we have a fully structured document model, so every piece in the document has an unique ID. We’re now modelling those small pieces as custom nodes (both block and inline) in PM.
Each node has a unique view state. Additionally some of the nodes are “decision” nodes with their own internal states. The internal state of a “decision” node is synced outside PM and could influence the view states of other nodes.
Since PM nodes per se are somewhat stateless, could you share some ideas how to store and manage those states?
My current thoughts are:
- All view states in a plugin, use node decorations to mutate the view (similar to PM’s linter example)
- Pro no need of custom views, better compatibility with other plugins
- Conta decorations are quite limited (but sufficient for us at the moment), hard to keep track of the nodes through updates
- Custom node view: Store view states in each node’s view (similar to PM’s footnote example) and pass an updater callback function to a central plugin
- Pro easier to code
- Conta NodeView life-cycle is actually not in sync with the document model, could this cause some problem? If we also mutate node attributes, which creates a new node and node view, how to pass the view state from the old to the new view?
We want these internal states to go with the document. They have influences on the view states of other nodes and they have to be two-way synced out of PM.
- Node attribute or mark: I think this makes changing states quite expensive?
- Separate custom state nodes either as children of each “decision” node or in a separate state section of the doc.
What’s your opinion?