Open Reinmar opened 7 years ago
Also this is useful to render saved editor schema in readonly mode. It allows to store editor schema in DB instead of plain html and have dynamic rendering (converting schema -> html) at front-end to display article to user.
This is a use case we've been also considering. To make it possible, we decided to split every feature into two level:
You can clearly see this division in the Bold feature:
BoldEngine
implements the schema rules, converters between the model and the view and even a command. This means that if you load an editor with this feature you'll be able to perform model<->view conversion (loading data, getting data) and even apply/remove the bold attribute from the selection (using virtual selection in the model). All this, without any dependency on the DOM and the browser environment in general.Bold
requires BoldEngine
and adds a UI on top of it (button + keystroke).So, not only this architecture allows running (in Node.js) an editor with some features to load/convert/retrieve the data, but it also allows operating on this data. Since model and view (virtual DOM, not real DOM) are browser-independent, unless rendering to the DOM is not enabled, you can do everything you want.
If it's going to be a big feature/epic then I have suggestion for code name for that one: Mike.
I've tried to build an embeddable / headless editor. It works quite well so far, but there are some issues:
Blockquote
plugin overwrites enter key behavior. I don't use this plugin because I don't want GUI. But I need fully functional typing. I think such overwrite should be handled somewhere else, perhaps in BlockquoteTyping
plugin.Wow, thanks for the feedback :)
It's about 100 kB (ES5, gzipped). I wonder if it will be possible to make it a bit smaller. 100 kB is not too much, but mobile devices often run on slow connections. See report.
Let's discuss it in https://github.com/ckeditor/ckeditor5/issues/435.
The Blockquote plugin overwrites enter key behavior. I don't use this plugin because I don't want GUI. But I need fully functional typing. I think such overwrite should be handled somewhere else, perhaps in BlockquoteTyping plugin.
I didn't expect that anyone will ever want to split the code into even smaller pieces :). I thought that we're already going crazy dividing features into two parts (engine + UI).
But your point of view makes a lot of sense. We need to decide whether we more want to divide features into browser-independent + browser-dependent pieces or headless + head. I reported a more specific ticket about it in https://github.com/ckeditor/ckeditor5/issues/488. Feel free to comment there.
There's a discussion regarding implementing a headless editor in https://github.com/ckeditor/ckeditor5/issues/984. We've explained there some architectural concepts like how's the current feature split working and what interfaces make for an editor.
Hello friends. I've tried to use ckeditor5 as headless editor, fully removing all the ui and so far my experience is alright, but i needed some re-touches.
1) I managed to change build system (using vite) and not use webpack, or any ckeditor-specific plugins
2) It is difficult to not get css loaded into the build. A lot of files include them inside packages. I had to create custom rollup transformer to stub the css into empty files, but it's still not really a clean solution. Same with the svg icons
3) There're some modules that access some ui code ,e.g. editor.ui.focusTracker
, so i stubbed it.
4) I had to pick non-ui specific files for all the modules i used (e.g. headingediting.js
vs heading.js
), but some of the modules still require ui files by using imports from main file (e.g. hypothetical xxxediting.js
does import {xxx} from "index.js"
which does import xxxui.js
. I think one of examples is undo
plugin
5) Unfortunately it currently is really hard to get some of the cruft out of the build (e.g. widgetresize)
6) It was really nice to be able to use ckeditor on dom elements directly, implementing custom focus handling, etc. It went really smooth.
Overal i'm decently happy with the result, but it obviously could use some love. I think CKEditor5 is the best framework out there and i'm using it with a lot of custom plugins and external ui. I just wish there was a cleaner (more complete) way to achieve it.
There has been no activity on this issue for the past year. We've marked it as stale and will close it in 30 days. We understand it may still be relevant, so if you're interested in the solution, leave a comment or reaction under this issue.
Still important
On Sun, Oct 22, 2023 at 1:13 PM CKEditor Bot @.***> wrote:
There has been no activity on this issue for the past year. We've marked it as stale and will close it in 30 days. We understand it may still be relevant, so if you're interested in the solution, leave a comment or reaction under this issue.
— Reply to this email directly, view it on GitHub https://github.com/ckeditor/ckeditor5/issues/438#issuecomment-1773996885, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAAVFDGD3A5TCW4BAH42MDYASTPHAVCNFSM4DKHLWD2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCNZXGM4TSNRYHA2Q . You are receiving this because you commented.Message ID: @.***>
See @fredck's initial ticket: https://github.com/ckeditor/ckeditor5-design/issues/86.
The goal of a headless editor would be to make it as simple as possible to create an editor with your own UI.
This means that we need:
EDIT: See https://github.com/ckeditor/ckeditor5/issues/984 for explanation how headless editor can be implemented.