Casi todas las bibliotecas de interfaz de usuario de JavaScript &/| El marco que he visto tiene algún tipo de ganchos de ciclo de vida: onmount, willmount, beforemount, aftermount, onunmount, onwhatever.

¿Realmente los necesitas? ¿Son buenos o malos? ¿Es posible vivir sin?

Entonces, ¿por qué existen, en primer lugar?

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

Este es el típico (aburrido) texto estándar de inicialización que vienen con muchos componentes de la web y que utilizan. La naturaleza declarativa de HTML y CSS tiene como objetivo hacerlos redundantes, excepto que algunas veces es difícil, si no imposible, preestablecer alguna funcionalidad con los valores previstos (piense endisable="${()=>false}" que no solo comportarse como uno esperaría).

Entonces, ¿qué hacemos? Es imperativo configurar lo que nos quede en un controlador de inicio. Funciona y el mundo puede avanzar.

Sin embargo, hay un problema importante con este enfoque. Si algo sale mal, es difícil garantizar que los detectores de eventos y otras cosas se limpien adecuadamente. Por supuesto, el marco proporcionado puede exponer cualquier gancho de desmontaje, pero si hay un error en la lógica de la aplicación, entonces hay un error o, peor aún, una pérdida de memoria.

La programación imperativa es un paradigma de programación desafortunado que está totalmente expuesto a estas situaciones. Puedes hacer casi todo, incluso romper cosas.

La solución viene con inversión de control y programación funcional, que no es la forma en que se concibieron HTML y JavaScript, pero hay buenas noticias: aún podemos implementar algunos de los patrones de diseño fundamentales de FP y proporcionar una solución estratégica al problema.

rimmel.js es una implementación de referencia de un superconjunto conceptual de HTML llamado Reactive Markup, que funciona un poco como TypeScript para JavaScript, pero tiene como objetivo hacer que HTML y el DOM sean funcionales/funcionales-reactivos.

Esto se logra tratando todo como una corriente: ¿estilo? Es una corriente. ¿Eventos DOM? Por supuesto que son corrientes. ¿Atributos HTML? Corrientes también. Cada vez que emiten un valor, se establece.

Veamos cómo funciona.

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

  const template = rml`
    

    
  `;

CreateStream es solo una utilidad hipotética de creación de flujos. Por lo general, querrás usar Promises, Observables RxJS transmite más en general, ya que modelan mejor las interacciones de la interfaz de usuario.

Si revisas el código nuevamente, pronto te darás cuenta de que no hay ninguna llamada montada. De hecho, simplemente no es necesario, ya que cada operación que realizaba anteriormente una devolución de llamada onmount ahora se realizará tan pronto como se emitan esas transmisiones.

Cualquier marco o biblioteca de UI se encargará de desmontar cada flujo que esté definido o vinculado en las plantillas: estilo, clave de datos, onmouseover. No hay riesgo de que se olvide de limpiar y las posibilidades de crear pérdidas de memoria se reducen sustancialmente.

Si eres nuevo en la programación funcional, probablemente dedicarás algún tiempo a comprender cómo reformular tus problemas en términos de flujos, pero cuando lo logres, habrá muchos más beneficios esperándote a cambio, como una reducción dramática tamaño del código (50 % a 90 % menos código), lógica e implementación mucho más comprobables y menos propensas a errores.

¿Listo para vivir una experiencia exótica? Consulte rimmel.js