Hosted onseed.hyper.mediavia theHypermedia Protocol

Problem

Now that we are accepting draft links inside the document editor, we need to be careful of publishing draft links to the network. We decided for now to prevent publishing if there's any draft link in the document content, so writers must resolve all draft links in the document before they are allowed to publish

The problem is when we have a chain of draft links in multiple documents (A -> draft B -> Draft C) and we start publishing the chain (Publish C, then B...) we need to "resolve" this draft link dependencies automatically. let's work with a concrete example to really understand the flow.

Example

what we have:

  1. Document A that is a Draft and have a Document B Document card

  2. Document B that is a Draft and have a Document C Document card

  3. Document C that is a Draft.

In this example:

  • If we want to publish Document A, we need to first Publish Document B

  • If we want to publish Document B, we need to first Publish Document C

Until here I believe everything should be clear. the issue is what happens when we publish Document C or Document B. In this case we need to make sure we "update" the url those document cards point to.

Desired Solution

In the case that we publish Document C or Document B, we have multiple options, but because we know we are adding a link to a draft, we have all the information needed to accomplish this properly.

This is what I believe we should do:

  1. when we add a link to a draft, we must store this link into the draft schema, and keep track of all the documents that includes a link to it

  2. when we publish one draft, we should check the list of "backlinks" to this draft, and update the link to it from pointing to the draft, to point to the final published document URL.

  3. This extra updates on other drafts should happen before we remove the draft document in the middle-end.

  4. when we add a link to a draft, we should also call a new event in the document machine, that will call an async function (another actor or an action), that will include this document link to the backlinks of the draft linked.

  5. when the draft is published, we need to make sure we are updating the link to all its backlinks correctly.

Because we have the document machine, we have a very deterministic way of knowing this states and make sure this new transformations and events are reliable.

The implementation of this new actor or action should not live inside the document machine, but where we create it, because the way we store drafts now is different on web and desktop (check how the publishActor is spawned and implemented for an example).

Do you like what you are reading? Subscribe to receive updates.

Unsubscribe anytime