Skip to content
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

Open
littledan opened this issue Nov 15, 2019 · 9 comments
Open

Prototype as independent npm package for feedback? #5

littledan opened this issue Nov 15, 2019 · 9 comments

Comments

@littledan
Copy link
Member

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.

@zloirock
Copy link
Contributor

I'm not a fan of .select, so I don't want to add it before the next stage to core-js.

@littledan
Copy link
Member Author

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.

@zloirock
Copy link
Contributor

I don't think that adding it to core-js could cause any serious problems since it could be added as a proposal, not to the standard subset of features and could not cause any serious problems with the current core-js policy about breaking changes (only in major releases) since I don't see any serious possible changes in the spec text, but I'm too skeptical about adding an alias to .filter - for me and many other users .select alias is even more non-obvious.

@littledan
Copy link
Member Author

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.

@zloirock
Copy link
Contributor

For this case is no difference is it a big project from which you could optionally include this polyfill or a small independent package. core-js tries to prevent possible related problems, however, completely prevent them is not possible. Definitely, it's should be discussed in another place.

@jridgewell
Copy link
Member

it would be best to do this as a module exporting these two things as functions

These already exist as lodash/underscore functions, and data is at #4. Note lodash no longer has _.select, but it's easy enough for an aliased import: import select from 'lodash.filter', though I don't imagine many would do that since "filter" is the official name.

rather than monkey-patching onto the Array.prototype

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))

this prototype may give us some more data on the details we select in this proposal.

The only details for this proposal is the name, though. select (or any name we choose) must be implemented the same as filter, and reject (or filterOut) must be the opposite of filter's predicate.

@littledan
Copy link
Member Author

These already exist as lodash/underscore functions, and data is at #4.

Array.prototype.reject is a bit different from _.reject in its semantics, so I'm not sure if it's really comparable.

I think that would hamstring the data.

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.

@jridgewell
Copy link
Member

Array.prototype.reject is a bit different from _.reject in its semantics, so I'm not sure if it's really comparable.

The object filtering?

So, because it would be an unfair disadvantage, you're suggesting that we use other kinds of evidence to decide without direct experience?

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.

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.

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.

@hax
Copy link
Member

hax commented Nov 20, 2019

Ease of use is required here, and swapping from functional to prototype is a nuisance

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants