[QUEST] Allow plain ES6 classes to be services #16134
Comments
|
Awesome to see this! Here is my survey. This does not include services provided by add-ons, which is about 6 more services. |
|
Here is our app output, |
|
Three production apps surveys: As @josemarluedke, this does not include services provided by add-ons. |
|
Intercom (numbers are counts of services, eg. 16 services use |
👉 Actions are techincally just methods, called using the bind helper from templates. |
|
Here is data on 2 of the more complex apps at Yapp: App 1: Total services: 18 App 2: Total services: 26 Also, several services mix in Ember.Evented and have ember-concurrency tasks |
|
Here's data on our core app at TradeGecko Total services: 72 As well as several ember-concurrency tasks, and one usage of |
|
One of our internal apps: Total services: 15 |
|
App 1 |
not counting addons, numbers are number of services that use one or more of these features, not total count of instances |
|
|
Total services: 36 |
|
For the Heroku dashboard: |
|
For https://digitalroots.com / https://interactions.com |
|
For MinuteBase For Kayako |
|
@pzuraq this is great work. Keep em coming! |
|
App 1 App 2 (older) |
|
Hey, exciting work! For
I wasn’t sure about “is an object proxy”; some services are extensions of others, but I think that isn’t what you mean? I also wasn’t sure whether “non-volatile computed properties” should include |
|
@backspace "is an object proxy" means |
|
|
Counts for Ghost: |
|
TradeGecko total services and computed properties are going to grow by quite a few more. |
|
This is great! It looks like by far the dominant use-cases are:
That's really great news, because those features have a clearer path to direct migration to ES6 classes than some other features of the Ember object model (like concatenated properties). Keep the surveys coming. |
|
What about actions on services. I think this feature might be unused mainly due to education and that most people don't know about I'd love for actions to work with functions and be bound to the parent object by default, that would prevent having to need an |
|
@knownasilya My personal opinion is that, in modern Ember, actions are just functions, and that the point of the |
I'd suggest at this point, for simple binding purposes that folks should use the
TBH, I don't think its this simple. We might be writing "new code" by authoring a replacement for an existing concept (consider refactoring to a service from a controller). When the "new code" we are talking about is template code: I totally agree! But to have to refactor any number of my templates simply to refactor to a service seems non-ideal. |
|
|
Total services: 18 is an object proxy: 0 injects another service: 10 alias: 0 readonly: 0 computed properties (not volatile): 6 observers: 0 concatenated or merged properties: 0 actions: 2 |
|
|
Total services: 47 |
|
|
|
Olo’s main Ember app (~20k LoC in the |
|
|
I wrote a simple ruby script as part of Ember London's Meetup Quest Night to test all services against the listed features: https://gist.github.com/sevab/497ead350f25e82c5034686c6b163192 Matches Ghost's results. Feel free to try against your apps by dropping and running the file at the root of the project. |
|
I was also at the Ember London's Meetup Quest Night and put together a script to generate these counts... Mine is javascript and you can paste it into the web developer console next to any running ember app and it should find the ember app and introspect it and output the relevant info. https://gist.github.com/vitch/591d022359bd392535c15c715a59e81a Here's the output from one of our apps: The script is hacked together and may not work on all ember apps or all versions of ember but hopefully it's a useful start. It would be pretty easy to extend it to output additional information if desired... |
Another of our apps: |
|
I should have mentioned before too many people use the script... I wasn't clear on what "concatenated or merged properties" was meant to represent so that will always output "0 (?)" for now! If someone can tell me what it's meant to represent I can update the script. I can also try to add information about the Evented Mixin if that's useful. And I was thinking it might be nice to distinguish services defined in the app from those defined in addons? |
|
Concatenated and merged properties are a feature of the object model that’s mainly used for components, controllers, and routes. Examples are It’s actually possible (but highly unrecommended) to define your own properties that do this. We didn’t expect anyone to be using this feature, but wanted to make sure. |
|
I wasn't sure how they manifested themselves on the services but there seems to be I updated my script to output information about these as well and here's the updated list from one of our apps: |
|
@wycats Is there a Discord channel this work continues on?
|
|
@pixelhandler most of the active work is happening in The goals have shifted a bit from just services without a base class to using native classes with the Ember Object model for the time being, with a longer-term outlook outlined in the Native Class Roadmap RFC |
|
@pzuraq should this one be closed? |
|
I think so, we should double check with @wycats but I think baseless native classes still need to be fleshed out and maybe RFCd before we can move forward with them |
|
The cheese has been thoroughly moved and this issue can be considered stale. |
and others
Now that the ES2015 classes RFC has been merged, it's time to take advantage of the internal cleanup to allow Ember applications to use ES2015 classes in their applications.
We're going to start with services because the Service superclass is an empty subclass from
Ember.Object.However, there are still a number of things to work out.
Context and Background
First of all, not all of the functionality of the RFC has yet been implemented. For the most part, the problems are minor and related to
.extend()ing an ES2015 subclass of an Ember superclass. Since this quest is about using basic ES2015 classes that do not extend fromEmber.ObjectorEmber.Service, it is not directly relevant, but @pzuraq is working on identifying these limitations and writing failing tests for them.Second, in order to support simple objects, we will need to decide on the public API for dependency injecting into ES classes, which requires deciding on a stable public API for dependency injection in general. The smallest incremental step is to expect a static
createmethod that takes theowner, but we might want to do a little more than that. I'll take responsibility for writing an RFC.Finally, we will need to decide how to handle computed properties in these news classes. The most incremental step is to not support computed properties directly in Ember and still require
Ember.setto set properties directly on services. The ember-decorators addon could be used to get sugar for those features.However, if we expect people to feel that they need to use
ember-decoratorsevery time they use bare classes, we should probably pull enough into Ember proper to avoid that. For example, we could add a@trackeddecorator for fields that (for the moment) callsEmber.setunder the hood. We will all need to review our own apps to decide how many services in the real world rely a lot on Ember object model features.Current Status and Work Items
The most useful thing that you could do right now is go through your app and survey all of your services for the use of certain features:
For example, this is my survey of Skylight:
Hang out in Community Slack
We'll be coordinating this work on the community slack. You can join the #st-es-class-services channel.
The text was updated successfully, but these errors were encountered: