Skip to content

Latest commit

 

History

History
56 lines (41 loc) · 2.6 KB

no-at-ember-render-modifiers.md

File metadata and controls

56 lines (41 loc) · 2.6 KB
Raw

ember/no-at-ember-render-modifiers

What's wrong with {{did-insert}}, {{did-update}}, and {{will-destroy}}?

These modifiers were meant for temporary migration purposes for quickly migrating @ember/component from before Octane to the @glimmer/component we have today. Since @ember/component implicitly had a wrapping div around each component and @glimmer/components have "outer HTML" semantics, an automated migration could have ended up looking something like:

<div
  {{did-insert this.doInsertBehavior}}
  {{did-update this.doUpdateBehavior @arg1 @arg2}}
  {{will-destroy this.doDestroyBehavior}}
>
  ...
</div>

It was intended that this would be a temporary step to help get folks off of @ember/components quickly in early 2020 when folks migrated to the Octane editon, but some folks continued using these modifiers.

Additionally, this style of mananging data flow has some flaws:

  • an element is required
    • this can be mitigated by using helpers, but they have the same problems mentioned below
  • the behavior that is used with these modifiers can cause extra renders and infinite rendering loops
    • this is the nature of "effect"-driven development / data-flow, every time an effect runs, rendering must re-occur.
  • behavior that needs to be co-located is spread out, making maintenance and debugging harder
    • each part of the responsibility of a "behavior" or "feature" is spread out, making it harder to find and comprehend the full picture of that behavior or feature.

Examples

This rule forbids the following:

import didInsert from '@ember/render-modifiers/modifiers/did-insert';
import didUpdate from '@ember/render-modifiers/modifiers/did-update';
import willDestroy from '@ember/render-modifiers/modifiers/will-destroy';

For more examples, see the docs on ember-template-lint.

References