Closed RebeccaStevens closed 1 year ago
Also, the conversion is inefficient. It should produce a proper iterable, not convert it into array, similar to how reverse was done, but just forward, not backwards.
So I have refactored the implementation to return a proper iterable, and I moved it up, into object condition, because any ArrayLike is always an object, as far as I know.
We still need a test for it.
And, I'm thinking, should we not add the same into toAsync? :wink:
Base: 99.75% // Head: 99.45% // Decreases project coverage by -0.30%
:warning:
Coverage data is based on head (
ed2b0a6
) compared to base (56daaad
). Patch coverage: 25.00% of modified lines in pull request are covered.
:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.
I have added a test also.
@RebeccaStevens Please review my changes, and review/refactor, as you wish.
Ok, I'm merging it as is. I also think that we should not do anything for async here.
If you see a need for improvement, please follow up with another PR ;)
I've set this up to work for the sync case. The async case will be a little more complicated.
However, I'm not sure if this is worth pursuing as it can lead to false matches users will not be expecting. The only way we can test if something is array-like is by seeing if it has a
length
property and that it is an integer. However, it is quite plausible for an object to meet that criteria without being array-like. We'd need to add an escape hatch for this case, which would be more work than it's worth imo.