We’ve been bitten several times by cases where a single node in a bad state brings down the whole document. For example, we had a text node get inserted somehow in an illegal empty state due to a nbsp. This then caused all renders of the doc to fail. In my preferred world, there would be a way to still render the doc but with a type of “this node is broken” placeholder.
To the best of my knowledge, prosemirror doesn’t have any built in error handling. (This post, eg).
Does anyone have any tips for handling cases like this in production? Is this kind of thing potentially possible with prosemirror? On first blush it seems quite complicated, because it might break selections, offsets, etc.
If someone’s thought about this I’d love to hear from them.
How did this happen? The DOMParser shouldn’t be capable of producing invalid documents.
In any case, the approach of this library is to try and keep the document rigidly valid, and I don’t think a messier approach where schema-violating nodes are tolerated sounds very promising.
How did this happen? The DOMParser shouldn’t be capable of producing invalid documents.
I’ve yet to figure that out. Probably a side effect of some monstrous way we’re using the library.
We semi-regularly find edge cases where somehow an illegal document has been persisted in a way that breaks prosemirror. A null node attribute that I expected not to be null, eg. Or more commonly, someone has made a backwards incompatible schema change so that a node was valid at write time, and then invalid when loaded three months later.
This is programmer error, obviously, but we haven’t come up with a good way to prevent this. We’ve considered eslint rules or perhaps JSONSchema applied to the doc, but we haven’t implemented anything yet.