You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Creating a rollup issue to start collecting all the feedback we've been getting on decorators (there's a lot, and it's often conflicting). The idea is we can create a separate npm package (@azure/functions-decorators?) that lets you register functions using decorators.
As a bit of background, Node.js has a stage 3 proposal for decorators here. TypeScript has older support for decorators, which is still labeled experimental but has received a decent amount of adoption already. As the Node.js proposal puts it:
Unfortunately, we're in the classic trap of, "The old thing is deprecated, and the new thing is not ready yet!" For now, best to keep using the old thing.
We pretty quickly decided we would not be able to use decorators for the first iteration of the new programming model package because of the above complicated state. However, we could still explore a preview package with decorator support.
Here is a summary of some of the conflicting feedback we've received:
I would suggest thinking of how the new API model could leverage TS to make it a first class citizen. For example, I would push forward TS decorators as a way to define bindings and other functions settings. I know decorators' TC39 proposal is currently only stage 2, and TS decorators are already diverging a bit from that proposal. But as syntactic sugar, they're unmatched and AFAIK all most popular TS-first frameworks tools use decorators: Angular, NestJS, TypeORM, TypeGraphQL, Loopback, Ts.ED...
the fact is that decorators are hugely popular in all TS-first Node.js libs. This is what I think is the most important point here.
IMO, decorators don't bring much other than just making the code read closer what whats done in C#. It feels like the ts community has shifted away from OOO in favor of more functional code (decorators are only supported on classes). Current approach seems more flexible and composable.
Even some .NET people don't want decorators - see here
I came to this need because I find myself defining many functions very similar to each other, having the same binding types but requiring different values in the bindings, e.g.
...
So, instead of copying the functions over and over again, I'd love to automate this process.
The text was updated successfully, but these errors were encountered:
Creating a rollup issue to start collecting all the feedback we've been getting on decorators (there's a lot, and it's often conflicting). The idea is we can create a separate npm package (
@azure/functions-decorators
?) that lets you register functions using decorators.As a bit of background, Node.js has a stage 3 proposal for decorators here. TypeScript has older support for decorators, which is still labeled experimental but has received a decent amount of adoption already. As the Node.js proposal puts it:
We pretty quickly decided we would not be able to use decorators for the first iteration of the new programming model package because of the above complicated state. However, we could still explore a preview package with decorator support.
Here is a summary of some of the conflicting feedback we've received:
For
Feedback from @sinedied here
Against
Feedback from @ChuckJonas here
Even some .NET people don't want decorators - see here
The text was updated successfully, but these errors were encountered: