bustle
Mobiledoc Format Changes (roll-up issue)
This issue tracks potential changes to make to the mobiledoc format in the next release:
- [ ] #477 make node types unique so that alternate renders unambiguously know what node type they are looking at
- [ ] Consider allowing for additional metadata to be included with markers and markup sections
- [ ] Allow arbitrarily deeply nested list item sections (via a "depth" property that could be added in the metadata or otherwise memorialized in the format)
- [ ] Expand the allowed markup section tag names and markup tag names and allowed markup attributes (#473 #451 #346 #342)
Nested sections is interesting, have you thought about how that could be implemented? I'm wondering if something like a sectionsToClose indicator similar to markers would work.
I see a lot of power coming from a homogeneous (or close to it) node structure, especially when it comes to renderers -- not just alternate ones, but keeping the core renderer(s) up to date with new Mobiledoc formats. I'll probably have more to say on this once I work through the React renderer, but I can imagine a future where rendering happens in two stages: first validate/customize/transform a mobiledoc into a generic intermediary tree, and then do the final projection into the target markup.
That makes it easier to supply alternate renderers, since they're only concerned with walking a known structure. And when the format does change you only have to update the core plumbing once; each "last-mile" renderer only needs to be taught about changes to the intermediary tree.
Oh, actually the nested is mostly just aimed at allowed arbitrarily nested lists (I'll update the description above). I'm not sure if I see use cases for nested sections of arbitrary type (although I'd be curious if that's a use case anyone else envisions having).
I haven't thought it through too carefully but the general idea was that instead of list items being nested in the mobiledoc inside of "listSection" type sections, they would be at the top-level (alongside all other section types), with a "depth" (numeric) value. Two list item sections with the same depth side-by-side would be rendered as two items in the same list (ul>li+li), and items with a depth greater than 1 would be the responsibility of the renderer to wrap with successive lists (i.e. a list item section with depth 2 would be rendered as ul>li>ul>li). This would complicate the renderer somewhat, but it would a) be nice for multiply-nested lists to be possible in mobiledoc and b) would likely simplify the internals a great deal (the fact that some top-level sections — list sections — are not markerable or directly addressable by cursor causes probably more complication in mobiledoc-kit's internals than we would like to have). The open question is how much this would complicate renderers. If you have any feedback, especially thoughts about how it might impact your react renderer, I'd love to hear it.
I can imagine a future where rendering happens in two stages: first validate/customize/transform a mobiledoc into a generic intermediary tree, and then do the final projection into the target markup.
I like the sound of this. And thinking about it now, nested list items may not actually impact alternate renders very much; the validate/transform function would simply unroll the list items into the appropriate nested tree structure before handing it off to the last-mile renderer. ?
the validate/transform function would simply unroll the list items into the appropriate nested tree structure before handing it off to the last-mile renderer
That sounds right to me. I'd suggested using something like a sectionsToClose counter because it's already a procedural description of a nested structure. A depth indicator on list items probably isn't any harder to unroll, it just means the renderer has to know how to unroll different structures. I actually think the biggest factor here might just be whatever makes it easiest to write the mobiledoc in the first place.
Re: a two-stage renderer, my plan is to work through the React renderer and then try to extract just the React-specific portions, leaving stage 1 pluggable with e.g. a DOM target instead. No idea how it'll go, but I'll let you know! 😁
Per the 1.0 planning doc I think we've decided to execute a subset of this list: https://docs.google.com/document/d/1Tn3XdADu50Q0VStF5sIeUqlEDWqRJRX5-ZFwUKJ4ZS8/edit
I'm kind of inclined to close this, not because the discussion isn't valuable (it has been) but because I'm not sure this describes the steps forward we intend to take.
