Tasks
improve design for editor blocks rendering
SSR the editor
new document state machine definition with all new possible states
improve editor schema so it will load the needed extensions depending on editor state.
editor inside editor: embed use case
new editor extensions
supernumbers
select to comment
copy block link + block comment buttons
state persistence for fast navigation
image full page gallery
test the new machine in publication page
Questions
the idea is to remove the special draft URL and make the edited version or a document a new document state. should we encode this editing state in the URL? maybe a new param like draft=<DRAFT_ID> ? This could enable users to have multiple drafts for the same path in the future?
Horacio: I think we should skip this to the future.
when there's an available draft for /foo document and I can edit it, if I click on a button that takes me to /foo, should I show the edited version of the published version? of course if I have a v= param this should show the actual version IF its not the latest version I have on my node, but if there's no v param?
Horacio: I think we should show the edited version all the time we can. if the v param is present, then show the readOnly version of that document version.
do we want a special "Edit" button to enter into edit mode? or just by clicking on any block it should enter to edit mode?
Horacio: I think we can enter edit mode by clicking on any text block content. media elements should have the ability to "replace" them. after replacing we should be already in edit mode.
Do you like what you are reading?. Subscribe to receive updates.
Unsubscribe anytime