Собственный WYSIWYG-редактор мы разрабатываем, когда готовые инструменты не справляются с уникальными требованиями: нестандартные блоки, строгий выходной HTML, интеграция с бэкендом CMS. Наш опыт — 10+ лет и 50+ проектов — позволяет создавать редакторы под ключ за 3–12 недель. Мы гарантируем документацию, обучение и поддержку после сдачи.
Готовые редакторы (TinyMCE, CKEditor) часто имеют избыточную функциональность или, наоборот, не позволяют добавить специфические блоки: видео с кастомного плеера, интерактивные таблицы, встраивания из внешних сервисов. Кроме того, они генерируют грязный HTML, который сложно парсить на бэкенде. Кастомный редактор даёт полный контроль над моделью данных и выходным кодом.
Мы проектируем редактор под конкретную CMS: Laravel, WordPress, Django или кастомное решение. Контент храним в JSONB полях базы данных — это гибко и индексируемо. На выходе — быстрый, предсказуемый редактор с контекстным тулбаром, slash-командами и перетаскиванием блоков.
Сценарии для кастомного WYSIWYG-редактора
Свой редактор пишут, когда ни одно готовое решение не закрывает все требования. Типичные сценарии:
- Нестандартные блоки: кастомные галереи, интерактивные схемы, встраивание сторонних сервисов через iframe.
- Чистый HTML: нужен строгий выходной код без лишних обёрток, например, для дальнейшей конвертации в PDF или e-mail.
- Глубокая интеграция: редактор должен сохранять данные напрямую в CMS, работать с медиатекой, поддерживать права доступа.
- Производительность: при сотнях блоков на странице готовые редакторы тормозят — нужна виртуализация и ленивая загрузка.
Какой движок выбрать: ProseMirror, Slate или Lexical?
Писать редактор на голом contenteditable — путь к бесконечным багам. Выбор стоит между тремя зрелыми движками:
| Движок | Гибкость | Производительность | Поддержка React | Сложность освоения |
|---|---|---|---|---|
| ProseMirror | Высокая | Высокая | Через Tiptap | Высокая |
| Slate.js | Средняя | Средняя | Нативная | Средняя |
| Lexical | Высокая | Очень высокая | Нативная | Средняя |
ProseMirror даёт максимальный контроль над моделью данных — его используют, например, в New York Times. Slate.js лучше для React-проектов, где важна скорость разработки. Lexical от Meta — самый производительный, но сообщество ещё невелико.
Как построить модель данных для редактора?
Редактор должен работать с чёткой схемой. Два популярных подхода: Flat JSON (список блоков) и Дерево (вложенная структура).
Пример Flat JSON (стиль Editor.js):
{
"blocks": [
{ "id": "abc123", "type": "header", "data": { "text": "Заголовок", "level": 2 } },
{ "id": "def456", "type": "paragraph", "data": { "text": "Текст параграфа" } },
{ "id": "ghi789", "type": "image", "data": { "url": "/uploads/photo.jpg", "caption": "Подпись" } }
],
"version": "2.28.0"
}
Пример дерева (ProseMirror/Tiptap):
{
"type": "doc",
"content": [
{
"type": "heading",
"attrs": { "level": 2 },
"content": [{ "type": "text", "text": "Заголовок" }]
},
{
"type": "paragraph",
"content": [
{ "type": "text", "text": "Обычный " },
{ "type": "text", "marks": [{ "type": "bold" }], "text": "жирный" },
{ "type": "text", "text": " текст" }
]
}
]
}
В PostgreSQL данные хранятся в jsonb с GIN-индексом для полнотекстового поиска. Каждый тип блока — отдельная React-компонента с режимами просмотра и редактирования. Регистрируем блоки через плагинную систему:
interface BlockPlugin<T = Record<string, unknown>> {
type: string;
label: string;
icon: React.ReactNode;
defaultData: T;
render: (data: T, ctx: RenderContext) => React.ReactNode;
edit: (data: T, onChange: (data: T) => void) => React.ReactNode;
validate?: (data: T) => ValidationError[];
toHTML?: (data: T) => string;
}
Контекстный тулбар, slash-команды и drag-and-drop
Тулбар появляется только при выделении текста — не занимает место и не отвлекает. Реализуем плавающую панель через FloatingToolbar с кнопками жирности, курсива, ссылки.
Slash-команды — стандарт для блочных редакторов: ввод / открывает меню выбора блока. Фильтрация по названию ускоряет работу.
Drag-and-drop сортировка блоков реализована через @dnd-kit/core. Блоки перетаскиваются без потери контента.
Как работает история изменений?
class EditorHistory {
private undoStack: EditorState[] = [];
private redoStack: EditorState[] = [];
private maxSize = 100;
push(state: EditorState) {
this.undoStack.push(structuredClone(state));
if (this.undoStack.length > this.maxSize) this.undoStack.shift();
this.redoStack = [];
}
undo(current: EditorState): EditorState | null {
if (this.undoStack.length === 0) return null;
this.redoStack.push(structuredClone(current));
return this.undoStack.pop()!;
}
redo(current: EditorState): EditorState | null {
if (this.redoStack.length === 0) return null;
this.undoStack.push(structuredClone(current));
return this.redoStack.pop()!;
}
}
Для больших документов используем иммутабельные структуры (Immer) для экономии памяти.
Автосохранение — через дебаунс 2 секунды после последнего изменения. Статус отображается в интерфейсе: «Сохранено», «Сохранение...», «Есть изменения».
Рендеринг на фронтенде сайта
JSON редактора рендерится на публичной части сайта. Два подхода:
- SSR через React — данные передаются в те же компоненты блоков, что и в редакторе. Идеально для Next.js.
- Серверный рендеринг — на PHP или Node.js парсим JSON и генерируем HTML напрямую, без React.
| Подход | Производительность | Сложность | Гибкость |
|---|---|---|---|
| SSR с React | Средняя | Средняя | Высокая |
| Серверный рендеринг | Высокая | Высокая | Средняя |
Пример рендерера на Laravel:
class BlockRenderer
{
protected array $renderers = [];
public function register(string $type, callable $renderer): void
{
$this->renderers[$type] = $renderer;
}
public function render(array $blocks): string
{
return collect($blocks)
->map(fn($block) => ($this->renderers[$block['type']] ?? fn() => '')($block['data']))
->implode("\n");
}
}
Работа с медиа и производительность
Редактор интегрируется с медиатекой CMS. Изображения загружаются через drag-and-drop прямо в блок — прогресс-бар показывает статус. Для больших документов (сотни блоков и десятки изображений) включаем виртуализацию: рендерим только видимые блоки плюс буфер, остальные заменяем плейсхолдерами. Используем react-window или @tanstack/virtual.
Что входит в работу
- Анализ требований и проектирование модели данных
- Разработка ядра редактора и системы плагинов
- Реализация типовых и кастомных блоков
- Интеграция с CMS через REST API или прямую работу с БД
- Настройка автосохранения, истории, медиатеки
- Тестирование и отладка
- Создание документации и обучение редакторов
- Гарантийная поддержка 12 месяцев
Сроки и стоимость
Ориентировочные сроки:
- MVP: 3–4 недели
- Полноценный редактор: 8–12 недель
- Сложные проекты с уникальными блоками: до 16 недель
Стоимость рассчитывается индивидуально в зависимости от сложности. Конкретную цифру называем после аудита требований.
Почему выбирают нас?
- 10+ лет опыта в разработке редакторов для медиа и корпоративных сайтов
- 50+ проектов — от небольших блогов до крупных порталов
- Прозрачный процесс: каждые 2 недели демонстрируем промежуточные результаты
- Гарантия 12 месяцев и бесплатная поддержка после запуска
Закажите разработку редактора под ключ — свяжитесь с нами для консультации и получите инструмент, который полностью соответствует бизнес-задачам.