DEV Community: Raja SK

Demystifying ember-render-modifiers

Raja SK — Tue, 28 Jul 2020 16:35:16 +0000

Ember modifier is one of the coolest features that I see in ember octane. Many ember addons are based on ember modifiers. ember-render-modifier is one of those addons which provides element modifiers that can be used to hook into specific portions of the rendering lifecycle.

One key point that fascinates me about ember-render-modifiers is using this, we can access the basic lifecycle hooks of a component without creating a class for it. That is, we can access them in a template(.hbs) file.

While I stumbled upon this addon, I wanted to explore more. So, I did it and like to share my learnings with you all.

How ember-render-modifier works behind the scene?

Behind the scenes, ember-render-modifiers is nothing but the customModifierManager API which was a low-level API designed especially for addon developers to create and manage custom modifiers.

To know more about Custom Modifier Manager and how they are used to manage ember modifiers, feel free to check out my previous blog.

How do Ember Modifiers get to be managed internally?

Raja SK ・ Jul 14 '20

#javascript #ember

How does a `customModifierManager` look like?

Each modifier manager has four life-cycle methods.

createModifier - creates an instance of the modifier.
installModifier - runs when a modifier is installed on a DOM element.
updateModifier - runs when the arguments passed to the modifier element changes.
destroyModifier - runs just before the element is to be destroyed.

The skeleton of a customModifierManager API looks like

import { setModifierManager, capabilities } from '@ember/modifier';

export default setModifierManager(
  () => ({
    capabilities: capabilities('3.6'),

    createModifier(factory, args) {
      return factory.create(args.named);
    },

    installModifier(instance, element, args) {
      // installation logic...
    },

    updateModifier(instance,args) {
      //re-render logic
    }

    destroyModifier(instance, args) {
      // teardown logic...
    }
  }), class BaseClass {}
);

What are the modifiers provided by `ember-render-modifiers`?

did-insert - runs when the element is inserted in the DOM.
did-update - runs when the element's arguments changes
will-destroy - runs when the element is destroyed.

Along with this, if we see the customModifierManager API's skeleton, we can able to understand how ember-render-modifiers are implemented.

Each modifier in this addon uses its respective lifecycle method of the customModiferManager API and runs the function passed to the modifier within that method itself.

did-insert => installModifier
did-update => updateModifier
will-destroy => destroyModifier

Let's take the did-insert modifier.

export default setModifierManager(
  () => ({
    capabilities: capabilities('3.13', { disableAutoTracking: true }),

    createModifier() {},

    installModifier(_state, element, args) {
      let [fn, ...positional] = args.positional;

      fn(element, positional, args.named);
    },

    updateModifier() {},
    destroyModifier() {},
  }),
  class DidInsertModifier {}
);

Here, the main logic lies inside the installModifier and the other two lifecycle methods are left empty.

Similarly, in the did-update modifier, the logic lies inside the updateModifier and the state maintenance is done by installModifier

export default setModifierManager(
  () => ({
    capabilities: capabilities('3.13', { disableAutoTracking: true }),

    createModifier() {
      return { element: null };
    },
    installModifier(state, element) {
      // save element into state bucket
      state.element = element;
    },

    updateModifier({ element }, args) {
      let [fn, ...positional] = args.positional;

      fn(element, positional, args.named);
    },

    destroyModifier() {},
  }),
  class DidUpdateModifier {}
);

Also, in the will-destroy modifier, the logic lies inside the destroyModifier and installModifier is used to maintain state.

export default setModifierManager(
  () => ({
    capabilities: capabilities('3.13', { disableAutoTracking: true }),

    createModifier() {
      return { element: null };
    },

    installModifier(state, element) {
      state.element = element;
    },

    updateModifier() {},

    destroyModifier({ element }, args) {
      let [fn, ...positional] = args.positional;

      fn(element, positional, args.named);
    },
  }),
  class WillDestroyModifier {}
);

Among several addons that are based on ember modifier, this ember-render-modifier is one of its kind and easy to understand the implementation.

There are so many ways to play with ember modifiers. This addon is a small drop that ember modifiers can do. You can also play with your thoughts on ember modifiers and create some custom modifiers.

Hope you find my learnings on ember-render-modifiers informative. See you all in my next blog! 👋

The magic behind the ember modifiers

Raja SK — Tue, 21 Jul 2020 15:25:02 +0000

Prerequisites:

Before moving on to our topic, let's recap some basic stuff about ember modifiers from my previous blogs.

Explanation about ember modifiers and how they are used to achieve reusable DOM behavior are in the following post.

Reusable DOM behavior in React vs Ember

Raja SK ・ Jul 7 '20 ・ 4 min read

#javascript #ember #react
Each ember modifier should be managed by an ember modifier manager. To explore more, check out my other blog.

How do Ember Modifiers get to be managed internally?

Raja SK ・ Jul 14 '20 ・ 6 min read

#javascript #ember

If you're familiar with these topics, feel free to skip this part.

Now, let's move on to our topic.

So far, IMO, ember modifiers are one of the extraordinary features of ember octane. While working with ember modifiers recently, I was questioning myself on:

How does ember Modifiers do the magic on Reusable DOM behavior?

Come on! Let's solve the mystery together by replicating the ember modifiers through plain javascript.

Ember has both functional and class-based modifiers.

Let's break down the functional modifiers.

Create an `autofocus` modifier to just focus an element.

File: `modifiers/autofocus.js`

export default function autofocus(element) {
  element.focus();
  return () => {
    console.log("destroy"); // Dummy log to simulate the teardown logic
  };
}

As we know, every ember modifiers will be managed by a modifier manager. Also, every modifier manager should have these four methods:

createModifier
installModifier
updateModifier
destroyModifier

Create a functional modifier manager.

Now, we need to create a functional modifier manager class with the above-mentioned methods.

Before that, we need two WeakMaps here:

MODIFIER_ELEMENTS - to map the element with the modifier.
MODIFIER_TEARDOWNS - to map the teardown logic with the modifier

const MODIFIER_ELEMENTS = new WeakMap();
const MODIFIER_TEARDOWNS = new WeakMap();

Teardown logic is nothing but the piece of code given in the return of modifier function. To set this in MODIFIER_TEARDOWNS, we need to have a setup method that runs the modifier and maps the returned value with the modifier.

function setup(modifier, element, args) {
  const { positional, named } = args;
  const teardown = modifier(element, positional, named);
  MODIFIER_TEARDOWNS.set(modifier, teardown);
}

Some modifiers won't have any teardown logic. So we need a separate function teardown to check if the teardown present in MODIFIER_TEARDOWNS is a function and then access it.

function teardown(modifier) {
  const teardown = MODIFIER_TEARDOWNS.get(modifier);
  if (teardown && typeof teardown === "function") {
    teardown();
  }
}

Now, Let's create the FunctionalModifierManager class with the above-mentioned lifecycle methods.

class FunctionalModifierManager {
  createModifier(factory) {
    return (...args) => factory(...args);
  }
  installModifier(modifier, element, args) {
    MODIFIER_ELEMENTS.set(modifier, element);
    setup(modifier, element, args);
  }
  updateModifier(modifier, args) {
    teardown(modifier);
    const element = MODIFIER_ELEMENTS.get(modifier);
    setup(modifier, element, args);
  }
  destroyModifier(modifier) {
    teardown(modifier);
  }
}

Let's see what these four methods trying to do.

createModifier - simply returns the modifier instance.
installModifier - maps the element with the modifier in the MODIFIER_ELEMENTS WeakMap. Also calls the setup method to map the teardown logic with the modifier in MODIFIER_TEARDOWNS WeakMap.
updateModifier - runs the teardown logic once to remove the outdated modifier mapping and maps the element with the updated modifier in the MODIFIER_ELEMENTS WeakMap.
destroyModifier - runs the teardown logic to completely remove the mapping between the modifier and the element.

Combining the above snippets will form our functional-modifier-manager.js file.

File: `functional-modifier-manager.js`

const MODIFIER_ELEMENTS = new WeakMap();
const MODIFIER_TEARDOWNS = new WeakMap();

function setup(modifier, element, args) {
  const { positional, named } = args;
  const teardown = modifier(element, positional, named);
  MODIFIER_TEARDOWNS.set(modifier, teardown);
}

function teardown(modifier) {
  const teardown = MODIFIER_TEARDOWNS.get(modifier);
  if (teardown && typeof teardown === "function") {
    teardown();
  }
}

export default class FunctionalModifierManager {
  createModifier(factory) {
    return (...args) => factory(...args);
  }
  installModifier(modifier, element, args) {
    MODIFIER_ELEMENTS.set(modifier, element);
    setup(modifier, element, args);
  }
  updateModifier(modifier, args) {
    teardown(modifier);
    const element = MODIFIER_ELEMENTS.get(modifier);
    setup(modifier, element, args);
  }
  destroyModifier(modifier) {
    teardown(modifier);
  }
}

How do ember modifier and ember modifier manager communicate?

Custom Modifier Manager acts as a middleman between the ember modifier and the ember modifier manager.

We need CustomModifierState to maintain the state for the CustomModifierManager.

class CustomModifierState {
  constructor(element, delegate, modifier, args) {
    this.element = element;
    this.delegate = delegate;
    this.modifier = modifier;
    this.args = args;
  }

  destroy() {
    var { delegate, modifier, args } = this;
    delegate.destroyModifier(modifier, args);
  }
}

Let's decode the properties of this class.

element - element on which the modifier is applied.
delegate - an instance of the modifier manager (functional modifier manager).
modifier - modifier definition (autofocus function).
args - a snapshot of the arguments passed while invoking the modifier in hbs.
destroy() - used to trigger destroyModifier method of the delegate(functional modifier manager).

Now, Let's create our CustomModifierManager class.

class CustomModifierManager {
  create(element, definition, args) {
    var { delegate, ModifierClass } = definition;
    var instance = delegate.createModifier(ModifierClass, args);
    return new CustomModifierState(element, delegate, instance, args);
  }
  install(state) {
    var { delegate, modifier, element, args } = state;
    delegate.installModifier(modifier, element, args);
  }
  update(state) {
    var { delegate, modifier, args } = state;
    delegate.updateModifier(modifier, args);
  }
  getDestructor(state) {
    return state;
  }

Here,

create() - triggers the createModifier method of the FunctionalModifierManager which will provide the instance of the modifier function. Also, this method returns an instance of the CustomModifierState which has information about the element, delegate, instance, and args.
install() - triggers the installModifier method of the FunctionalModifierManager.
update() - triggers the updateModifier method of the FunctionalModifierManager.
getDestructor() - returns the state in which we can access the destroy method to trigger the destroyModifier method of the FunctionalModifierManager.

Combining these two classes, our custom-modifier-manager.js file would look like

File: `custom-modifier-manager.js`

class CustomModifierState {
  constructor(element, delegate, modifier, args) {
    this.element = element;
    this.delegate = delegate;
    this.modifier = modifier;
    this.args = args;
  }

  destroy() {
    var { delegate, modifier, args } = this;
    delegate.destroyModifier(modifier, args);
  }
}

export default class CustomModifierManager {
  create(element, definition, args) {
    var { delegate, ModifierClass } = definition;
    var instance = delegate.createModifier(ModifierClass, args);
    return new CustomModifierState(element, delegate, instance, args);
  }
  install(state) {
    var { delegate, modifier, element, args } = state;
    delegate.installModifier(modifier, element, args);
  }
  update(state) {
    var { delegate, modifier, args } = state;
    delegate.updateModifier(modifier, args);
  }
  getDestructor(state) {
    return state;
  }

Implementing `index.js` file.

As of now, we have created the overall logic behind the ember functional modifiers. Let's move on to our main fileindex.js

1. Import necessary files

import autofocus from "./modifiers/autofocus";
import FunctionalModifierManager from "./functional-modifier-manager";
import CustomModifierManager from "./custom-modifier-manager";

2. Ember component implementation

Let's assume this as an ember component with a render method which helps to render the elements in the DOM.

class EmberComponent {
  render(...elements) {
    document.getElementById("app").innerHTML = "<div>Hello!</div>";
    document.getElementById("app").append(...elements);
  }
}

3. Instantiate the `EmberComponent` and call render with an input element.

var componentInstance = new EmberComponent();
var inputElement = document.createElement("input");
componentInstance.render(inputElement);

4. Instantiate CustomModifierManager

var FUNC_CUSTOM_MODIFIER = new CustomModifierManager();

5. Get the state using FUNC_CUSTOM_MODIFIER.create()

var funcModifierState = FUNC_CUSTOM_MODIFIER.create(
  inputElement,
  {
    delegate: funcManager,
    ModifierClass: autofocus
  },
  {}
);

Here, create() method accepts three arguments.

element - inputElement is the element on which modifier is applied.
definition - delegate and modifierClass together.
args - {}

This will return an instance of the customModifierState.

6. Install the modifier on the element using FUNC_CUSTOM_MODIFIER.install()

FUNC_CUSTOM_MODIFIER.install(funcModifierState);

Finally, our index.js file will look like

File: `index.js`

import autofocus from "./modifiers/autofocus";
import FunctionalModifierManager from "./functional-modifier-manager";
import CustomModifierManager from "./custom-modifier-manager";

class EmberComponent {
  render(...elements) {
    document.getElementById("app").innerHTML = "<div>Hello!</div>";
    document.getElementById("app").append(...elements);
  }
}

var componentInstance = new EmberComponent();
var inputElement = document.createElement("input");
componentInstance.render(inputElement);

var FUNC_CUSTOM_MODIFIER = new CustomModifierManager();

var funcModifierState = FUNC_CUSTOM_MODIFIER.create(
  inputElement,
  {
    delegate: funcManager,
    ModifierClass: autofocus
  },
  {}
);

FUNC_CUSTOM_MODIFIER.install(funcModifierState);

Additionally, if we want to simulate the update and destroy,

update

FUNC_CUSTOM_MODIFIER.update(funcModifierState);

destroy

We can access the destroy() method through the getDestructor() method which returns the CustomModifierState containing the destroy() method.

FUNC_CUSTOM_MODIFIER.getDestructor(funcModifierState).destroy();

We are only one step ahead to see the magic ✨ of ember modifiers.

Include the index.js script in index.html and see the magic.

File: `index.html`

<!DOCTYPE html>
<html>
<head>
  <title>Parcel Sandbox</title>
  <meta charset="UTF-8" />
</head>
<body>
  <div id="app"></div>
  <script src="src/index.js">
  </script>
</body>
</html>

Hurray! The input element was focused automatically.

Apart from this, I've experimented with on modifier as a class-based-modifier through plain javascript and combined with the implementation we've done so far in this codesandbox

Normally, we won't come across these implementations because Ember, as a framework, does its job in keeping those implementations away from us. But still, I find it interesting and useful to learn the internal working and redoing it with plain javascript. It was pretty exciting! 🤩

Hope you enjoyed getting to know the behind the scenes of ember modifiers. See you in my next blog! 👋

How do Ember Modifiers get to be managed internally?

Raja SK — Tue, 14 Jul 2020 11:35:05 +0000

To know about ember modifiers and how they are used to achieve reusable DOM behaviors in ember, feel free to check my previous blog which compares the reusable DOM behavior in ember and react.

Now let's get into our topic: How do Ember modifiers get to be managed internally?

The answer is through Element modifier manager!

In ember, an element modifier manager is an object which is responsible for coordinating the life cycle events that occur when invoking, installing, and updating element modifiers.

Each element modifier needs a modifier manager that could be set by setModifierManager() API, which is a low-level API provided by the ember specifically for addon developers.

setModifierManager takes two parameters.

A function that takes an Owner and returns an instance of a manager.
The base class that applications would extend from.

When do we need this `setModifierManagaer` API?

By default, the modifier manager would already be assigned to a super-class provided by the framework or an addon.
But, while developing some addons like ember-render-modifiers, we need setModifierManager() API to create a custom modifier manager.

Modifier Lifecycle

createModifier()
installModifier()
updateModifier()
destroyModifier()

Before diving deeper into the modifier lifecycle, we need to know that in every modifier, there should be

Installation logic
Teardown logic

Installation logic is a piece of code that has to be executed when the element is installed to the DOM(the main modifier logic).

Teardown logic is a piece of code that has to be executed when the element is removed from the DOM.

`createModifier`

At first, to create an instance of a modifier, ember will invoke the modifier manager's createModifier method.

createModifier(factory, args) {
  return factory.create(args);
}

This method is responsible for returning an instantiated modifier which will be passed as an argument to the other three lifecycle methods.

A small tip 💡 on how args is constructed inside ember.

args object will have two properties.

positional (will be an array)
named (will be an object)

Let's say, we have canShow = true and pass this to a tool-tip modifier

{{tool-tip canShow text="This is a tooltip"}}

The args object will be constructed as

args: {
  positional: [true],
  named: {
    text: "This is a tooltip"
  }
}

`installModifier`

After the modifier instance is created, the installModifier method is responsible for giving access to the underlying element and the arguments to the modifier instance.

Here, we need the installation logic.

installModifier(instance, element, args) {
  // installation logic ...
}

The first argument instance is the result of createModifier. The second is the element on which the modifier is defined. The third is the snapshot of the args which we discussed earlier.

`updateModifier`

When any of the arguments passed to the modifier changes, ember invokes the updateModifier() method to allow the manager to reflect those changes on the modifier instance, before re-rendering.

First, we have to do the teardown logic for removing the instance with the old values.
Then, we have to do the installation logic for installing the new one.

updateModifier(instance, args) {
  // teardown logic...
  // installation logic...
}

Here, we didn't get element as an argument because we have already installed this modifier on the element through installModifier method.

`destroyModifier`

When the element on which the modifier is defined is going to be destroyed (removed from the DOM), ember invokes this destroyModifier() method to perform the cleanup.

Teardown logic alone does the job here.

destroyModifier(instance, args) {
  // teardown logic...
}

How do ember know which ember version does this modifier manager targets?

Through capabilities property. It should be the result of the capabilities() function provided by ember.

The first and the mandatory argument to the capabilities() function is the ${major}.${minor} format (eg 3.6), matching the minimum Ember version this manager is targeting.
It also accepts another argument, which is an object containing optional features.

This allows Ember to introduce new capabilities and make improvements to this setModifierManager API without breaking the existing code.

Now, we have managed to create a skeleton of setModifierManager API.

import { setModifierManager, capabilities } from '@ember/modifier';

export default setModifierManager(
  () => ({
    capabilities: capabilities('3.6'),

    createModifier(factory, args) {
      return factory.create(args.named);
    },

    installModifier(instance, element, args) {
      // installation logic...
    },

    updateModifier(instance,args) {
      // teardown logic...
      // installation logic...
    }

    destroyModifier(instance, args) {
      // teardown logic...
    }
  }), class BaseClass {}
);

Let's create our custom tooltip modifier manager.

In this tooltip modifier, we need to do two processes

Add tooltip when the cursor moves into the element (mouseover event).
Remove tooltip when the cursor moves out of the element (mouseleave event).

Add Tooltip

addTooltip(event) {
  let element = event.target;
  let text = element.getAttribute('data-tooltip');
  let tooltipContent = document.getElementById('tooltip-content');
  if (!tooltipContent) {
    let tooltipElement = document.createElement('span');
    tooltipElement.setAttribute('id', 'tooltip-content');
    tooltipElement.innerHTML = text;
    element.appendChild(tooltipElement);
  }
}

Here, we are getting the tooltip text from data-tooltip attribute of the element and we have created an element with id tooltip-content and appended it to the element.

Remove Tooltip

removeTooltip(event) {
  let element = event.target;
  let tooltipContent = document.getElementById('tooltip-content');
  if(tooltipContent) {
    element.removeChild(tooltipContent);
  }
}

Here, we are removing the element with the id tooltip-content from the element.

Now, we need to incorporate the two logics.

Installation logic

Here, it is nothing but adding the event listeners - mouseover and mouseleave.

installationLogic(element) {
  element.addEventListener('mouseover', this.addTooltip);
  element.addEventListener('mouseleave', this.removeTooltip);
}

Teardown Logic

In this case, we have to remove the added event listeners in the teardown logic.

tearDownLogic(element) {
  element.removeEventListener('mouseover', this.addTooltip);
  element.removeEventListener('mouseleave', this.removeTooltip);
}

Now we have to define the lifecycle methods.

In the createModifier method, we have to return the state which would be passed as the instance argument for the other three lifecycle methods. Here, we just need to return null for the element property.

createModifier() {
  return {
    element: null,
  };
}

Next, we have to perform the installation logic on the installModifier method. Also, we can store the text on the element's data-tooltip attribute.

installModifier(instance, element, args) {
  let { named: { text }} = args;
  element.setAttribute('data-tooltip', text);
  instance.element = element;
  this.installationLogic(element);
}

updateModifier gets triggered only when the args change. So, here we need to do the teardown logic to destroy the old values and perform the installation logic to install a new one.

updateModifier(state, args) {
  let { element } = state;
  let { named: { text }} = args;
  element.setAttribute('data-tooltip', text);
  this.tearDownLogic(element);
  this.installationLogic(element);
}

At last, we need to define the destroyModifier method in which the teardown logic must be called to remove the modifier from the element.

destroyModifier(state) {
  let { element } = state;
  this.tearDownLogic(element);
}

We can set capabilities as capabilities('3.13').
Now, combining all these, we can get our tooltip custom modifier manager.

File: app/modifiers/tooltip.js

import { setModifierManager, capabilities } from '@ember/modifier';

export default setModifierManager(
  () => ({

    addTooltip(event) {
      let element = event.target;
      let text = element.getAttribute('data-tooltip');
      let tooltipContent = document.getElementById('tooltip-content');
      if (!tooltipContent) {
        let tooltipElement = document.createElement('span');
        tooltipElement.setAttribute('id', 'tooltip-content');
        tooltipElement.innerHTML = text;
        element.appendChild(tooltipElement);
      }
    },

    removeTooltip(event) {
      let element = event.target;
      let tooltipContent = document.getElementById('tooltip-content');
      if(tooltipContent) {
        element.removeChild(tooltipContent);
      }
    },

    installationLogic(element) {
      element.addEventListener('mouseover', this.addTooltip);
      element.addEventListener('mouseleave', this.removeTooltip);
    },

    tearDownLogic(element) {
      element.removeEventListener('mouseover', this.addTooltip);
      element.removeEventListener('mouseleave', this.removeTooltip);
    },

    /*--------- Modifier manager function starts here -----------*/

    capabilities: capabilities('3.13'),
    createModifier() {
      return {
        element: null,
      };
    },

    installModifier(state, element, args) {
      let { named: { text }} = args;
      element.setAttribute('data-tooltip', text);
      state.element = element;
      this.installationLogic(element);
    },

    updateModifier(state, args) {
      let { element } = state;
      let { named: { text }} = args;
      element.setAttribute('data-tooltip', text);
      this.tearDownLogic(element);
      this.installationLogic(element);
    },

    destroyModifier(state) {
      let { element } = state;
      this.tearDownLogic(element);
    }
  }),
  class TooltipModifierManager {}
)

The class TooltipModifierManager is added because haven't defined a base class, we would run into an error. Rather we have defined it empty.

That's all. Our tooltip modifier is ready to be invoked as

<span {{tooltip text=this.tooltipText}}>Tooltip</span>

For reference, check out this twiddle that I've created.

Also, feel free to drop off your queries (if any) in the discussion.

Up next ⚠️

Wanna know how exciting it could be to replicate ember modifiers in vanilla JS? Wait! We can work along in my next blog! 👋

Reusable DOM behavior in React vs Ember

Raja SK — Tue, 07 Jul 2020 07:05:11 +0000

As a developer, while writing some common logic of code, our mind would have thought of the following question.

"How we are gonna share these code between several components". 🤔

In case, if the logic of the code handles DOM behavior(i.e., the block of code which triggers when an element is added, updated or removed from the DOM tree), the answer is pretty simple - reusable DOM behavior.

Each framework handles it differently. Let's just dig into React and Ember and see how they handle it.

How does React achieve it?

React's class-based components handles DOM behavior through the following lifecycle hooks:

componentDidMount - fires when the component is inserted to the DOM
componentDidUpdate - fires when the component is being re-rendered.
componentWillUnmount - fires just before a component is being removed from the DOM.

React's functional components manages to do this with a single hook - useEffect.

useEffect() => {
  // logic when component is rendered and re-rendered...
  // replaces componentDidMount and componentDidUpdate

  return () => {
    // teardown logic...
    // replaces componentWillUnmount
  }
}

We can reuse this useEffect hook by creating a custom hook and importing it wherever we want.

How does Ember fills the gap?

In classic ember, generally, a mixin is a group of logic that can be reused in multiple places.DOM behaviors can also be reused through component mixins with the help of component lifecycle hooks.

We can write a mixin named tabs.js like this

import Mixin from '@ember/object/mixin';

export default Mixin.create({
  didInsertElement() {
    this._super();
    activateTabs(this.element);
  }

  willDestroyElement() {
    this._super();
    deactivateTabs(this.element);
  }
})

and consume the Tabs mixin like this

import Component from '@ember/component';

export default Component.extend(Tabs, {
  // ...
});

Now, Ember Octane comes with a better solution - `ember-modifiers`.

Ember modifiers are just like the helpers in ember but the difference is that the former applies directly to an element and the latter is passed as an attribute to an element.

We can access the modifiers using the double curly-braces {{}} syntax.

Ember modifiers can be implemented in two ways.

Ember functional modifier
Ember class-based modifier

As in every other framework, functional implementation is way simpler than class-based implementation, but the latter provides more control.

Syntax for ember functional modifiers - overall same as the useEffect in react.

export default modifierName((element, positional, named) => {
  // do side effects...
  return () => {
    //teardown logic
  }
}

Syntax for ember class-based modifiers - same as the react class-based component hooks.

export default class ModifierName extends Modifier {
  didReceiveArguments() {
    // do side effects...
  }
  willRemove() {
    // teardown logic
  }
}

If we have a thought that ember modifiers are new to ember, then we have probably missed something while working with ember. We may come across two syntaxes for invoking action in templates.
This one demonstrates an action helper.

<button onclick={{action "handleClick"}}> Click Me! </button>

And this demonstrates an action modifier (one of the inbuilt ember modifiers).

<button {{action "handleclick"}}> Click Me! </button>

Oh! I've worked with a modifier without even knowing it's a modifier. 😅

Let's say, we need an autofocus modifier which when applied to an element, should focus the element on every render.

File: app/modifiers/autofocus.js - functional implementation

export default function autofocus((element) => {
  element.focus();
}

We can easily apply this modifier to as many elements as we want.

File: app/components/my-component.hbs

<input value=this.value {{autofocus}} />

This approach to autofocus has a huge advantage over the HTML input element's autofocus attribute. This autofocus modifier gets triggered for each render and re-render of that element. But the autofocus attribute gets triggered only on the first render.

Advantages of ember modifiers over ember mixins

1. Modifiers allow targeting specific elements easily.

In case of mixins, if we need to apply the mixin to an element inside a component, then we have to make that element as a separate component and extend the js class with that mixin. This will create chaos.
Ember modifiers can be applied to any element we want without making it a separate component.

2. Modifiers work with template only components.

Without a js file, the mixins are useless. They have no place to be extended.
Modifiers are invoked only in the templates. There is no need for a js file.

3. Modifiers work with tag-less components and Glimmer components.

Nowadays, Tag-less components have lifecycle hooks, but they don't have this.element in it. Glimmer components also don't have a wrapping element and hence no this.element.

With mixins, it is hard to do the DOM manipulations.
With modifiers, we can simply have the logic in a modifier file separately and invoke it in the template file alone.

Which one wins? React's `useEffect()` hook or `ember modifiers`?

Both do the same jobs in their respective environments and it's hard to compare them. But, ember modifiers allow us to grab the element directly through arguments. This can't be done in useEffect() hook without the help of other hooks like useRef().

Through this point, ember proves one more time that it is more of an organized framework, which handles most of the stuff internally and makes the end-developer care more on other kinds of stuff.

Up next ⚠️

Curious about how ember modifiers get to be managed internally? Go through my next blog ! 👋

DEV Community: Raja SK

Demystifying ember-render-modifiers

How ember-render-modifier works behind the scene?

How do Ember Modifiers get to be managed internally?

Raja SK ・ Jul 14 '20

How does a customModifierManager look like?

What are the modifiers provided by ember-render-modifiers?

The magic behind the ember modifiers

Prerequisites:

Reusable DOM behavior in React vs Ember

Raja SK ・ Jul 7 '20 ・ 4 min read

How do Ember Modifiers get to be managed internally?

Raja SK ・ Jul 14 '20 ・ 6 min read

How does ember Modifiers do the magic on Reusable DOM behavior?

Let's break down the functional modifiers.

Create an autofocus modifier to just focus an element.

File: modifiers/autofocus.js

Create a functional modifier manager.

File: functional-modifier-manager.js

How do ember modifier and ember modifier manager communicate?

File: custom-modifier-manager.js

Implementing index.js file.

1. Import necessary files

2. Ember component implementation

3. Instantiate the EmberComponent and call render with an input element.

4. Instantiate CustomModifierManager

5. Get the state using FUNC_CUSTOM_MODIFIER.create()

6. Install the modifier on the element using FUNC_CUSTOM_MODIFIER.install()

File: index.js

update

destroy

We are only one step ahead to see the magic ✨ of ember modifiers.

File: index.html

How do Ember Modifiers get to be managed internally?

When do we need this setModifierManagaer API?

Modifier Lifecycle

createModifier

installModifier

updateModifier

destroyModifier

How do ember know which ember version does this modifier manager targets?

Let's create our custom tooltip modifier manager.

Add Tooltip

Remove Tooltip

Installation logic

Teardown Logic

Up next ⚠️

Reusable DOM behavior in React vs Ember

How does React achieve it?

How does Ember fills the gap?

Now, Ember Octane comes with a better solution - ember-modifiers.

Advantages of ember modifiers over ember mixins

1. Modifiers allow targeting specific elements easily.

2. Modifiers work with template only components.

3. Modifiers work with tag-less components and Glimmer components.

Which one wins? React's useEffect() hook or ember modifiers?

Up next ⚠️

How does a `customModifierManager` look like?

What are the modifiers provided by `ember-render-modifiers`?

Create an `autofocus` modifier to just focus an element.

File: `modifiers/autofocus.js`

File: `functional-modifier-manager.js`

File: `custom-modifier-manager.js`

Implementing `index.js` file.

3. Instantiate the `EmberComponent` and call render with an input element.

File: `index.js`

File: `index.html`

When do we need this `setModifierManagaer` API?

`createModifier`

`installModifier`

`updateModifier`

`destroyModifier`

Now, Ember Octane comes with a better solution - `ember-modifiers`.

Which one wins? React's `useEffect()` hook or `ember modifiers`?