Fast jede JavaScript-UI-Bibliothek &/| Das Framework, das ich gesehen habe, hat eine Art Lebenszyklus-Hooks: onmount, willmount, beforemount, aftermount, onunmount, onwhatever.

Brauchen Sie sie wirklich? Sind sie gut oder schlecht? Kann man ohne leben?

Warum gibt es diese überhaupt?

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

Dies ist das typische (langweilige) Initialisierungs-Boilerplate, das viele Web-Komponenten mitbringen und verwenden. Der deklarative Charakter von HTML und CSS zielt darauf ab, diese überflüssig zu machen, mit der Ausnahme, dass es manchmal schwierig oder sogar unmöglich ist, einige Funktionen mit den vorgesehenen Werten voreinzustellen (denken Sie an „disabled="${()=>false}", was nicht einfach der Fall ist). sich so verhalten, wie man es erwarten würde).

Was machen wir also? Legen Sie unbedingt alles fest, was uns noch bleibt, in einem Init-Handler. Es funktioniert und die Welt kann sich weiterentwickeln.

Es gibt jedoch ein wichtiges Problem bei diesem Ansatz. Wenn etwas schief geht, ist es schwierig zu garantieren, dass Ereignis-Listener und andere Dinge ordnungsgemäß bereinigt werden. Das gegebene Framework kann natürlich jeden Onunmount-Hook offenlegen, aber wenn es einen Fehler in der Anwendungslogik gibt, liegt ein Fehler vor, oder schlimmer noch, ein Speicherverlust.

Imperative Programmierung ist ein unglückliches Programmierparadigma, das diesen Situationen völlig ausgesetzt ist. Sie können fast alles tun, auch Dinge kaputtmachen.

Die Lösung kommt mit Inversion of Control und Functional Programming, was nicht zufällig der Art und Weise entspricht, wie HTML und JavaScript konzipiert wurden, aber es gibt eine gute Nachricht: Wir können immer noch einige der grundlegenden Designmuster von FP implementieren und bereitstellen eine strategische Lösung des Problems.

rimmel.js ist eine Referenzimplementierung einer konzeptionellen Obermenge von HTML namens Reactive Markup, die ein wenig wie TypeScript für JavaScript funktioniert, aber darauf abzielt, HTML und das DOM funktional/funktional-reaktiv zu machen.

Dies wird dadurch erreicht, dass alles als Stream behandelt wird: Stil? Es ist ein Bach. DOM-Ereignisse? Natürlich sind es Streams. HTML-Attribute? Auch Streams. Wann immer sie einen Wert ausgeben, wird dieser festgelegt.

Mal sehen, wie es funktioniert.

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

  const template = rml`
    

    
  `;

CreateStream ist nur ein hypothetisches Dienstprogramm zur Stream-Erstellung. Normalerweise möchten Sie stattdessen eher allgemeine Promises- und Observables-RxJS-Streams verwenden, da sie UI-Interaktionen am besten modellieren.

Wenn Sie den Code noch einmal überprüfen, werden Sie schnell feststellen, dass es keinen Onmount-Aufruf gibt. Tatsächlich besteht dafür einfach keine Notwendigkeit, da jeder Vorgang, den ein Onmount-Callback zuvor ausführte, jetzt ausgeführt wird, sobald diese Streams ausgegeben werden.

Jedes Framework oder jede UI-Bibliothek ist dafür verantwortlich, jeden einzelnen Stream, der in den Vorlagen definiert oder gebunden ist, abzuhängen: Stil, Datenschlüssel, Onmouseover. Es besteht keine Gefahr, dass Sie das Aufräumen vergessen, und die Wahrscheinlichkeit von Speicherlecks wird erheblich verringert.

Wenn Sie neu in der funktionalen Programmierung sind, werden Sie wahrscheinlich einige Zeit damit verbringen, zu verstehen, wie Sie Ihre Probleme in Bezug auf Streams neu formulieren können, aber wenn Sie es schaffen, werden im Gegenzug viele weitere Vorteile auf Sie warten, wie zum Beispiel eine drastische Reduzierung Codegröße (50 % bis 90 % weniger Code), viel besser testbare und weniger fehleranfällige Logik und Implementierung.

Bereit für ein exotisches Erlebnis? Schauen Sie sich rimmel.js an