SwiftDocOrg / CommonMark

Create, parse, and render Markdown text according to the CommonMark specification
MIT License
179 stars 10 forks source link

Proposal: Move render from Document to Node #16

Closed Lukas-Stuehrk closed 4 years ago

Lukas-Stuehrk commented 4 years ago

Currently, there's no way to render individual nodes if one doesn't want to render an entire document, but only parts of it. Of course one could import cmark and then use the underlying cmark functions to do so, but I think it makes sense to provide a convenient way to do it via CommonMark.

Therefore I suggest that we simply move the existing render(format:options:width) method from Document to Node. The implementation stays exactly the same.

Document is a Node, so it still provides the render method after the change and the straight-forward use case of the library does not change.

What do you think? Please let me know if this does not make sense at all or if you see better ways in implementing it. Or if I did not find the way to render individual nodes 😄.

mattt commented 4 years ago

@Lukas-Stuehrk My initial rationale for this decision was in the spirit of parsimony — I thought it would make sense for Document to be solely responsible for rendering. However, in practice, I've already run into situations where it would have been nice to render nodes individually, which have forced me to create a new document from the description of a node, just to then call render. Woof.

So yeah — you've got the 👍 from me. The only question is what to do with the rendering types. It probably doesn't make sense to keep them nested under Document, so do we move them to Node instead or unnest them as a top-level type? (I favor the latter, making them a top-level type).