-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Prototype as independent npm package for feedback? #5
Comments
I'm not a fan of |
I'd actually recommend making this a separate package until it becomes Stage 3 or 4. Putting this into core-js and monkey-patching the built-ins risks making it harder for us to iterate on changes. |
I don't think that adding it to |
Well, lots of project maintainers have explicitly said that they don't guarantee stability over certain time periods, and then the JS spec ends up being held back due to wide deployment anyway--Mootools is a classic example. But this is a bigger discussion independent of Array.prototype.select/reject that we should discuss elsewhere. |
For this case is no difference is it a big project from which you could optionally include this polyfill or a small independent package. |
These already exist as lodash/underscore functions, and data is at #4. Note lodash no longer has
I think that would hamstring the data. Ease of use is required here, and swapping from functional to prototype is a nuisance: const array = select(
input.map(e => e.value),
(value) => predicate(value)
).find(value => match(value))
The only details for this proposal is the name, though. |
So, because it would be an unfair disadvantage, you're suggesting that we use other kinds of evidence to decide without direct experience? Maybe that could work with these very small proposals, but I don't think it's a good idea for standard library features most of the time. |
The object filtering?
I'm suggesting that I would just make a prototype polyfill, if anything. But I doubt people will install either version. They'll just use lodash's functions, or they'll stick to the "official" method and change their predicate to match what's needed.
I don't think there is any data to collect here. I'm proposing an alias, and an opposite behavior of an already spec'd feature. The proposal's spec won't change, only the naming. We can certainly bikeshed the naming with everyone, but I don't think that's going to be useful. I've chosen the names with precedent in the ecosystem. |
Totally agree with that! This is a very important issue and apply to all proposals relate to prototype methods/accessors. I really hope we can revive bind operator which can help to solve "how to experiment and get real feedback for prototype methods" issue. |
I think it'd be great if, prior to Stage 2 (or at least Stage 3), this could be prototyped as an independent package on npm, so we can get some real-world feedback on how people like it.
IMO, it would be best to do this as a module exporting these two things as functions, rather than monkey-patching onto the Array.prototype, for the reasons described in Andrew Betts' essay Polyfills and the evolution of the Web.
Even if similar features are available elsewhere, and we have a good understanding from that experience that it would be a good idea, this prototype may give us some more data on the details we select in this proposal.
The text was updated successfully, but these errors were encountered: