machty / ember-concurrency

ember-concurrency is an Ember Addon that enables you to write concise, worry-free, cancelable, restartable, asynchronous tasks.
http://ember-concurrency.com
MIT License
691 stars 155 forks source link

Decorators in JavaScript project #511

Closed DavertMik closed 4 months ago

DavertMik commented 1 year ago

When we started using ember-concurrency the decorators were a recommended way of handling tasks Recently the API was changed with this note:

Previous versions of Ember Concurrency recommended decorators-based APIs for declaring tasks, but these APIs are no longer recommended due to decorators not playing nicely with TypeScript-based APIs.

So I have a few questions:

Thanks for the answers and for the great library!

machty commented 1 year ago

I asked about this in the topic-typescript discord channel: https://discord.com/channels/480462759797063690/484421406659182603/1067597807080448032

My question:

is TypeScript the official or unofficial "future" of Ember? It feels like it is, and that as a general rule you'll have a happier time using Ember with TS if you avoid decorators-centric APIs

but I guess I haven't heard this confirmed anywhere

Chris Krycho's response:

No: the way we’ve said it (including in the RFCs) is that it is an officially-supported language, not the officially-supported language, and it will remain so. It and JS are and will remain peers for the foreseeable future: no one, myself or the rest of the Ember TS team, has any intent of doing the Angular “must use TS” thing.

Eventually I expect decorators to be able to work usefully in some way with TS types. The first round of support for the (Stage 3 at last!) ES Decorators will land in TS 5.0, coming in February.

The bigger issue you all are going to have with ember-concurrency is that you’re going to have to rewrite your decorators (and we’re going to have to migrate the whole community off of the old Stage 1 decorators to the Stage 3 decorators).

That said, the future of Ember itself is “must play nicely with TypeScript,” so the way to think about API designs (like those for ember-concurrency) is that if they don’t work for TS users, you’ll increasingly be cutting off a large part of your user base.

I personally am pushing/evolving my company's codebase to TypeScript, and even though I hear decorator support in TS will be improved, the experience thus far has pushed me away from decorators-based APIs. So, I'd say: decorator-based EC APIs won't be removed any time soon, but I'm not going to be pushing them strongly because I don't like having these competing decorator- and non-decorator-based APIs competing with each other.