The current Document machine is in charge of updating just one draft at a time. this is OK for the simple scenario of editing just one document, but what if the user wants to edit more than one document at a time?
Enter Draft document cards
Based on the new document card directions and interactions, we nee dto allow users to edit document metadata inside a document card. while this is possible inside query blocks and before in the special draft section at the end of the document content, it's not currently possible in document card embeds.
This can be achieved by introducing a new event type in the document machine, that can edit other drafts apart from the one loaded in the whole document editor.
Here's how we can achieve this:
a user creates a new document card.
this new document card that points to a separate draft, have the ability to change the document name, icon and even cover image.
because this events will be happening inside the editor, we might need to "ignore" this changes from the normal document edition. and trigger a new event (action or actor) that will accept the draft metadata that was changed and the draft ID. with this information, we can trigger a saveDraft to the correct draft outside of the document editor.
We can either spawn a new actor inside the document machine for each draft link (deduped), and send messages to it when something changes inside the draft cards. We can also do not spawn small actors, but just trigger async events when we blur inputs or the draft card form to trigger the draft save.
There are multiple ways to achieve this, and I prefer to explore the possible solutions and see which one can be the most robust one, because this needs to play well with other flows like rebase.
Editing documents is getting very complex
As y'all can see, "editing a document" is not just editing one document, is a very complex set of tasks that need to play well with all the tools we have in our disposal. now editing one document becomes editing a "document graph" or "Site Section", which makes things much more complex than a simple document editing experience.
I'm very glad we are using state machines and actors for this, because the complexity is increasing over time, and the only way to reason about something as complex as this is using predictable tooling like state machines and actors. Without it, it would become very hard to follow the workflow.
Do you like what you are reading? Subscribe to receive updates.
Unsubscribe anytime