[QUEST] Allow plain ES6 classes to be services #16134
Description
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 from Ember.Object or Ember.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 create method that takes the owner, 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.set to 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-decorators every time they use bare classes, we should probably pull enough into Ember proper to avoid that. For example, we could add a @tracked decorator for fields that (for the moment) calls Ember.set under 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
- Identify limitations in the current support for ES classes (🔒 @pzuraq)
- Fix or defer them
- Write an RFC for dependency injecting outside of old-style Ember classes (🔒 @wycats)
- Survey real-world apps for use of Ember object model features in services
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:
Total services: <count>
is an object proxy: <count>
injects another service: <count>
alias: <count>
readonly: <count>
non-volatile computed properties: <count>
observers: <count>
concatenated or merged properties: <count>
actions: <count>
For example, this is my survey of Skylight:
Total services: 9
is an object proxy: 1
injects another service: 3
alias: 1
readonly: 1
computed properties (not volatile): 0
observers: 0
concatenated or merged properties: 0
actions: 0
Hang out in Community Slack
We'll be coordinating this work on the community slack. You can join the #st-es-class-services channel.