Tree: edit flow diagrams for readme #11602
Conversation
…to more-diagrams
github-actions
bot
added
area: dds
packages/dds/tree/README.md
Outdated
| This shows editing during a transaction: | ||
|
|
||
| ```mermaid | ||
| graph RL; |
There was a problem hiding this comment.
Was this (and the one below) meant to be LR? It's a bit hard to read in the data flow sense but I can also see how RL makes sense when it comes to editing back in a pipe. I prefer LR for this though since it isn't a pipe.
There was a problem hiding this comment.
This was on purpose. I mostly wanted the components to be in roughly the same places in all the data flow diagrams, and in this one the data flows mainly in the reverse direction.
There was a problem hiding this comment.
Oh I see. Using subgraphs might help make this more clear if you keep some consistent groups of components in the same places throughout the diagrams. Feel free to resolve this though.
There was a problem hiding this comment.
I added some subgraphs, which I do think help. Good suggestion. They also broke the right to left setup, but I think left to right is fine now.
packages/dds/tree/README.md
Outdated
| This shows editing during a transaction: | ||
|
|
||
| ```mermaid | ||
| graph RL; |
There was a problem hiding this comment.
I'm also wondering if this particular graph would benefit from being a sequence diagram instead. The arrows are positioned in a way that makes them a bit confusing and it's difficult to tell which actors in this process matter.
There was a problem hiding this comment.
I tried a sequence diagram and I have mixed feelings about it. I'll make a separate PR for that change so its easier to compare
There was a problem hiding this comment.
I think with the subgraphs, it's probably not as necessary.
packages/dds/tree/README.md
Outdated
|
|
||
| ```mermaid | ||
| graph RL; | ||
| command["App's command callback"]--"completes transaction"-->transaction |
There was a problem hiding this comment.
There is a "completes transaction" arrow here and in the following line which is a bit confusing for me.
There was a problem hiding this comment.
When the application's command completes the transaction (returns in the case of a synchronous transaction), that is information flow from the command callback to the transaction which kicks of this whole process causing the transaction to submit the changes. I'm not sure how to more clearly capture that. Any suggestions?
There was a problem hiding this comment.
Hmm maybe either replacing the first with "trigger transaction completion" or the second with something along the lines of "finalize edits into transaction"? I think it'll help as long as it's clear in what component the transaction is actually being completed.
There was a problem hiding this comment.
I have made some more changes. Maybe its more clear now.
|
This commit is queued for merging with the |
No description provided.