В качестве образцов блоков мы написали первые плагины: «Параграф», «Заголовок», «Картинка», «Список» и еще некоторые. Старались придумать примеры разных сценариев: от простого набора и оформления текста до плагинов, взаимодействующих с серверной частью. Это позволило развивать API, который даёт возможность создать абсолютно любой плагин.
Отличный редактор !
А он открытый ? его в своих проектах юзать можно будет ?
(принцип тот же остался - на сервер типа массив параграфов уходить будет ?)
Спасибо !
Привет!
Исходный код открыт и выложен на гитхабе :)
Вот тут можно найти ядро — https://github.com/codex-team/editor.js, а здесь наши плагины — https://github.com/editor-js
Ядро распространяем под лицензией Apache-2.0 (можно делать все, что угодно, упоминая оригинальную лицензию), плагины под MIT.
Формат данных и другие подробности есть в документации — https://editorjs.io
Обожаю редакторы как на комитете, телеграфе, телетайпе и вордпрессе.ком (именно ком).
Крутая штука!
Восхищаюсь вашей работой. Спасибо большое! Как пользователь ранее использовал другие предложения рынка, но теперь я точно знаю куда смотреть) На ханте апвот оставил.
Подскажите, пожалуйста, на вашем сайте https://editorjs.io/ вижу примечание связанное с видео, но в редакторе тестирую возможности и его не нахожу. Как добавить видео? А второй вопрос, возможно ли добавлять иной код, например плейлист с Я.музыка?
Все зависит от плагинов, которые вы будете использовать. Для любой задачи можно написать свой плагин.
Мы написали несколько для примера:
https://github.com/editor-js
У нас есть плагин Image, который поддерживает загрузку гифок и mp4, но требуется серверная имплементация
Есть плагин Embed, который позволяет вставлять YouTube, Vimeo и тд по ссылкам. Кстати, Яндекс.Музыку тоже поддерживает.
Очень здорово! Этот мир нуждается в хороших WYSIWYG-редакторах :)
В сравнении с draft.js вы не стали пытаться работать с внутренним состоянием блока и просто оставили там html. Надо сказать, решение изящное (я в свое время не сработался с draft.js/slate.js — слишком много приходится кода вокруг писать, и результат не стабилен), но вдруг захочется большего? Например, есть ли возможность (или появится), сохранить в JSON блока дополнительные ключи с какими-либо данными и соответствует ли это философии проекта?
А можете вкратце написать, как вы работаете с состоянием (обновлением) редактора (понятно, что можно подсмотреть в коде), но хотелось бы ваш взгляд, почему сделали так, а не иначе. И проверяли ли на больших текстах (от 40 тыс. знаков)?
Наконец, вопрос про хранение в JSON. Если вы настраиваете поиск по тексту, насколько все усложняется? (логично хранить это в jsonb постгреса — подозреваю, что у вас так и есть)
Именно из-за усложнения вывода таких данных и не стали пока применять отдельные структуры для форматирования инлайн-фрагментов. Внутренние споры об этом ведем до сих пор. Но наша изначальная задумка — максимально низкий порог входа для разработчиков. В будущих обновлениях, возможно, появится выбор.
Про дополнительные поля в JSON — прямо в точку. Уже проектируем такой уровень API. Нужен нам для плагина комментариев.
Про состояние, если совсем кратко, используем Proxy. То есть у нас по сути написан реактивный диспетчер блоков — добавили или изменили блок в массиве, он изменился в DOM.
Про хранение JSON планируем написать отдельную заметку в документации. У нас по разному везде. Тут, например jsonb. Elasticsearch легко интегрируется.