Hallo, das ist wieder Katya von Yandex.Money. Ich setze meine Geschichte darüber fort, wie ich aufgehört habe mich zu schminken und angefangen habe zu leben. Im ersten Teil habe ich erzählt, wie ich hierher gekommen bin und was unsere Front-End-Entwickler tun. Heute - über den Frontstack, woher kommt React und wohin ist BEM gegangen?

Spoiler: BEM ist nirgendwo hingegangen ¯ \ _ (ツ) _ / ¯. Lass uns gehen!



Achtung: hohe Konzentration des Frontends. Viel Text, Bilder und Code, wie versprochen.

Teil 2. Über Technologie

Far 2016. Der Versuch, in React zu schreiben, stellt sich als ziemlich erträglich heraus. Ich vermute immer noch nicht, dass ich in einem Jahr ganze Dienste an React übertragen werde. 2017 beginnt auf Yandex.Money, ich habe einen BEM des Gehirns und ich vermute immer noch nicht.

Backend auf Node.js, mein erstes Mal

Um sich mit dem Projekt vertraut zu machen, erhält ein neuer Entwickler eine Testaufgabe. Ich hatte Glück: Ich hatte diese Aufgabe aus dem Rückstand. Und am ersten Tag traf ich auf Node.js.

Das Front-End in Yandex.Money ist nicht nur für die Clientseite verantwortlich, sondern auch für die Serverschicht als Node.js-Anwendung. Die Aufgabe der Anwendung besteht darin, Daten aus dem Java-Backend für die Vorbereitung in einer ansichtsorientierten Form sowie für das Rendern und Routing von Servern zu orchestrieren. Sie hätten dies vor ein paar Jahren erfahren, ich hätte nichts verstanden, und alles ist ganz einfach: Wenn eine Anfrage vom Browser an den Server kommt, generiert Node.js HTTP-Anfragen für das Backend, empfängt die erforderlichen Daten und Vorlagen-Webseiten. Wir verwenden Express als Server-Framework und für die Entwicklung interner Anwendungen ohne Legacy- Link haben wir uns für Koa2 entschieden . Die Entwickler waren vom Design des Frameworks begeistert, und wir entschieden uns, kein Downgrade auf Express durchzuführen, sodass Koa2 auf dem Stack blieb. Wir stellen Koa2-Code jedoch nicht für externe Benutzer bereit: Das Framework bietet nicht genügend Unterstützung, es gibt jedoch offene Sicherheitslücken.

Wir haben bereits über den Platz von Node.js in unserem Frontend geschrieben, aber seitdem hat sich etwas geändert. Node.js 8 wurde zu LTS und läuft bereits auf unseren Produktionsservern. Wir möchten auch Nginx-Server aufgeben, die wir auf jedem Host zur Verteilung der Statik aufrufen. Sie werden durch separate Server mit Nginx und eines Tages CDN ersetzt.

Um Code zwischen Projekten zu fummeln, aber nicht öffentlich verfügbar zu machen, verwenden wir eine ganze Reihe von Tools: Speichern Sie die Module in Bitbucket und sammeln Sie sie in Jenkins. Wir verwenden auch die lokale Registrierung von Paketen und gehen dank dieser nicht zum externen Netzwerk - dies beschleunigt die Montage und erhöht die Sicherheit des gesamten Systems. Dieser Ansatz wurde uns von den Javisten vorgeschlagen, sie sind cool. Liebe deine Backender;)

Wir haben auch ein Experiment durchgeführt - wir haben einen Prozessmanager in eine der Anwendungen eingeführt, der die Verwaltung von Diensten auf Node.js vereinfacht hat. Er half beim Clustering und rettete uns auch vor einem alten Bash-Skript, auf dem Anwendungen ausgeführt wurden.

Und der ganze Stapel reicht nicht aus

Wir haben überall im Frontend Javascript. Und auf dem Server und auf dem Client und unter der Haube interner Tools. Wir kennen andere Sprachen, aber Javascript macht einen tollen Job.

Aber BEM im Rahmen unserer Aufgaben bewältigt nicht alles.


Aus diesem Grund haben wir begonnen, Dienste an React zu übertragen. Einige von ihnen leben bereits in zwei Anwendungen, die auf unterschiedlichen Stapeln basieren:

- eine Plattform speziell für Yandex BEM;
- Das junge und modische Ökosystem von React.

Yandex Technologies

Es ist Zeit, Ihnen zu sagen, warum ich mich in BEM verliebt habe.

Neudefinitionsebenen

Levels, Levels, Levels ... BEM! Gewinn!
Überschreibende Ebenen sind eines der Hauptmerkmale der BEM-Methodik. Schauen Sie sich das Bild an, um zu verstehen, wie sie funktionieren:


Das Bild wird durch Überlagern von Ebenen erzeugt. Jede Ebene ändert das endgültige Bild, die anderen Ebenen jedoch nicht. Die Ebene kann leicht herausgezogen oder hinzugefügt werden, und das Bild ändert sich.
Override-Levels machen dasselbe mit Code:


Das Verhalten der Komponente wird während der Code-Assemblierung gebildet. Um zusätzliches Verhalten hinzuzufügen, verbinden Sie einfach die gewünschte Ebene mit der Baugruppe. Der Code des Moduls aus verschiedenen Ebenen, als ob er übereinander geschichtet wäre. In diesem Fall ändert sich der Quellcode nicht, aber wir erhalten ein unterschiedliches Verhalten, indem wir verschiedene Ebenen kombinieren.


Mit Ebenen können Sie komplexe Module basierend auf einfachen Modulen schreiben, das Verhalten einfach kombinieren und denselben Code zwischen Diensten fummeln. Und dieser Code wird von ENB - Webpack in der BEM-Welt gesammelt.

Als ich BEM kennenlernte, war ich besonders zufrieden mit den UI-Bibliotheken, in denen fertige Komponenten liegen. Wir erweitern diese Komponenten im Rahmen neuer Bibliotheken und teilen sie zwischen Projekten. Das macht das Leben einfacher: Ich mache selten Make-up, schreibe nicht den gleichen JS-Typ und baue schnell Schnittstellen aus vorgefertigten Blöcken zusammen.



Jetzt werden wir uns die Tools der BEM-Plattform genauer ansehen, um zu verstehen, was BEM nicht gut genug macht und warum es nicht zu unseren Aufgaben passt.

BEM-XJST

Ich werde mit meiner Lieblings- bem-xjst- Template-Engine beginnen. Vor Yandex.Money habe ich Jade verwendet, und Bem-xjst hat die Minuspunkte von Jade, die ich damals nicht gesehen habe, perfekt illustriert. Die bem-xjst-Vorlagen sind deklarativ [1], haben keine if-Hölle [2] und erfüllen perfekt die Anforderungen des Komponentenansatzes [3]. All dies ist im Beispiel deutlich zu sehen:



In der Sandbox können Sie das Ergebnis der Vorlage sehen und damit spielen.


Bem-xjst ist isomorph. Wir rendern HTML-Seiten auf dem Server und ändern sie dynamisch auf dem Client. Für die Vorlage zur Laufzeit bietet bem-xjst eine API, die wir beim Schreiben von clientseitigem Javascript-Code verwenden.

Ich-bem

Mit bem-xjst beschreiben wir die Ansicht und die Logik mit i-bem . I-bem ist eine Abstraktion über das DOM, die eine allgemeine API für die Arbeit mit Komponenten bietet. Einfach ausgedrückt, schreiben wir Folgendes:



stattdessen:



Um Code zu schreiben, müssen Sie nicht über die interne Implementierung der Komponente informiert sein. Wir arbeiten mit Entitäten, die wir in der Vorlage beschrieben haben: Auf jeden Fall handelt es sich um einen jQuery-Selektor oder ein DOM-Element. Wir können benutzerdefinierte Ereignisse erstellen, die für ein bestimmtes Objektmodell geeignet sind, und die Arbeit mit nativen Ereignissen und Schnittstellen wird in der internen Implementierung ausgeblendet. Dort wird auch die Logik auf niedriger Ebene beschrieben, was bedeutet, dass wir den Code nicht mit der Hauptlogik mit unnötigen Überprüfungen laden. Infolgedessen ist der Code leicht zu lesen und hängt nicht von einer bestimmten Technologie ab.

Mit I-bem können Sie die Logik der Komponente als eine Reihe von Zuständen beschreiben [1]. Dies ist deklaratives Javascript. I-bem implementiert seinen eigenen Event Emitter: Wenn sich Zustände ändern, generieren Komponenten automatisch Ereignisse, die eine andere Komponente abonnieren kann [2].

So sieht der größte Teil des clientseitigen BEM-Javascript-Codes aus:




Mit i-bem können wir das Verhalten von Komponenten einfach neu definieren, eine wohlgeformte API für ihre Interaktion erstellen und sie zur Laufzeit dynamisch ändern. Was fehlt also?
Wir lieben BEM wegen seiner Deklarativität, einfachen Skalierbarkeit und Abstraktionen auf hoher Ebene, sind aber nicht mehr bereit, seine Einschränkungen in Kauf zu nehmen. Im Folgenden werden wir das Problem des Client-Renderings, der Datenspeicherung und anderer Einschränkungen der BEM-Plattform betrachten. Im Laufe der Zeit können diese Probleme von BEM-Mitarbeitern gelöst werden, aber wir sind nicht bereit zu warten.

Modernes Web mit SPA und Anpassungsfähigkeit für mobile Geräte erfordert auch Anpassungsfähigkeit von uns. Aus diesem Grund haben wir uns entschlossen, auf unseren eigenen Stack umzusteigen. Und sie entschieden sich für React.

Neuer React Maple Stack

React brachte ein virtuelles DOM, Hot Reload, CSS in JS und eine große Community, zu der wir gehören, in unser Leben.

Die Migration unserer Dienste zu React ist in vollem Gange. Einige Anwendungen wurden bereits ganz oder teilweise in React umgeschrieben. Wir lernen neue Ansätze und Tools kennen und verbessern die Architektur unserer Anwendungen.

Bibliotheken

Das Partitionieren von Schnittstellenentitäten in unabhängige BEM-Blöcke ist mit dem React-Komponentenansatz sehr benutzerfreundlich. Yandex-Entwickler haben bem-react-core geschrieben und die UI-Bibliothek der Basiskomponente an React übertragen. Wir haben darüber eine Adapterbibliothek geschrieben, die die Besonderheiten dieser Komponenten berücksichtigt und als HOC bereitstellt :



Solche Bibliotheken sind nicht in der Anwendung, sondern in der Hauptbibliothek der Komponente verbunden:



Die Anwendung hängt nur von der Hauptbibliothek ab und bezieht alle Komponenten daraus:



Dadurch wird die Anzahl der Anwendungsabhängigkeiten verringert, und Bibliotheken werden unter verschiedenen Versionen nicht zweimal in das Bundle aufgenommen.

Technologie

React ist nicht an bestimmte Technologien gebunden und wir wählen selbst Tools und Bibliotheken aus. Es gibt Axios, Redux, Redux-Form, Redux-Thunk, Styled-Komponenten, TypeScript, Flow, Scherz und andere coole Sachen in meiner Bewaffnung. Um den Zoo zu verhindern, koordinieren wir den Einsatz neuer Technologien mit anderen Entwicklern. Wir senden eine Pull-Anfrage an ein spezielles Repository mit einer Analyse, wie nützlich die Technologie ist und warum sie ausgewählt wurde.

Das Frontend kommt in die Bar und der Barkeeper sagt es ihm

Für Anwendungen auf React erstellen wir eine Plattform, die Bibliotheken und Prozesse zusammenführt, um sie zu erstellen und zu unterstützen. Das Herzstück dieser Plattform ist das Frontend Bar-Konsolendienstprogramm. Bar kann viele leckere Stücke kochen.

Im Menü:

1. Config with ice: bar mischt und schüttelt Ihre yml-Variablen und bereitet eine Konfigurationsvorlage für ansible vor.
   
2. Saft mit dem Aroma von Konfiguratoren: Bar erstellt eine neue Anwendung basierend auf einem modularen Rohling - Saft.
   
3. Grundlegende Bibliothekseinstellungen. Bald erhältlich.
   

Das Erstellen einer saftigen App ist jetzt ganz einfach - Frontend-Bar macht Saft. Saft machen, nicht Krieg! Wenn Bar eine neue Anwendung bereitstellt, führt es eine Reihe von Konfigurationen aus Juice aus: package.json, .babelrc wird generiert, Key Middleware und Routencode, Root-Komponentencode. Die Frontend Bar erleichtert die Zuweisung neuer Microservices und hilft, einheitliche Regeln für das Schreiben von Code einzuhalten.

Beim Wechsel zu einem neuen Stack haben wir begonnen, die Serverarchitektur von Anwendungen zu verbessern. Wir haben einen neuen Logger für den Client und eine Bibliothek mit einer Reihe von Abstraktionen für die Implementierung von MVC geschrieben . Heute entscheiden wir über die neue Serverarchitektur.



Spoiler: Zwiebel wählen.

Was ist passiert und ist es besser geworden? Lass uns verstehen

Dynamische Schnittstellen

War

Ich habe oben geschrieben, dass bem-xjst eine API für Vorlagen zur Laufzeit bereitstellt. I-bem kann wiederum mit dem DOM-Baum arbeiten. Wir werden sie zu Freunden machen und in der Lage sein, HTML dynamisch zu generieren und zu ändern. Versuchen wir, die Schaltfläche nach Ereignis zu ändern:




In diesem Beispiel ist die schwache Seite von BEM sichtbar: i-bem möchte nicht mit bem-xjst befreundet sein und möchte nichts über Vorlagen wissen. Es fügt dem Block eine Klasse hinzu, wendet jedoch die Vorlage nicht an [1]. Wir rendern die Komponente manuell neu [2]:

• beschreibe ein neues Stück BEM-Baum [3];
• Wenden Sie dann eine neue Vorlage an [4].
• und initialisieren Sie eine andere Komponente auf dem aktuellen DOM-Knoten [5].

Außerdem erstellt i-bem keinen Unterschied zwischen BEM-Bäumen. Daher wird die gesamte Komponente gerendert, nicht die Teile, die sich geändert haben. Stellen Sie sich ein einfaches Beispiel vor: Rendern Sie den Inhalt eines modalen Fensters bei Bedarf neu. Es besteht aus drei Elementen:



Der Einfachheit halber nehmen wir an, dass sich nur ein Element ändern kann.



Ich möchte [1] tun und mich entspannen. Aber i-bem wird nicht verstehen, was sich geändert hat, die gesamte Komponente komplett neu rendern und sich auch entspannen. In diesem Beispiel gibt es keine schwerwiegenden Konsequenzen, aber was ist, wenn die gesamten Formulare so ungenau wiedergegeben werden? Dies verschlechtert die Leistung und verursacht unangenehme Nebenwirkungen: Irgendwo flackert die Eingabe, irgendwo hängt der inhaberlose Tooltip. Aus diesem Grund sind wir traurig und steuern Teile der Komponenten manuell, um einen Punktrenderer zu erstellen [2]. Dies erschwert die Entwicklung und wir sind wieder traurig.

Ist geworden

Die Reaktion kam und ruinierte alles. Er selbst überwacht den Status der Komponenten, wir verwalten das manuelle Rendern nicht mehr und denken nicht an die Interaktion mit dem DOM. React enthält eine virtuelle DOM- Implementierung. Durch Aufrufen von React.createElement wird ein js-Objekt des DOM-Knotens mit seinen Eigenschaften und Nachkommen erstellt - das virtuelle DOM dieser Komponente, das in React gespeichert ist. Wenn sich eine Komponente ändert, berechnet React das neue virtuelle DOM und dann den Unterschied zwischen gespeichert und neu und aktualisiert nur den Teil des DOM, der sich geändert hat. Alles fliegt und wir können komplexe Logik nur mit shouldComponentUpdate optimieren. Es ist ein Erfolg!

Datenspeicherung

War

In BEM bereiten wir alle Daten auf dem Server vor und übertragen sie auf die Seitenkomponenten:



Die Komponenten sind isoliert und teilen keine Daten miteinander, was bedeutet, dass dieselben Daten in verschiedene Komponenten geworfen werden müssen [1]. Wir können sie nicht auf den Client übertragen, daher akzeptiert jede Komponente im Voraus einen Datensatz, der für alle möglichen Szenarien ihres Betriebs benötigt wird. Dies bedeutet, dass wir die Komponente mit Daten laden, die sie möglicherweise nicht benötigt [2].

Manchmal rettet uns eine globale Entität, in der ein Teil der gemeinsamen Daten gespeichert ist, aber die globale Speicherung von Variablen passt nicht gut zum BEM-Konzept. Deshalb haben wir einen bem-redux geschrieben , der Redux für BEM anpasst. Redux ist ein Statusmanager, der den Datenfluss verwaltet. Es verwaltet unsere Daten perfekt über einfache Schnittstellen, aber bei der Entwicklung einer komplexen Komponente stoßen wir auf das oben beschriebene Rendering-Problem. Redux ist nicht freundlich zu i-bem, wir beheben Fehler und sind traurig.

Ist geworden

Redux + React = <3
Redux speichert Daten für die gesamte Anwendung an einem Ort [1]:



Die Komponente selbst entscheidet, wann und welche Daten sie benötigt [2]:



Wir müssen nur die Szenarien der Komponente [3] beschreiben und angeben, woher die Daten für ihre Ausführung stammen [4]:



Und React wird den Rest erledigen [5]:



Mit diesem Ansatz können Sie dem Prinzip der Einzelverantwortung folgen und die Logik der Komponente in der Komponente selbst kapseln, anstatt sie im Seitencode zu verbreiten. Es ist ein Erfolg!

Sie müssen für alles bezahlen

Für den Erfolg haben wir eine Menge Vermächtnis für React bezahlt. Es ist schmerzhaft zu sehen, wie Ihr Code, der vor ein paar Monaten geschrieben wurde, reibungslos veraltet wird.

Tatsache ist, dass React eine Bibliothek auf Ansichtsebene ist, kein vollwertiges Framework. Sie können alle Werkzeuge auswählen, müssen jedoch alle Werkzeuge auswählen. Und auch, um den Code selbst zu organisieren, Ansätze zur Lösung typischer Probleme zu formulieren, eine Reihe von Vereinbarungen zu entwickeln und die fehlenden Plugins zu schreiben.Wir schreiben unsere eigenen Validatoren für Redux-Formulare und haben noch nicht gelernt, wie man mit komplexen Animationen arbeitet. Und wir versuchen rauszuwerfen, zu schreiben und neu zu schreiben. Und wir schreiben es nicht immer neu, weshalb unser Rückstand wächst.

React ist jung genug und im Gegensatz zu BEM nicht bereit für die Unternehmensentwicklung. Und während wir lernten, wie man es kocht, haben wir unsere gesamte Küche und uns selbst bis zum Ellbogen durcheinander gebracht. Und wir diskutieren immer noch, ob wir Flow benötigen oder nicht, und verstehen immer noch nicht vollständig, was im Geschäft und was im lokalen Geschäft gespeichert werden soll. Wir schreiben nach Bedarf und gehen zu Konferenzen, um herauszufinden, wie es geht. Wir haben die Zapfen geschlagen, sind aber zuversichtlich vorwärts gegangen.

Unerwartete Brötchen

Mit dem neuen Stack konnten wir eine Reihe von Aufgaben neu betrachten und auf einfache Weise lösen.

CSS in JS

War

Stellen Sie sich einen einfachen Fall aus dem Leben vor: Um ein Symbol durch ein Ereignis zu kolorieren und zu animieren, etwa so:



Alles Code ist nichts:



Richtig, gemäß den Regeln von BEM müssen Sie ihn in drei Verzeichnisse



sortieren : Overshot? Ein strittiger Punkt. Noch wichtiger ist, dass wir in js diese Klassen manuell hinzufügen, wenn die erforderlichen Ereignisse auftreten. Die übliche Situation, aber je benutzerdefinierter oder komplexer die Benutzeroberfläche ist, desto häufiger müssen Sie Klassen hinzufügen und entfernen. Und wenn Sie nicht nur das Symbol, sondern auch den Text ändern müssen? Nicht genau die Logik, die Sie im js-Code sehen möchten:



Aber was ist, wenn die Dauer der Animation von etwas abhängt und dynamisch eingestellt wird? Dann werden wir die CSS-Animation in jQuery umschreiben und ein wenig traurig sein.

Ist geworden

Styled-Komponenten , ich liebe dich! CSS in JS - eine Liebe! Mein innerer Schriftsetzer freut sich: Die



Modularität bleibt erhalten, CSS-Animation funktioniert und keine manuelle Arbeit mit Klassen. Ein schöner Bonus für den neuen Stack.

Tippen

War

Wir haben Tonnen von jsDoc geschrieben. Mal sehen, ob es nützlich ist:



Dieses Beispiel stammt aus dem Produktionscode. Was enthält der Staat? Ich habe keine Ahnung. Ja, es gibt eine Readme-Datei, aber leider ist sie etwas veraltet. Ja, wir schämen uns, aber mit Dokumentationen und Kommentaren, die häufig vorkommen, sind sie unzuverlässig. Muss in den Code eintauchen. Oder gehen Sie nicht tief und brechen Sie versehentlich alles. Wir haben es eilig, gehen nicht tief, brechen und fühlen uns traurig.

Ist geworden

Das Tippen kam zur Rettung. "Tyk" über den Typ und alle Vor- und Nachteile der Methode vor meinen Augen. Zu faul um zu verstehen? Precommit Checker startet den Flow und Sie müssen es noch herausfinden.

Ich mochte Flow auf den ersten Blick nicht. Termine sind an, der Manager pingt, und Sie haben "kann kein Eigentum bekommen", und hier "Eigentum fehlt". Aber kürzlich wurde mir gesagt, dass Typen von O_o entworfen werden können. Wie kann man nach Typen entwerfen? So etwas in der Art:



Meine Welt hat sich auf den Kopf gestellt. Flow ist kein Albtraum mehr. Es war praktisch und nützlich, die API-Module vor dem Schreiben des Codes mit Typen zu beschreiben. Zuverlässiger Code - ein schöner Bonus!

Also kein BEM mehr?

Nein.BEM lebt und wir unterstützen weiterhin Anwendungen auf dem BEM-Stack. Mit der Zeit werden sie auch zu React wechseln, aber jetzt bereiten wir den Weg dafür vor: Wir übersetzen Komponentenbibliotheken, bilden eine Reihe von Tools und Vereinbarungen und lernen, wie Migrationsdaten geplant werden.

Bei BEM ist unsere E-Mail-Newsletter-Vorlagen-Engine implementiert. Wir bereiten Briefe auf dem Server vor, und die oben beschriebenen Einschränkungen der BEM-Plattform wirken sich nicht auf diese Anwendung aus. Die Verwendung von BEM zur Entwicklung ist eine geeignete elegante Lösung.

Darüber hinaus verwenden unsere Designer Prototypen mit BEM und bringen uns manchmal vormontierte Komponenten anstelle von Layouts. Und selbst wenn wir aufhören, über BEM zu schreiben, wird er uns immer noch finden :)

Ich habe den ersten Teil gelesen. Was ist mit Codierern?

Ich habe an der Übersetzung einer der Anwendungen von BEM nach React teilgenommen und eine wichtige Sache herausgefunden.

Bevor ich zu Yandex.Money kam, war ich ein einfacher Schriftsetzer und verbrachte mehr als ein Jahr, kilometerlange Tonnen von HTML und JSX. Ich habe die Front-End-Community und ihre sich verändernde Welt nicht ernst genommen. Ich verstand nicht, warum ich den ersten Winkel studieren sollte, um ihn morgen zu vergessen und den zweiten zu studieren. Ich habe nicht verstanden, warum jQuery.Ajax in Fetch geändert und dann Fetch durch Axios ersetzt wird.

Es stellte sich heraus, dass Sie beim Übertragen eines Projekts von einem Framework auf ein anderes nicht nur den Code portieren. Wir müssen die Architektur der Anwendung analysieren und verbessern, die Logik begradigen, den Refactor. Ein ständiger Werkzeugwechsel ist kein Versuch, die Hype-Welle zu bewältigen, sondern eine ständige Suche nach der besten Lösung, die den Anforderungen der Zeit entspricht. Ein sich dynamisch entwickelndes Feld wie nichts anderes trägt zur Entwicklung Ihres Produkts bzw. Ihrer beruflichen Entwicklung bei. Und das Frontend ist genau so ein Bereich. Lasst uns gemeinsam dafür kämpfen!

Reagiere auf alle!