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
Decorator standard library #54
Comments
Just putting this here for the future...one thing I'd like to see in a standard library is a decorator to create a soft-private field or method. It would be simple for anyone to implement on their own, but the naming could get confusing if different people call it different things in different codebases, e.g. |
I would prefer this be left to the ecosystem for everything that doesn't map to property descriptor fields for now ( |
What about seal/extensible/frozen, and decorator placement, let alone autobinding? I think it would be a big mistake to leave a gap like this in the feature and cause ecosystem fragmentation for known-common use cases. |
@ljharb I have concerns about those and see them as non-trivial. |
What concerns? |
For: @freeze
class A {} @seal
class A {} Extending those classes would not allow adding properties, but does allow adding private fields. This seems something to at least discuss. WeakMaps get around frozen stuff as well so it might not be so controversial. Also timing is something I'd like to discuss here, if it should freeze during the constructor or when Also, those feel kind of odd without Object literal decorators to me. For autobinding, I think public fields kind of remove most of the usefulness of that decorator. I could be wrong, but would want to discuss if it is giving reasonable gains to put into the standard library. |
Specifically regarding autobinding, see my PR where I explained its advantages over arrow functions in class fields...specifically the "Notes on the |
@mbrowne while I agree that there are cases where arrow functions are not ideal, I'm not convinced that |
This is true of builtins already; all the collections, as well as Promise, and RegExp’s internal state via .compile - it’s been discussed previously and i don’t think there are any problems there. Class decorator timing is already determined iirc, altho i don’t recall it off the top of my head. Object literal decorators seem super helpful and an important followon, but that’s imo even more of a reason to ship standard decorators now - then, if any changes are needed for object literal decorators, we can ship those instead of having not-fully-compatible implementations in the wild. As for bound being preferable to arrow functions, i can dredge up dozens of issues with enzyme (the canonical react testing lib) that demonstrate that arrow functions in class properties are a general antipattern (one the airbnb guide will be banning once an eslint rule is created, fwiw) |
Since there is disagreement on these, I want to discuss it. I'm open to adding things as standard library features, but don't think doing so on first iteration is necessary. We also haven't even talked about where the references to these decorators would live. |
@bmeck, at the last meeting I discussed this with @littledan about a solution that would work. I put together a rough outline of the approach in a gist. |
I think there might be value in something like an |
I'm not sure how this discussion belongs in the decorators proposal exactly. This is more a property of what |
At the January 2018 TC39 meeting, during the decorators presentation, the committee discussed a possible decorators standard library.
Would it make sense to sketch out, at an explainer level, what such a library might contain? Or, are we entirely content with leaving this to ecosystem-level solutions (e.g., core-decorators)?
At the time, some people in committee seemed to be advocating for a decorators standard library to be part of the this proposal, while others were suggesting that it would make more sense to wait until decorators are shipped for a while and see what JavaScript programmers find useful for themselves.
A compromise might be to aim to develop a Stage 1 proposal for a decorator standard library while this decorators proposal is at Stage 2 or 3. Even if it stays at Stage 1 for a while, such a standard library might be a useful design for polyfills and gain usage organically that way.
The text was updated successfully, but these errors were encountered: