[QUEST] Allow plain ES6 classes to be services

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.

[sevab]

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.

[vitch]

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:

Total services: 72
is an object proxy: 0
injects another service: 58 properties in 46 services
computed properties: 149 properties in 52 services
alias: 5 properties in 4 services
readonly: 4 properties in 2 services
involatile computed properties: 148 properties in 52 services
volatile computed properties: 1 properties in 1 services
observers: 1 properties in 1 services
concatenated or merged properties: 0 (?)
actions: 0

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…