Deprecate the usage of Ember.on for Component's lifecycle events. about rfcs HOT 18 CLOSED

Another point against the Ember.on style is that you are forced to choose a key name (doA, doB) for each of the event handlers.

from rfcs.

@givanse which packages are this? Ember.on, for framework hook methods, is widely used in applications in the wild so I'd rather the events that have hook method alternatives to be deprecated.

Yes, I would really like to get critical mass on-board with moving away from these. We burn many extra CPU cycles speculatively trigging a huge number of events during both ember-data models, and ember component lifecycles. Although we do also speculative call the method hooks, those atleast perform much better then the event listener equivalents.

In addition to the perf overhead, the ordering/extended traps these have over just method + super cause real pain, not to mention yet another thing to teach.

from rfcs.

Very happy to close! Thanks.

from rfcs.

and all the on hooks are slow

from rfcs.

FWIW, I've ditched Ember.on a long time ago and I fully support this.

The transition to ES6 classes can be the perfect time, so if glimmer-components includes the changes in the ObjectModel as part of it, I'd push to also use that transition as an opportunity to remove this.

from rfcs.

I'm apparently not in the majority here, but I like .on. Even though, as @mmun points out, you have to choose a key name, I find that far better than having to use this._super. Case and point, there is a bug in your sample code, @givanse:

Ember.Component.extend({
  didInsertElement: function() {
    this._super(...arguments); // You need to return here
  }
});

Without returning the result of this._super, you aren't properly overriding that method. This isn't an issue with the .on style. As for the sequence in which multiple .ons fire, the trivial solution is to put imperative code in a single listener.

My opinions here aren't strong, but this thread was in need of a counter-argument.

from rfcs.

Since on hooks are slow, should the scope be to completely deprecate Ember.on? Doesn't seem to be used that much:

cd emberjs/ember.js
grep -R -e '\.on(' packages/ | wc -l
47
# a couple less than that, the regex is not perfect

Not assuming that is trivial, but it doesn't seem to be all over the place either.

from rfcs.

@givanse which packages are this? Ember.on, for framework hook methods, is widely used in applications in the wild so I'd rather the events that have hook method alternatives to be deprecated.

from rfcs.

It was emberjs/ember.js/packages. (updated the snippet)

Ember.on can be removed by its users over time, just as views were removed. A deprecation warning can be put in place for as long as needed. Aside from wide spread usage what else can be said in favor of .on?

from rfcs.

@givanse it's how you listen to Ember events :P

from rfcs.

For didInsertElement in particular, you don't, but generally speaking, the super may return something other than undefined. And even if the super doesn't return today, it could in the future. This is more prevalent in Ember Data.

from rfcs.

@locks How is that relevant to general commentary on method overriding?

from rfcs.

Whoops, I saw my comments repeated and deleted one of them. They weren't repeated after all.

from rfcs.

As a user who up to this point has avoided overriding lifecycle hooks, I was unaware the use of Ember.on was that bad, I always consider it the safer approach as you didn't have to always remember to call this._super plus I found the super call kind of unergonomic, so I've always recommended people use Ember.on instead. This was mostly because I was bitten by this early on.

Is it worth pursing a more ergonomic alternative to overriding the methods and calling super?

from rfcs.

@stefanpenner when you say the on hooks are slow, have you quantified this? I'm curious to know how much slower the on hooks are from the hook method alternative.

from rfcs.

@DingoEatingFuzz Returning values from a lifecycle hook is something I've never seen done in an Ember application. However, it is possible to find code where the lifecycle hooks will return this (maybe old code in addons, libraries). The main reason for this is that lifecycle hooks are abstract interfaces and they used to be initialized by default with the value Ember.K which is nothing more than a function that returns this. The chaining capabilities of that function didn't really see wide spread usage. And, Ember.K was deprecated.

from rfcs.

It seems like both of the current options have drawbacks and can be prone to bugs in different use cases. _super can cause issues if it is called at the wrong time, with the wrong arguments, or is forgotten. .on can cause issues if there are multiple occurrences of them and the order matters for code execution.

Is there an acceptable API which can avoid both of these issues? Perhaps a dedicated hook like extendDidInsertElement, but with a better name. By default it could maybe call _super with any supplied arguments before running the code inside?

from rfcs.

Thanks everyone for the discussion!
@givanse what do you feel about closing this issue given that Glimmer components are now the default implementation and they do not have lifecycle hooks?

from rfcs.