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

Create a decorator programming model package #18

Open
ejizba opened this issue Sep 6, 2022 · 0 comments
Open

Create a decorator programming model package #18

ejizba opened this issue Sep 6, 2022 · 0 comments

Comments

@ejizba
Copy link
Contributor

ejizba commented Sep 6, 2022

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:

For

  • Feedback from @sinedied here

    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.

Against

  • Feedback from @ChuckJonas 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.

@ejizba ejizba added feature needs discussion v4 🚀 We no longer use this label since v4 is now the default model. labels Sep 6, 2022
@ejizba ejizba added this to the Backlog Candidates milestone Sep 6, 2022
@ejizba ejizba added P3 and removed v4 🚀 We no longer use this label since v4 is now the default model. labels Oct 10, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant