First off – allow me to gush about how friggen awesome ProseMirror is briefly. It makes me feel like I can actually build incredibly rich experiences without going insane and is well thought through at every turn, so, thanks Marijn!
I am building a kind of rich content editor where a user is able to interpolate dynamic data into their content, similar to a Handlebars template. Users are able to write prose like the basic schema, but then add in “tokens” that stay abstract and unbound at authoring time, and then are rendered using data from a different source later. I have an inline token
node that I’ve wired up to represent the binding, and I plan to create an inline expression
node that lets authors operate on tokens in a code-like instead of prose-like fashion.
This is working fine for me so far, but, I realized I will likely need to let users use tokens to populate other node’s or mark’s attrs, instead of them just being child nodes. For example, a user should be able to create a link who’s anchor text is fixed but has an href pointing to data from a token, or a user should be able to create a heading who’s level is the result of an expression on a token.
The way I am inclined to model this would be to make a link’s href
attribute hold a whole other document containing nodes to be evaluated at render time. To edit a link’s href
the editor would pop open a sub-editor, similar to the footnotes example, that edits a separate document that is then toJSON’d and stored in the link’s markup. It’s different than the footnotes example however though because the sub-document isn’t stored just as child nodes of a node in the outer document, but in the attrs of a node or mark. That’d be necessary because the sub-document needs a name so it can be rendered out into the right place (‘href’ in the example), and so that there could be multiple sub documents for nodes that have several programmable attributes.
This plan makes me a little nervous however. Philosophically it seems to be stretching the definition of an attribute a bit far as most attrs seem to be simple, scalar values. Practically it would mean a lot of jerry-rigging of serialization/deserialization, decidedly harder schema validation, and I imagine some serious headaches around getting the history stack to work right between the two living documents, and that’s just what I have thought of so far.
Is there another way to model this that you fine folks could think of that might be better?