You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Note: Not relevant for [email protected] — this is about versions after that.
When thinking about how a future version of Cheerio might look like, one idea I keep getting back at is to have Cheerio extend JS's native Array (ie. class Cheerio extend Array {}). This would be a change with a lot of breakages, and I am not sure if this is the right approach for Cheerio. My current thinking:
Pro
Contra
Easier to learn interface ("more powerful arrays")
Knowledge from jQuery wouldn't transfer over
Automatic inheritance of all new Array methods
Existing pitch ("jQuery for the server") would have to change
New code looks more idiomatic
Breakage of existing code
That said, here is a (probably incomplete) list of changes that would have to happen:
Methods with different signatures
All function arguments would have their parameter order changed. Eg. .map would take a function (el: T, index: number) => U rather than (this: T, index: number, el: T) => U.
Non-functions inputs for eg. .filter would still be supported and behave the way they currently do.
.map would no longer flatten the input (there is .flatMap for that)
Removed methods
.each: Users can use .forEach
.index: We would transfer the behavior to an overridden .indexOf.
.find
.find is an interesting case, and my main concern. In Cheerio, find traverses the current selection and returns a new collection of found elements. The array find method looks through the current collection and returns the first element that matches a condition.
As both the behavior and the return value are different, having Cheerio's behavior override the existing function doesn't make too much sense to me. Instead, Cheerio's .find would have to be renamed to something else.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Note: Not relevant for
[email protected]
— this is about versions after that.When thinking about how a future version of Cheerio might look like, one idea I keep getting back at is to have Cheerio extend JS's native
Array
(ie.class Cheerio extend Array {}
). This would be a change with a lot of breakages, and I am not sure if this is the right approach for Cheerio. My current thinking:That said, here is a (probably incomplete) list of changes that would have to happen:
Methods with different signatures
.map
would take a function(el: T, index: number) => U
rather than(this: T, index: number, el: T) => U
..filter
would still be supported and behave the way they currently do..map
would no longer flatten the input (there is.flatMap
for that)Removed methods
.each
: Users can use.forEach
.index
: We would transfer the behavior to an overridden.indexOf
..find
.find
is an interesting case, and my main concern. In Cheerio,find
traverses the current selection and returns a new collection of found elements. The arrayfind
method looks through the current collection and returns the first element that matches a condition.As both the behavior and the return value are different, having Cheerio's behavior override the existing function doesn't make too much sense to me. Instead, Cheerio's
.find
would have to be renamed to something else.Beta Was this translation helpful? Give feedback.
All reactions