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

1. 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.

2. 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.

3. 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.