Почти каждая библиотека пользовательского интерфейса JavaScript &/| В фреймворке, который я видел, есть какие-то перехватчики жизненного цикла: onmount, willmount, beforemount, aftermount, onunmount, onwhatever.

Они вам действительно нужны? Они хорошие или плохие? Можно ли жить без?

Итак, почему они вообще существуют?

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

Это типичный (скучный) шаблон инициализации, который поставляется и используется многими веб-компонентами. Декларативная природа HTML и CSS направлена ​​на то, чтобы сделать их избыточными, за исключением того, что иногда бывает сложно, если не невозможно, заранее задать некоторые функции с заданными значениями (подумайте о отключении = "${()=>false}", что не просто вести себя так, как и следовало ожидать).

И что нам делать? Императивно установите все, что у нас осталось, в обработчике инициализации. Это работает, и мир может двигаться вперед.

Однако с этим подходом есть важная проблема. Если что-то пойдет не так, трудно гарантировать, что прослушиватели событий и другие вещи будут правильно очищены. Данная платформа, конечно, может предоставить любой перехват onunmount, но если в логике приложения есть ошибка, значит, у вас есть ошибка или, что еще хуже, утечка памяти.

Императивное программирование — это неудачная парадигма программирования, которая полностью подвержена подобным ситуациям. Вы можете делать практически все, в том числе ломать вещи.

Решение включает в себя инверсию управления и функциональное программирование, что не соответствует тому, как были задуманы HTML и JavaScript, но есть и хорошие новости: мы все еще можем реализовать некоторые из основополагающих шаблонов проектирования FP и обеспечить стратегическое решение проблемы.

rimmel.js — это эталонная реализация концептуального расширенного набора HTML под названием Reactive Markup, который немного похож на TypeScript для JavaScript, но его цель — сделать HTML и DOM функциональными/функционально-реактивными.

Это достигается за счет рассмотрения всего как потока: стиль? Это поток. DOM-события? Конечно, это потоки. HTML-атрибуты? Потоки тоже. Всякий раз, когда они выдают значение, оно устанавливается.

Давайте посмотрим, как это работает.

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

  const template = rml`
    

    
  `;

CreateStream — это всего лишь гипотетическая утилита для создания потоков. Обычно вместо этого лучше использовать Promises, Observables RxJS, поскольку они лучше всего моделируют взаимодействие с пользовательским интерфейсом.

Если вы еще раз проверите код, вы скоро поймете, что вызова onmount нет. На самом деле в этом просто нет необходимости, поскольку каждая операция, которую ранее выполнял обратный вызов onmount, теперь будет выполнена, как только эти потоки отправят данные.

Любая платформа или библиотека пользовательского интерфейса будет отвечать за отмонтирование каждого отдельного потока, определенного или привязанного в шаблонах: стиль, ключ данных, onmouseover. Риск того, что вы забудете выполнить очистку, отсутствует, а вероятность возникновения утечек памяти существенно снижается.

Если вы новичок в функциональном программировании, вы, вероятно, потратите некоторое время на то, чтобы понять, как переформулировать свои проблемы в терминах потоков, но когда вам это удастся, взамен вас будет ждать гораздо больше преимуществ, таких как резкое сокращение размер кода (на 50–90 % меньше кода), гораздо более тестируемая и менее подверженная ошибкам логика и реализация.

Готовы к экзотическим впечатлениям? Проверьте rimmel.js