|
| 1 | +# ember/no-at-ember-render-modifiers |
| 2 | + |
| 3 | +<!-- end auto-generated rule header --> |
| 4 | + |
| 5 | +What's wrong with `{{did-insert}}`, `{{did-update}}`, and `{{will-destroy}}`? |
| 6 | + |
| 7 | +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/component`s have "outer HTML" semantics, an automated migration could have ended up looking something like: |
| 8 | + |
| 9 | +```hbs |
| 10 | +<div |
| 11 | + {{did-insert this.doInsertBehavior}} |
| 12 | + {{did-update this.doUpdateBehavior @arg1 @arg2}} |
| 13 | + {{will-destroy this.doDestroyBehavior}} |
| 14 | +> |
| 15 | + ... |
| 16 | +</div> |
| 17 | +``` |
| 18 | + |
| 19 | +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. |
| 20 | + |
| 21 | +Additionally, this style of mananging data flow has some flaws: |
| 22 | + |
| 23 | +- an element is required |
| 24 | + - this can be mitigated by using helpers, but they have the same problems mentioned below |
| 25 | +- the behavior that is used with these modifiers can cause extra renders and infinite rendering loops |
| 26 | + - this is the nature of "effect"-driven development / data-flow, every time an effect runs, rendering must re-occur. |
| 27 | +- behavior that needs to be co-located is spread out, making maintenance and debugging harder |
| 28 | + - 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. |
| 29 | + |
| 30 | +## Examples |
| 31 | + |
| 32 | +This rule **forbids** the following: |
| 33 | + |
| 34 | +```js |
| 35 | +import didInsert from '@ember/render-modifiers/modifiers/did-insert'; |
| 36 | +``` |
| 37 | + |
| 38 | +```js |
| 39 | +import didUpdate from '@ember/render-modifiers/modifiers/did-update'; |
| 40 | +``` |
| 41 | + |
| 42 | +```js |
| 43 | +import willDestroy from '@ember/render-modifiers/modifiers/will-destroy'; |
| 44 | +``` |
| 45 | + |
| 46 | +For more examples, see [the docs on ember-template-lint](https://github.com/ember-template-lint/ember-template-lint/blob/master/docs/rule/no-at-ember-render-modifiers.md). |
| 47 | + |
| 48 | +## References |
| 49 | + |
| 50 | +- [Editions](https://emberjs.com/editions/) |
| 51 | +- [Octane Upgrade Guide](https://guides.emberjs.com/release/upgrading/current-edition/) |
| 52 | +- [Component Documentation](https://guides.emberjs.com/release/components/) |
| 53 | +- [Avoiding Lifecycle in Component](https://nullvoxpopuli.com/avoiding-lifecycle) |
| 54 | +- [The `ember-template-lint` version of this rule](https://github.com/ember-template-lint/ember-template-lint/blob/master/docs/rule/no-at-ember-render-modifiers.md) |
| 55 | +- [`ember-modifier`](https://github.com/ember-modifier/ember-modifier) |
| 56 | +- [`@ember/render-modifiers`](https://github.com/emberjs/ember-render-modifiers) (deprecated) |
0 commit comments