Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Start RFC to deprecate the use of Ember Evented in Ember Data #329
Awesome, I'm definitely in favor of this!
Some smallish things that I think we should clarify in the RFC are:
May 1, 2018
If the idea behind this RFC is to strive towards ES classes rsp. allowing a better "programming model" to narrow the gap to traditional OOP-related programming languages and their design patterns then I'd say
Removing events in favor of overwritable methods sounds good to me as this is what happened with components afair.
@dwickern there is already a path forward for ember-data-change-tracker with the ModelData RFC.
@btecu using the
@joukevandermaas Can you provide an example use of
@gossi lifecycle methods have been debated before for models; however, for the most part there isn't a clear conceptual model for what the lifecycle of a model even is. That said, the
@runspired anything that has side-effects really, which is the reason to use lifecycle hooks generally. For example, kicking off a long-running task. Are you saying there is overhead to
Side-effect driven development isn't something we seek to support. Kicking off additional work from the promise returned when fetching a record would achieve the same thing in a non-side-effect way. If you seek to centralize this pattern then fetching via a service that has these known additional behaviors would provide a clear abstraction.
Yes. Evented accounts for somewhere between 10 and 30% of our cost to instantiate a record and an even higher percentage of the cost when mutating a record, this even after we did things to make it substantially faster around version 2.10.
At a superficial level, the answer for this difference is that Components have a clear lifecyle, which makes certain patterns easy to optimize. Models do not. At a deeper level the specific issue is that in order to support these events we had to add significant complex anti-patterns throughout the internals. This has made the internals difficult for even regular contributors to understand, and prevented many needed optimizations from taking place.