Move away from Evented for subscriptions

[josemarluedke]

ember-apollo-client uses the Ember mixin Evented to allow users to subscribe to changes coming from a subscription.

Ember is planning to deprecate Evented and Mixins, which are two things we are relying on for subscriptions. Thankfully we already have deprecated the mixin for query manager.

I would like to start thinking about alternatives from the Ember Evented and move away from that as soon as possible.

@coladarci since you are the original implementer of the subscription feature here, what do you think an alternative would look like?

[coladarci]

Is there more than just that RFC to go off of? Doesn’t look like they are definitely moving forward w/ it, that said, our use of Evented is very limited; while it’d be a breaking change, we could easily come up with a new pattern, or eliminate it all together and encourage people to setup their own observer if they want updates

[buschtoens]

I recommend using the exported event utility functions over the mixin, for the following reasons:

• it's fully interoperable with the old mixin based implementations
• it's the general direction Ember is heading (reduce inherited class API surface area and use functions on objects instead), even though the RFC prescribes to remove these functions for Evented as well
• it's easier to refactor / codemod away from, once Evented actually gets removed and the community (hopefully) converges on a new standard event system

API docs: @ember/object/events:

• addListener
• removeListener
• sendEvent

Usage example in one of my recent addons: ember-css-modules-active-route

export default class CssModulesActiveRouteService extends Service {
  @service router!: RouterService & {
    routeWillChange(transition: Transition): void;
    routeDidChange(transition: Transition): void;
  };

  init() {
    super.init();

    addListener(this.router, 'routeWillChange', this.handleRouteChange);
    addListener(this.router, 'routeDidChange', this.handleRouteChange);
  }

  willDestroy() {
    super.willDestroy();

    removeListener(this.router, 'routeWillChange', this.handleRouteChange);
    removeListener(this.router, 'routeDidChange', this.handleRouteChange);
  }

  @action
  handleRouteChange(transition: Transition) {
    // ...
  }
}

[coladarci]

Super cool @buschtoens ; I hadn't seen that before. I'm a little confused though - from your reading are those on the chopping block as well? If not, and it's just the mixin that's going away, this is a great path forward,

[buschtoens]

From the RFC Summary:

This includes deprecating the Evented Mixin, and methods exposed in the @ember/object/events and @ember/object/evented packages.

And further down in Alternatives:

Deprecate only the @ember/object/evented package and Evented Mixin, and keep the @ember/object/events package

So far the RFC is heavily debated and not accepted yet. The only thing we know for sure so far is that Mixins are gonna die in a fire 🔥 eventually. So refactoring away from the Evented mixing will be an improvement in any case.

Since events are still central to Ember and Ember Data itself, I think there will be a "standard" replacement, should @ember/object/events be deprecated. If so, there will also likely be a code mod, which would have an easier time detecting function imports from @ember/object/events as to using methods from the Evented mixin.

[josemarluedke]

Thanks @buschtoens and @coladarci for the ideas. I have created a PR moving away from the mixin but still using ember events. Take a look at it #313 if you have time.

[josemarluedke]

Implemented in #313.