proposal-decorators
proposal-decorators copied to clipboard
tc39
Timeline / proposal for extensions?
This repo has a lot of really great & valuable extensions that could limit boilerplate in a lot of userland reactive libraries (specifically / let & const decorators).
Is there a separate proposal that tracks those?
Parameter decorators are currently in stage 1, being explored here: https://github.com/tc39/proposal-class-method-parameter-decorators
Function decorators are the other major candidate that seems to have enough momentum that they could be included in the language at some point. let/const decorators were discussed before in the plenary briefly, but there was not much appetite for them. We would basically be adding a new getter/setter mechanism to scopes in the language, which is a huge amount of complexity to add, and would make many types of optimizations very difficult.
Personally I'm committed to seeing this proposal and the metadata proposal through the process, and I may try to help with Function decorators after that (given I have the time and energy), but I can't say which, if any, of the proposed extensions will be pursued beyond that.
@pzuraq I think one frustrating thing as a developer is that, had the with keyword not been explicitly forbidden in strict mode, and had ES6 modules not extended strict mode, then reactive variables would have been possible using with + a Proxy object today, without any language additions.
Like, I get that with could be a possible footgun, but it's frustrating that JavaScript used to have features that would have allowed getters / setters on plain variables, and no longer does. I'm just hoping this feature comes back to JavaScript again in the future in a cleaner way.
"Reactive variables" are something that nonzero people consider to be a footgun, myself included.
@ljharb 🤷♂️ Possibly. But it makes UI state updates trivially easy. In the old days, you had to track each and every side effect, and patch manually, or just track nothing and destructively patch everything. And without operator overloading in JavaScript, at least allowing getter / setter on simple assignment / reference would simplify so much real-world code.
@matthew-dean doesn’t that just mean users have to define a class or object with accessors to intercept access to reactive values? Is the goal to enable something like the reactivity in Svelte’s reactive statements?
Svelte reactivity isn't implementable even with reactive variables because Svelte also treats a module as an instantiable thing, like a class.
@justinfagnani Yeah I was going to bring that up, I just am trying to understand the use cases before digging into potential issues, wanna make sure I’m not missing anything.
I definitely want to see function decorators as soon as possible. I tend to favor less object-oriented design patterns in JS.
Object literal and property decorators also interest me, as I use those more than classes.
yes, i also think function decorators would be the most useful.
i also think that const decorators would also be extremely useful, as you can wrap any value into any other value in an extremely simple way.
