I have an idea to detect and handle cases when the content JSON contains node/mark types which are missing in schema (e.g. extension is not provided), by patching the schema in runtime (i.e. adding dynamically generated fallback extensions of proper types and names). This way, the content remains unchanged (which is crucial in my case), and yet partially editable.
Is such idea feasible?
Could such mechanism play well with prosemirror (I’m still a newbie here).
Schemas can not be updated dynamically. Maybe you could generate a schema in advance before parsing, by scanning the input, but I don’t really see how that helps—the idea is that you define a schema for the document structure you want, so that you know what you get. If you want to allow anything, a generic HTML editing component might be more appropriate.
My use case is not a straightforward one. I’m migrating my project from draft-js based editor to prosemirror. There’s a bunch of draft-js plugins that are being transformed to prosemirror extensions. Also, there’s a lot of user content in JSON format, containing these plugins data.
So, I do know the final schema, but it takes time to fully implement all the extensions. I think such fallback extension could be useful during this migration period.
As you suggested, before editor instantiation the user content is being analyzed. So, I have a set of available extensions vs a set of marks/nodes that found in a specific content to be displayed. So, I’m trying to generate the fallback extensions and use the full extension set in editor.
@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?
Oh I might have misunderstood how you explained since it didnt (explicitly) mention VCS but now it makes more sense; thanks for clarifying (and hope my clarification also helps make a more fair case for this feature ask)
(and hope my clarification also helps make a more fair case for this feature ask)