Comments (18)
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 .on
s 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.
Related Issues (20)
- NVP todos
- Deprecate all of Ember Classic HOT 16
- Build-time configuration of index.html HOT 3
- Deprecate support for Travis CI HOT 6
- Deprecate `ember-mocha`? HOT 2
- Deprecate `ember-export-application-global` addon? HOT 4
- Run Prettier separately in `app` blueprint HOT 9
- Deprecate `app.import`
- Thoughts on this more ergonomic way to wire up the owner + destroyable association? HOT 2
- Explore "official" pod deprecation HOT 19
- {{else}} should render a value rather than be a control-flow keyword. HOT 5
- new primitive: transition, similar to modifiers, except they block certain render events HOT 2
- Numbers in PR titles affect automation
- Asset import spec RFC HOT 2
- Implement import spec RFC HOT 1
- Replacing `moduleName` in template meta HOT 11
- Simplified imports for common built-in modules HOT 2
- Pre-RFC: Add `aria-current` attribute to Ember's `LinkTo` component HOT 1
- Whitespace handling for `<template>` tag HOT 4
- Add LICENSE
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rfcs.