Further reducing the rendering API #1310
Replies: 2 comments
-
In pre-1.0.0 cheerio, I think it makes a lot of sense to deprecate Given that this hasn't been much of an issue so far, I would also not be opposed to just keeping the current behavior for the sake of backwards-compatibility. |
Beta Was this translation helpful? Give feedback.
-
I agree that we should clean this up. I'm tempted to say we should keep the methods (or at least This may also depend on if we can cleanup I also like the idea of |
Beta Was this translation helpful? Give feedback.
-
My research in gh-1248 makes me think there may be a hazard resulting from our use of two different parsers. We've worked to reduce the number of Cheerio-specific rendering methods to just two functions:
cheerio.html
andcheerio.xml
. This is an improvement over the prior state, but I'm wondering if it goes far enough.In pre-1.0.0 Cheerio, htmlparser2 did all of the parsing and all of the rendering. In
master
, parsing may be done by either htmlparser2 or parse5. By exposing two distinct rendering methods, we're giving consumers the ability to parse in one mode and render in another.For example:
If we further simplified the API to a single method,
cheerio.render
, then we could select the appropriate rendering approach based on the input tree. As long as there are no use cases for the examples demonstrated above, this would eliminate a potential source of confusion.@fb55 @inikulin Does this makes sense to you? Do you think we could reliably infer the correct rendering method based only on the tree being rendered?
Beta Was this translation helpful? Give feedback.
All reactions