Living without "lifecycle hooks"

Nearly every JavaScript UI library &/| framework I've seen has some sort of lifecycle hooks: onmount, willmount, beforemount, aftermount, onunmount, onwhatever.

Do you really need them? Are they good or bad? Is it possible to live without?

So, why do these exist, in the first place?

  const oninit = (e: Element) => {
    e.style.prop = value;
    e.addEventListener('mouseover', handler);
    e.setAttribute('data-key', value);
  }

This is the typical (boring) initialisation boilerplate many components for the web come with and make use of. The declarative nature of HTML and CSS are aimed to make these redundant, except some times it's hard if not impossible to preset some functionality with the intended values (think of disabled="${()=>false}" which doesn't just behave as one would expect).

So what we do? Imperatively set whatever we're left with in an init handler. It works and the world can move forward.

There is an important issue with this approach, though. If something goes wrong, it's hard to guarantee event listeners and other things are properly cleaned up. The given framework can of course expose any onunmount hook, but if there is an error in the application logic then you have a bug, or worst, a memory leak.

---

Imperative programming is an unfortunate programming paradigm that is totally exposed to these situations. You can do nearly everything, including breaking stuff.

The solution comes with Inversion of Control and Functional Programming, which doesn't happen to be how HTML and JavaScript have been conceived, but there is good news: we can still implement the some of the foundational design patterns of FP and provide a strategic solution to the problem.

rimmel.js is a reference implementation of a conceptual superset of HTML called Reactive Markup, which works a little like TypeScript for JavaScript, but it's aimed at making HTML and the DOM functional/functional-reactive.

This is achieved by treating everything as a stream: style? It's a stream. DOM events? Of course they are streams. HTML attributes? Streams, too. Whenever they emit a value, that's set.

Let's see how it works.

  const style = CreateStream({color: 'red'});
  const key = CreateStream(value);
  const handler = CreateStream();

  const template = rml`
    <div style="${style}" data-key="${key}" onmouseover="${handler}">
    </div>
  `;

CreateStream is just a hypothetical stream creation utility. Typically you'd want to use Promises, Observables or RxJS streams more in general instead, as they best model UI interactions.

If you check the code again, you'll soon realise there's no onmount attribute. There is no need for it, since every operation the onmount callback was performing earlier, will now be done when the streams emit.

Any given framework or UI library will be in charge of unmounting every single stream that's defined or bound in the templates: style, data-key, onmouseover. There is no risk of you forgetting to clean up and the chances of creating memory leaks is substantially reduced.

If you are new to functional programming you will likely spend some time understanding how to reformulate your problems in terms of streams, but when you manage to, there will be many more benefits waiting for you in exchange, such as a dramatically reduced code size (50% to 90% less code), much more testable and less error-prone logic and implementation.

Ready for a bit of an exotic experience? Check out rimmel.js