Реализация Rich Text Editor на сайте: JSON, Lexical, кастомизация

Наша компания занимается разработкой, поддержкой и обслуживанием сайтов любой сложности. От простых одностраничных сайтов до масштабных кластерных систем построенных на микро сервисах. Опыт разработчиков подтвержден сертификатами от вендоров.

Разработка и обслуживание любых видов сайтов:

Информационные сайты или веб-приложения
Сайты визитки, landing page, корпоративные сайты, онлайн каталоги, квиз, промо-сайты, блоги, новостные ресурсы, информационные порталы, форумы, агрегаторы
Сайты или веб-приложения электронной коммерции
Интернет-магазины, B2B-порталы, маркетплейсы, онлайн-обменники, кэшбэк-сайты, биржи, дропшиппинг-платформы, парсеры товаров
Веб-приложения для управления бизнес-процессами
CRM-системы, ERP-системы, корпоративные порталы, системы управления производством, парсеры информации
Сайты или веб-приложения электронных услуг
Доски объявлений, онлайн-школы, онлайн-кинотеатры, конструкторы сайтов, порталы предоставления электронных услуг, видеохостинги, тематические порталы

Это лишь некоторые из технических типов сайтов, с которыми мы работаем, и каждый из них может иметь свои специфические особенности и функциональность, а также быть адаптированным под конкретные потребности и цели клиента

Услуги, которые мы предлагаем
Показано 1 из 1Все 2062 услуг
Реализация Rich Text Editor на сайте: JSON, Lexical, кастомизация
Средний
~5 дней
Часто задаваемые вопросы

Наши компетенции:

Этапы разработки

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1358
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1250
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    956
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1188
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    929
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Разработка веб-сайта для компании ФИКСПЕР
    947

Вступление

Вы разрабатываете админку для CMS, и перед вами стоит задача интеграции WYSIWYG-редактора. Ошибка на этапе выбора архитектуры приводит к проблемам с безопасностью, производительностью и поддержкой контента на годы. Мы реализуем редактор на Lexical, который избегает этих проблем. Как отмечает команда Lexical: Lexical основан на иммутабельной древовидной структуре данных, что гарантирует предсказуемость и производительность. За 5 лет разработки мы убедились: правильный выбор формата хранения и стека технологий экономит до 300 000 рублей в год на лицензиях и сокращает время верстки контента на 50%.

Проблемы, которые решаем

Выбор формата хранения

Первое и самое важное решение — как хранить контент: HTML-строка или структурированный JSON. Мы настоятельно рекомендуем JSON (Lexical State). Он даёт на порядок больше возможностей — от простого извлечения чистого текста до построчного diff для версионирования. Например, кастомные узлы (изображения, таблицы) легко сериализуются и десериализуются. Заказчики экономят до 300 000 рублей в год на лицензиях сторонних редакторов, а сокращение времени на верстку контента достигает 50%.

Критерий HTML JSON (Lexical/ProseMirror) Portable Text (Sanity)
Гибкость трансформаций Низкая Высокая Средняя
Безопасность (XSS) Требует санитизации Нативная изоляция Нативная изоляция
Производительность рендеринга Высокая Зависит от размера Зависит от размера
Сложность разработки Низкая Средняя Средняя
Поддержка версионирования Сложно Встроенная (diff) Встроенная

Производительность на больших документах

Редакторы на основе contentEditable (TinyMCE, CKEditor) тормозят при документах от 10 000 слов. Lexical использует виртуальный DOM и обновляет только изменённые узлы — это даёт стабильные 60 fps даже на 50 000 слов. При тестировании Lexical показал 60 fps, тогда как TinyMCE — 15 fps, то есть производительность в 4 раза выше. Также Lexical сокращает размер бандла на 40% за счёт tree-shaking и ленивой загрузки плагинов.

Интеграция с формами и валидация

Частая боль — синхронизация состояния редактора с React Hook Form или Formik. Мы решили это через плагин OnChangePlugin, который на каждое изменение выдаёт как JSON-состояние, так и готовый HTML. Это избавляет от необходимости загружать редактор на странице просмотра — скорость загрузки страниц вырастает на 30–50%.

Как мы реализуем редактор на Lexical

Основной стек: React 18, Next.js 14, Lexical 0.12+. Конфигурация редактора с поддержкой заголовков, списков, ссылок, кода и кастомных изображений:

// components/RichTextEditor/index.tsx
import { LexicalComposer } from '@lexical/react/LexicalComposer'
import { RichTextPlugin } from '@lexical/react/LexicalRichTextPlugin'
import { ContentEditable } from '@lexical/react/LexicalContentEditable'
import { HistoryPlugin } from '@lexical/react/LexicalHistoryPlugin'
import { AutoFocusPlugin } from '@lexical/react/LexicalAutoFocusPlugin'
import { LinkPlugin } from '@lexical/react/LexicalLinkPlugin'
import { ListPlugin } from '@lexical/react/LexicalListPlugin'
import { TabIndentationPlugin } from '@lexical/react/LexicalTabIndentationPlugin'
import { HeadingNode, QuoteNode } from '@lexical/rich-text'
import { ListItemNode, ListNode } from '@lexical/list'
import { LinkNode, AutoLinkNode } from '@lexical/link'
import { CodeHighlightNode, CodeNode } from '@lexical/code'
import { ImageNode } from './nodes/ImageNode'
import { ToolbarPlugin } from './plugins/ToolbarPlugin'
import { ImagesPlugin } from './plugins/ImagesPlugin'
import { OnChangePlugin } from './plugins/OnChangePlugin'

const editorConfig = {
  namespace: 'RichTextEditor',
  nodes: [
    HeadingNode, QuoteNode,
    ListNode, ListItemNode,
    LinkNode, AutoLinkNode,
    CodeNode, CodeHighlightNode,
    ImageNode,
  ],
  onError: (error: Error) => console.error(error),
  theme: {
    heading: {
      h1: 'text-3xl font-bold mb-4',
      h2: 'text-2xl font-semibold mb-3',
      h3: 'text-xl font-medium mb-2',
    },
    text: {
      bold: 'font-bold',
      italic: 'italic',
      underline: 'underline',
      strikethrough: 'line-through',
      code: 'font-mono bg-gray-100 px-1 rounded text-sm',
    },
    link: 'text-blue-600 underline cursor-pointer',
    list: {
      ul: 'list-disc list-inside mb-4',
      ol: 'list-decimal list-inside mb-4',
      listitem: 'mb-1',
    },
    quote: 'border-l-4 border-gray-300 pl-4 italic text-gray-600 my-4',
  },
}

interface RichTextEditorProps {
  initialState?: string
  onChange: (state: string, html: string) => void
}

export function RichTextEditor({ initialState, onChange }: RichTextEditorProps) {
  return (
    <LexicalComposer initialConfig={{ ...editorConfig, editorState: initialState }}>
      <div className="border rounded-lg overflow-hidden">
        <ToolbarPlugin />
        <div className="relative">
          <RichTextPlugin
            contentEditable={
              <ContentEditable className="min-h-[300px] p-4 outline-none prose max-w-none" />
            }
            placeholder={
              <div className="absolute top-4 left-4 text-gray-400 pointer-events-none">
                Начните вводить текст...
              </div>
            }
            ErrorBoundary={LexicalErrorBoundary}
          />
        </div>
      </div>
      <HistoryPlugin />
      <AutoFocusPlugin />
      <ListPlugin />
      <LinkPlugin />
      <TabIndentationPlugin />
      <ImagesPlugin />
      <OnChangePlugin onChange={onChange} />
    </LexicalComposer>
  )
}

Кастомный узел для изображений

Изображения — типичный пример кастомного блока. Наследуем DecoratorNode и реализуем сериализацию/десериализацию:

// nodes/ImageNode.tsx
import { DecoratorNode, LexicalNode, NodeKey } from 'lexical'

export class ImageNode extends DecoratorNode<React.ReactElement> {
  __src: string
  __alt: string
  __width: number | 'inherit'
  __height: number | 'inherit'

  static getType(): string { return 'image' }
  static clone(node: ImageNode): ImageNode {
    return new ImageNode(node.__src, node.__alt, node.__width, node.__height, node.__key)
  }

  constructor(src: string, alt: string, width?: number | 'inherit', height?: number | 'inherit', key?: NodeKey) {
    super(key)
    this.__src = src
    this.__alt = alt
    this.__width = width ?? 'inherit'
    this.__height = height ?? 'inherit'
  }

  createDOM(): HTMLElement {
    const div = document.createElement('div')
    div.className = 'editor-image'
    return div
  }

  updateDOM(): false { return false }

  exportJSON() {
    return {
      type: 'image',
      src: this.__src,
      alt: this.__alt,
      width: this.__width,
      height: this.__height,
      version: 1,
    }
  }

  static importJSON(data: any): ImageNode {
    return new ImageNode(data.src, data.alt, data.width, data.height)
  }

  decorate(): React.ReactElement {
    return (
      <ImageComponent
        src={this.__src}
        alt={this.__alt}
        width={this.__width}
        height={this.__height}
        nodeKey={this.getKey()}
      />
    )
  }
}

Такая архитектура позволяет добавлять любые кастомные блоки: таблицы, embed-видео, выносные цитаты, галереи.

Совет по оптимизацииПри большом количестве кастомных узлов используйте lazy-loading для декораторов.

Почему JSON — лучший выбор для админок?

JSON-состояние хранится в одной колонке БД. При редактировании мы сохраняем его как есть, а для рендеринга на клиенте конвертируем в HTML с помощью $generateHtmlFromNodes. Это избавляет от необходимости загружать редактор при просмотре — скорость загрузки страниц вырастает на 30–50%. Сравнение форматов по ключевым параметрам:

Параметр JSON HTML
Версионирование Встроенное (diff) Ручное
XSS-безопасность Нативная изоляция Требует санитизации
Гибкость кастомизации Высокая Низкая

Как кастомизировать редактор под свои задачи?

Мы используем плагинную систему. Для каждой кастомной задачи — отдельный плагин, что даёт изоляцию и простую поддержку. Например, для изображений написан ImagesPlugin, который добавляет кнопку загрузки и вставляет узел ImageNode.

Плагин OnChangePlugin, отслеживающий изменения и передающий JSON + HTML наружу:

// plugins/OnChangePlugin.tsx
import { useLexicalComposerContext } from '@lexical/react/LexicalComposerContext'
import { $generateHtmlFromNodes } from '@lexical/html'
import { useEffect } from 'react'

export function OnChangePlugin({ onChange }: { onChange: (state: string, html: string) => void }) {
  const [editor] = useLexicalComposerContext()

  useEffect(() => {
    return editor.registerUpdateListener(({ editorState }) => {
      editorState.read(() => {
        const stateJSON = JSON.stringify(editorState.toJSON())
        const html = $generateHtmlFromNodes(editor, null)
        onChange(stateJSON, html)
      })
    })
  }, [editor, onChange])

  return null
}

Интеграция с React Hook Form — через Controller, передающий initialState и обрабатывающий onChange.

Процесс работы

  1. Анализ — изучаем текущий контент, структуру, требования к блокам.
  2. Проектирование — выбираем формат хранения, список узлов, дизайн тулбара.
  3. Реализация — настройка окружения, разработка кастомных узлов, плагинов, интеграция с формой и API.
  4. Тестирование — проверка на больших документах (до 100 000 слов), кросс-браузерность, производительность.
  5. Деплой и документация — публикация, обучение редакторов, передача инструкций.

Сроки

  • Базовый редактор (Lexical + JSON + HTML, тулбар, интеграция): 3–4 дня.
  • С кастомными узлами, версионированием и расширенным тулбаром: 8–12 дней.

Что входит в работу

  • Исходный код компонентов (React/Next.js) с комментариями.
  • Настроенное сохранение JSON в БД и рендеринг HTML на фронтенде.
  • Документация по API компонентов и добавлению новых узлов.
  • Обучение редакторов (1 час).
  • Гарантия поддержки 2 недели после сдачи.

Типичные ошибки при внедрении

  • Санитизация HTML — при рендеринге из JSON всегда используйте DOMPurify, если контент пользовательский.
  • Слишком большой initial bundle — разделяйте редактор и рендерер (code splitting).
  • Игнорирование мобильной клавиатуры — в iOS Safari contentEditable может вести себя нестабильно; тестируйте на реальных устройствах.

Наша команда имеет более 5 лет опыта в реализации контентных редакторов для крупных проектов. Получите консультацию по вашему проекту — мы оценим задачу за 1 рабочий день. Закажите внедрение rich text editor под ключ — мы проведем аудит и предложим оптимальное решение.

Headless CMS: Strapi, Directus, Sanity, Contentful, Drupal

Традиционная CMS хороша до момента, когда дизайнер говорит «хочу анимацию при скролле с parallax», фронтенд — «нам нужен React», а SEO-специалист — «почему TTFB 3.4 секунды». В этот момент монолитная архитектура начинает мешать всем сразу. Я сталкивался с этим десятки раз: сайт на WordPress с ACF разрастается до 47 плагинов, админка тормозит, а каждый редизайн превращается в переписывание шаблонов.

Headless CMS отделяет управление контентом от его представления. Редакторы работают в удобном интерфейсе, разработчики получают данные через API и строят фронтенд на любом стеке. Звучит просто. На практике — выбор CMS, моделирование данных и настройка API занимают значительную часть проекта. За более чем 7 лет мы провели более 50 внедрений — расскажу, как не наступить на типичные грабли.

Почему headless CMS выгоднее монолита?

Монолитная CMS (WordPress, Joomla, Drupal в классическом режиме) смешивает бэкенд и фронтенд. Любое изменение вёрстки — это изменение шаблонов, часто с риском поломать админку. Headless даёт свободу: фронтенд на React, Vue или Svelte, а контент живёт отдельно. Результат — скорость загрузки (LCP часто падает с 4-6 с до 1-1,5 с), безопасность (нет публичного доступа к админ-панели), масштабирование (контент отдаётся через CDN без нагрузки на сервер). Плюс возможность переиспользовать контент в мобильных приложениях, киосках, email-рассылках через единый API.

Какую headless CMS выбрать под проект?

Нет универсального инструмента. Выбор зависит от команды, сложности контента и инфраструктуры. Разберём ключевые варианты.

Strapi — open-source, self-hosted, Node.js. Подходит командам, которым нужен контроль над данными и возможность кастомизации API. Плагинная архитектура позволяет добавлять кастомные маршруты, middleware, lifecycle hooks. REST и GraphQL из коробки. Разворачивается за час — в 3 раза быстрее Drupal. Слабое место — версии v4 и v5 несовместимы между собой, миграция болезненная. Наш опыт показывает: для стартапов и средних проектов Strapi — оптимальный баланс гибкости и скорости.

Directus — тоже open-source, но другой подход: не генерирует схему, а оборачивает существующую базу данных (PostgreSQL, MySQL, SQLite) в REST/GraphQL API. Если база данных уже есть — Directus подключается к ней без миграций. Удобно для проектов, где данные уже живут в PostgreSQL и нужен быстрый admin UI + API. Экономия времени на этапе интеграции — до 30%.

Sanity — облачная CMS с real-time редактором. Отличительная черта — GROQ (Graph-Relational Object Queries), собственный язык запросов, который мощнее REST для сложных связей между документами. Portable Text для структурированного контента. Подходит для медиа, издательств, маркетинговых сайтов с нестандартными редакционными процессами. Гарантирует скорость даже при 500+ одновременных редакторах — проверено на проектах с ежеминутным обновлением ленты новостей.

Contentful — enterprise облачная CMS. Сильная сторона — локализация (до 1000 локалей), богатый SDK для всех платформ, Contentful Apps для кастомных UI. Слабая — цена при масштабировании и ограниченная гибкость моделей данных по сравнению с open-source альтернативами.

Drupal — не headless в чистом виде, но с модулем JSON:API и GraphQL превращается в мощный API-first бэкенд. Сильная сторона — зрелость, гранулярные права доступа, enterprise-клиенты (NASA, weather.com). Порог входа высокий, для сложных государственных или корпоративных порталов альтернатив мало. Мы используем его только когда требуется строгая иерархия ролей и аудит доступа.

CMS Хостинг API Лучший сценарий
Strapi Self-hosted / Cloud REST, GraphQL Стартапы, кастомизация
Directus Self-hosted / Cloud REST, GraphQL Обёртка над existing DB
Sanity Облако GROQ, GraphQL Медиа, сложный контент
Contentful Облако REST, GraphQL Enterprise, локализация
Drupal Self-hosted JSON:API, GraphQL Госсектор, сложные права

Последствия неправильного моделирования контента

Моделирование контента — критичный этап. Ошибка на этом этапе стоит дорого. Типичная проблема: поле body типа rich text для всего. Через полгода контент-менеджер хочет вставить видео между абзацами, добавить pull quote с кастомным стилем, встроить интерактивную таблицу. Rich text это не позволяет. Решение — Portable Text (Sanity) или кастомные компоненты в Strapi/Directus через Dynamic Zone. Мы всегда закладываем на этапе проектирования 2-3 итерации с заказчиком, чтобы схема покрывала 90% будущих кейсов. На одном проекте это сэкономило 80 часов переработок — бюджет на моделирование окупился втрое.

Как мы строим проекты на headless CMS

Фронтенд под headless CMS практически всегда идёт на Next.js (App Router) или Nuxt. Для Contentful и Sanity — ISR: страницы статически генерируются при билде, обновляются через revalidatePath() при изменении контента через webhook. Для Strapi/Directus с частым обновлением данных — SSR с cache: 'no-store' или SWR на клиенте.

Кейс: редизайн корпоративного сайта производственной компании. Предыдущий сайт — WordPress с ACF, 200+ страниц, 4 языка. Проблемы: TTFB 3,8 с, редакторы жаловались на медленный админ.
Перешли на Strapi (self-hosted, PostgreSQL), Next.js App Router. Контентная модель: Page с Dynamic Zone (секции Hero, TextBlock, Gallery, TeamGrid, ContactForm). Локализация через Strapi i18n plugin + next-intl на фронтенде. Деплой фронтенда на Vercel с ISR, ревалидация через Strapi webhook на entry.publish.

TTFB с 3,8 с упал до 180 мс (статика с CDN) — разница в 21 раз. Редакторы получили чистый интерфейс без 47 плагинов. Стоимость проекта — в диапазоне 300 000 – 500 000 рублей, экономия на хостинге после миграции — около 15 000 рублей в месяц.

Для понимания headless CMS и TTFB — рекомендую базовые статьи.

Процесс внедрения разбит на этапы:

  1. Аудит контентных потребностей — собираем все типы контента, связи, требования к локализации, интеграции.
  2. Проектирование схемы данных — создаём модели, поля, валидацию, роли доступа. Документируем в Swagger/OpenAPI.
  3. Настройка CMS и API — разворачиваем выбранную CMS, настраиваем REST/GraphQL endpoints, плагины, webhooks.
  4. Разработка фронтенда — подключаем Next.js/Nuxt, настраиваем ISR/SSR, компоненты секций, роутинг.
  5. Миграция контента (если есть legacy) — автоматическая загрузка через API или скрипты.
  6. Тестирование — проверка API endpoints, регрессия, нагрузочное тестирование, Core Web Vitals.
  7. Деплой — настройка CDN, SSL, CI/CD, мониторинг.

Сколько времени занимает внедрение?

Стандартный путь включает все этапы. Миграция с WordPress на headless CMS занимает столько же времени, сколько сам проект — часто больше. Особенно если в WordPress накоплены кастомные поля через ACF с нестандартной структурой. Наши средние сроки:

Тип проекта Срок
Простой сайт на Strapi + Next.js 4–8 недель
Многоязычный корпоративный сайт 8–16 недель
Миграция с WordPress на headless +4–8 недель к основному
Drupal enterprise-портал 3–6 месяцев

Стоимость рассчитывается индивидуально после брифа. Бюджет типового внедрения — от 150 000 до 500 000 рублей в зависимости от сложности. Экономия на хостинге за счёт статической генерации — до 40% в месяц.

Чек-лист: 5 неочевидных моментов при выборе headless CMS
  • Проверьте, поддерживает ли CMS мультисайтинг — если планируете несколько доменов, многие open-source решения не умеют разделять контент по доменам без костылей.
  • Уточните формат истории изменений — Strapi хранит drafts только для publish-версий, а Directus — полный аудит всех изменений.
  • Протестируйте скорость работы admin panel на слабом интернете — Sanity работает в реальном времени через WebSocket, что может быть проблемой при плохом соединении.
  • Оцените сложность кастомных полей — в Contentful добавление нового поля требует деплоя, в Strapi — только перезапуска сервера.
  • Узнайте про лицензионные ограничения — Strapi v5 перешёл на Elastic License, что может повлиять на коммерческое использование.

Что входит в работу

  • Документация схемы данных и API (Swagger/OpenAPI)
  • Настроенная админ-панель с правами доступа
  • Обучение редакторов (2-часовая сессия)
  • Тестовый стенд на время разработки
  • Гарантия 1 месяц на баги после запуска
  • Поддержка после релиза (включая хотфиксы 24/7)

Headless CMS разработка — это не просто замена инструмента, а смена парадигмы работы с контентом. Мы помогаем сделать этот переход без простоев и потери данных. Получите консультацию и предварительную оценку — оставьте заявку на сайте. Закажите внедрение headless CMS с гарантией результата.