@marijn I have a different use case that might very well affect more developer’s ease of use (and might be relatively common)
This desire to have support for placeholders crops up only when I am developing two branches at once, one with an experimental feature that contains new schema, and thus when exploring / testing, the relational database then contains text json that contains the new schema type.
But swapping back to, say, the master or develop branch, it’s no longer defined - currently, I have to purge the database and restore from some supported state while working there, for documents with the new schema to load at all. The schema no longer has the experimental new one, so all prosemirror documents with it fail to parse. Not a big deal, and like you say, one can develop a pre-parser to generate a schema, but sounds like it could relatively easily be an option in renderer or just always on.
I am narrowing in our developer flexibility and ease of switching branches, without worrying about dynamic schemas causing documents to fail. Im ok with it not being supported by main prosemirror, just wanted to add to the list of “what this may be helping”
It appears that @lxgreen’s use case has a better solution:
@lxgreen; My suggestion to you is to run a single screen of all json to detect “unknown” types and generate a schema once.
But for branched dev, it appears there is no way around this hiccup though I am open to other suggestions. The placeholder declaring no support for type X is just first that comes to mind. The proposal for a custom parser and dynamic schema generated being second in line - the end result is just to produce the placeholder anyway as not much can be done with it other than detecting whether it has children or not and rendering accordingly in both cases?