Closed Lukas-Stuehrk closed 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).
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 fromDocument
toNode
. 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 😄.