Geekly articles weekly

Regeln für die Auswahl eines JS-Frameworks

TL; DR

  • In diesem Artikel werden JS-Frameworks aus der TOP-3-Liste nicht behandelt.
  • Bei der Entwicklung auf einem Nicht-TOP-3-JS-Framework müssen Sie zu Beginn der Entwicklung um eine Größenordnung mehr technische Probleme lösen als erwartet
  • Die Geschichte basiert auf realen Ereignissen.

Die Geschichte begann mit einem Miniprojekt, das ursprünglich auf der Grundlage der Bibliotheken backbone.js und marionette.js entwickelt wurde. Dies sind natürlich die großartigen Bibliotheken, mit denen die Entwicklung einseitiger Anwendungen begann. Aber schon damals waren sie eher von historischem als von praktischem Wert. Ich werde nur die Tatsache erwähnen, dass zum Anzeigen einer einfachen Tabelle Folgendes erstellt werden musste: 1) ein Modul mit einer Beschreibung des Modells, 2) ein Modul mit einer Beschreibung der Sammlung, 3) ein Modul mit der Definition eines Ansichtsmodells, 4) ein Modul mit der Definition einer Ansichtssammlung, 4) eine Tabellenzeilenvorlage, 5) Tabellenvorlage; 6) Controller-Modul. Mit ungefähr 10 Entitäten in einer kleinen Anwendung - in der Anfangsphase hatten Sie bereits mehr als fünfzig kleine Module. Und das ist erst der Anfang. Aber jetzt geht es nicht darum.

Irgendwann, nach sechs Monaten der Bewerbung, erschien sie immer noch nicht in den Suchergebnissen. Das Hinzufügen von prerender.io zum Projekt (das dann die phantom.js-Engine verwendete) hat geholfen, aber nicht so signifikant wie erwartet. Über der Anwendung und über mir sammelten sich Wolken, woraufhin mir klar wurde, dass ich sehr schnell und effizient etwas tun musste, vorzugsweise heute. Das Ziel, das ich mir gesetzt habe, war Folgendes: Wechseln Sie zum Server-Rendering. Mit backbone.js und marionettejs ist dies fast unmöglich. Auf jeden Fall wurde das rendr-Projekt auf backbone.js, das unter der Leitung von Spike Brehm (dem Autor der Idee isomorpher / universeller Anwendungen) entwickelt wurde und 58 Mitwirkende und 4.184 Likes auf github.com sammelte, 2015 gestoppt und war eindeutig nicht für einen eintägigen Blitz gedacht . Ich suchte nach einer Alternative. Ich habe das TOP-3 JS-Framework sofort von der Prüfung ausgeschlossen, da ich keine Zeitreserve für ihre Entwicklung hatte. Nach einer kurzen Suche fand ich das schnell wachsende JS-Framework riot.js github.com/riot/riot , das derzeit 13.704 Likes auf github.com hat, und wie ich gehofft hatte, hätte es das erste erreichen können Position (was jedoch nicht geschehen ist).

Und ja, ich habe die Frage geschlossen (allerdings nicht am selben Tag, sondern für die nächsten zwei Tage des Tages), indem ich die Anwendung mit riot.js auf das Server-Rendering übertragen habe. Und am selben Tag, an dem dies geschah, wechselte die Site zu den ersten zehn Seiten der Suchergebnisse. Und innerhalb einer Woche ging ich zur ersten Seite, von wo aus sie seit mehreren Jahren nicht mehr gegangen ist.

Dies beendet die Erfolgsgeschichte und beginnt die Geschichte der Niederlagen. Das nächste Projekt war viel komplizierter. Es stimmte, dass 99% der Anwendungsbildschirme im persönlichen Konto des Benutzers gespeichert waren, sodass kein Server-Rendering erforderlich war. Inspiriert von der ersten erfolgreichen Erfahrung mit riot.js begann ich, die Idee zu fördern, den Erfolg zu festigen und riot.js im Frontend anzuwenden. Dann schien es mir, dass endlich eine Lösung gefunden wurde, die Einfachheit und Funktionalität kombinierte, wie die Dokumentation von riot.js. versprach. Wie falsch ich war!

Das erste Problem, auf das ich stieß, als es notwendig war, dem HTML-Layout-Designer alle erforderlichen Entwicklungstools zur Verfügung zu stellen. Insbesondere brauchten wir Plug-Ins für den Code-Editor, eine Engine, in der es möglich wäre, die Komponenten zu platzieren und das Ergebnis sofort zu beobachten, auch bei heißer Überladung von Komponenten (Hot-Reload). All dies musste in der Form gegeben werden, die in naher Zukunft für den industriellen Betrieb bereit war, und all dies war nicht der Fall. Infolgedessen begann das Layout der Anwendung auf einer der traditionellen Template-Engines, was zu einer undankbaren Phase der Übersetzung von HTML-Dokumenten in riot.js-Komponenten führte.

Das Hauptproblem, das zu diesem Zeitpunkt aufgetreten ist, hängt jedoch nicht einmal mit der Übersetzung des Layouts aus dem Vorlagenformat in riot.js-Komponenten zusammen. Plötzlich stellte sich heraus, dass riot.js völlig uninformative Meldungen zu Vorlagenkompilierungsfehlern sowie zu Laufzeitfehlern enthält (dies gilt für alle Versionen von riot.js bis Version 4.0, die komplett neu gestaltet wurden). Es gab keine Informationen nicht nur über die Zeile, in der der Fehler aufgetreten ist, sondern auch über den Namen der Datei oder Komponente, in der der Fehler aufgetreten ist. Es war möglich, viele Stunden hintereinander nach einem Fehler zu suchen, der jedoch immer noch nicht gefunden werden konnte. Und dann musste ich alle Änderungen auf den letzten Arbeitszustand zurücksetzen.

Das Folgende war ein Problem mit dem Routing. Das Routing in riot.js erfolgt fast sofort - github.com/riot/route - zumindest vom selben Entwickler. Dies erlaubte ihm, auf eine störungsfreie Operation zu hoffen. Aber irgendwann bemerkte ich, dass einige Seiten unvorhersehbar überladen sind. Das heißt, einmal kann der Übergang zu einer neuen Route im einseitigen Anwendungsmodus erfolgen, und ein anderes Mal hat derselbe Übergang das gesamte HTML-Dokument überlastet, wie bei der Arbeit mit einer klassischen Webanwendung. In diesem Fall ging natürlich der interne Status verloren, wenn er noch nicht auf dem Server gespeichert war. (Derzeit wird die Entwicklung dieser Bibliothek gestoppt und nicht mit riot.js 4.0 verwendet.)

Die einzige Komponente des Systems, die wie erwartet funktionierte, war der minimale flussähnliche Zustandsmanager github.com/jimsparkman/RiotControl . Um mit dieser Komponente arbeiten zu können, mussten die Zuhörer von Statusänderungen viel häufiger ernannt und abgesagt werden, als wir möchten.

Die ursprüngliche Idee dieses Artikels war folgende: Um anhand eines Beispiels unserer eigenen Erfahrung mit dem riot.js-Framework die Aufgaben zu zeigen, die der Entwickler lösen müsste, der beschlossen hat, eine Anwendung auf einem JS-Framework zu entwickeln, das nicht aus der TOP-3-Liste stammt. Während der Vorbereitung habe ich mich jedoch entschlossen, einige Seiten aus der Dokumentation zu riot.js in meinem Gedächtnis zu aktualisieren, und so habe ich erfahren, dass eine neue Version von riot.js 4.0 veröffentlicht wurde, die vollständig (von Grund auf neu gestaltet) wurde und im Artikel über Riot-Entwickler zu finden ist. js auf medium.com: medium.com/@gianluca.guarini/every-revolution-begins-with-a-riot-js-first-6c6a4b090ee . Aus diesem Artikel habe ich erfahren, dass alle Hauptprobleme, die mich beunruhigten und über die ich in diesem Artikel sprechen wollte, beseitigt wurden. Insbesondere in riot.js Version 4.0:

  • Der Compiler wird vollständig neu geschrieben (oder besser gesagt, er wurde zuerst geschrieben, weil die Engine zuvor mit regulären Ausdrücken gearbeitet hat) - dies wirkte sich insbesondere auf den Informationsgehalt von Fehlermeldungen aus
  • Zusätzlich zum Server-Rendering wurde Hydrat auf dem Client hinzugefügt - dies ermöglichte es uns schließlich, universelle Anwendungen ohne doppeltes Rendering zu schreiben (das erste Mal auf dem Server und genau dort auf dem Client, da in älteren Versionen keine hydrate () -Funktion vorhanden war).
  • Plugin für Hot Overloading-Komponenten hinzugefügt github.com/riot/hot-reload
  • und viele andere nützliche Änderungen

Dies ist keine Werbung, nur der Hintergrund. Tatsächlich werden meine Schlussfolgerungen in Bezug auf Verwendungsempfehlungen sehr zweideutig sein, und der Artikel ist im Allgemeinen nicht einem bestimmten Rahmen oder einer bestimmten Bibliothek gewidmet, sondern den Aufgaben, die während des Entwicklungsprozesses gelöst werden müssen.

Leider wurde die Arbeit der Entwickler von riot.js von der Community noch nicht richtig bewertet. Beispielsweise hat die Server-Rendering-Bibliothek github.com/riot/ssr für die sechs Monate, die seit Beginn ihrer Entwicklung vergangen sind, drei Mitwirkende und drei Likes auf github.com gesammelt (nicht alle Likes werden von den Mitwirkenden erstellt, obwohl einer mit dem Mitwirkenden identisch ist).

Deshalb änderte er im Laufe des Stücks die Richtung des Artikels und versuchte anstelle von Memoiren, den ganzen Weg wieder zu gehen, mit etwas mehr Wissen und Erfahrung, fortgeschritteneren Versionen von Bibliotheken und unbegrenzter Freizeit.

Also los geht's. Beispielsweise wurde eine Implementierung der Anwendung github.com/gothinkster/realworld durchgeführt . Dieses Projekt wurde mehr als einmal auf Habré diskutiert. Für diejenigen, die ihn nicht kennen, werde ich kurz seine Idee beschreiben. Die Entwickler dieses Projekts lösen mit Hilfe verschiedener Programmiersprachen und Frameworks (oder ohne diese) das gleiche Problem: die Entwicklung einer Blog-Engine mit einer ähnlichen Funktionalität wie die vereinfachte Version von medium.com. Dies ist ein Kompromiss zwischen der Komplexität realer Anwendungen, die wir täglich entwickeln müssen, und todo.app, wodurch wir die Arbeit mit der Bibliothek oder dem Framework nicht immer wirklich schätzen können. Dieses Projekt wird von den Entwicklern respektiert. Zur Bestätigung des oben Gesagten kann ich sagen, dass es sogar eine Implementierung von Rich Harris (Hauptentwickler von sveltejs) github.com/sveltejs/realworld gibt .

Entwicklungsumgebung


Natürlich sind Sie bereit, in die Schlacht zu eilen, aber denken Sie an die Entwickler um Sie herum. Konzentrieren Sie sich in diesem Fall auf die Frage, in welcher Entwicklungsumgebung Ihre Kollegen arbeiten. Wenn es keine Plugins für die wichtigsten Entwicklungsumgebungen und Programmcode-Editoren für das Framework gibt, mit dem Sie arbeiten werden, ist es unwahrscheinlich, dass Sie unterstützt werden. Zum Beispiel benutze ich den Atom-Editor für die Entwicklung. Für ihn gibt es ein Riot-Tag-Plugin github.com/riot/syntax-highlight/tree/legacy , das in den letzten drei Jahren nicht aktualisiert wurde. Und im selben Repository gibt es ein Plugin für sublime github.com/riot/syntax-highlight - es ist aktuell und unterstützt die aktuelle Version von riot.js 4.0.

Die Komponente riot.js ist jedoch ein gültiges Fragment eines HTML-Dokuments, in dem der JS-Code im Hauptteil des Skriptelements enthalten ist. Alles funktioniert also nur, wenn Sie einen HTML-Dokumenttyp für die Erweiterung * .riot hinzufügen. Dies ist natürlich eine erzwungene Entscheidung, da es sonst einfach unmöglich gewesen wäre, hier weiterzumachen.

Wir haben Syntaxhervorhebungen in einem Texteditor erhalten, und jetzt benötigen wir erweiterte Funktionen, wie wir es von eslint gewohnt sind. In unserem Fall ist der JS-Code der Komponente im Hauptteil des Skriptelements enthalten. Ich hatte gehofft, ein Plug-In zum Extrahieren des JS-Codes aus dem HTML-Dokument zu finden und zu finden - github.com/BenoitZugmeyer/eslint-plugin-html . Danach sah meine Eslint-Konfiguration folgendermaßen aus:

{ "parser": "babel-eslint", "plugins": [ "html" ], "settings": { "html/html-extensions": [".html", ".riot"] }, "env": { "browser": true, "node": true, "es6": true }, "extends": "standard", "globals": { "Atomics": "readonly", "SharedArrayBuffer": "readonly" }, "parserOptions": { "ecmaVersion": 2018, "sourceType": "module" }, "rules": { } }

Das Vorhandensein von Plug-Ins für die Hervorhebung von Syntax und Eslint ist wahrscheinlich nicht das erste, woran ein Entwickler bei der Auswahl eines JS-Frameworks zu denken beginnt. In der Zwischenzeit können Sie ohne diese Tools aus "guten" Gründen des Projekts auf Widerstand von Kollegen und deren Massenexodus stoßen. Obwohl der einzige und wirklich gültige Grund darin besteht, dass es ihnen unangenehm ist, ohne ein vollständiges Entwicklerarsenal zu arbeiten. Im Fall von riot.js wurde das Problem mit der Columbus-Methode gelöst. In dem Sinne, dass es eigentlich keine Plugins für riot.js gibt, aber aufgrund der Besonderheiten der Template-Syntax von riot.js, die wie ein Fragment eines normalen HTML-Dokuments aussieht, decken wir 99% der erforderlichen Funktionen mit Tools für die Arbeit mit einem HTML-Dokument ab.

Zusätzlich zu den Mitteln zum Schreiben und Validieren des soeben untersuchten Codes umfassen die Tools des Entwicklers Tools zum schnellen Zusammenstellen und Debuggen des Projekts sowie zum erneuten Laden von Komponenten und Modulen in einem Webbrowser, wenn Änderungen am Projekt vorgenommen werden. Wir werden diesen Teil im nächsten Abschnitt betrachten.

Projektmontage


Wir haben es geschafft, uns an die meisten Funktionen zu gewöhnen, die beim Erstellen des Projekts benötigt werden, und haben sogar aufgehört, darüber nachzudenken, was anders sein könnte. Aber es könnte auch anders sein. Wenn Sie sich für ein neues JS-Framework entschieden haben, sollten Sie zunächst sicherstellen, dass alles wie erwartet funktioniert. Wie bereits erwähnt, war das größte Problem bei der Entwicklung älterer Versionen von riot.js beispielsweise das Fehlen von Kompilierungsfehlermeldungen und Laufzeitinformationen zu der Komponente, in der dieser Fehler aufgetreten ist. Wichtig ist auch die Kompilierungsgeschwindigkeit. Um die Kompilierungsgeschwindigkeit zu beschleunigen, wird in einem korrekt erstellten Framework in der Regel nur der geänderte Teil neu kompiliert. Daher ist die Reaktionszeit auf Änderungen des Komponententextes minimal. Nun, es ist sehr gut, wenn ein Hot-Reload von Komponenten ohne ein vollständiges Neuladen von Seiten in einem Webbrowser unterstützt wird.

Daher werde ich versuchen, die Checkliste aufzulisten, worauf Sie bei der Analyse der Build-Tools des Projekts besonders achten müssen:

1. Das Vorhandensein eines Entwicklungsmodus und einer funktionierenden Anwendung
Im Entwicklermodus:
2. Informative Meldungen zu Projektkompilierungsfehlern (Name der Quelldatei, Zeilennummer in der Quelldatei, Beschreibung des Fehlers)
3. Informative Meldungen zu Laufzeitfehlern (Name der Quelldatei, Zeilennummer in der Quelldatei, Beschreibung des Fehlers)
4. Schneller Zusammenbau modifizierter Module
5. Heiße Überlastung der Komponenten im Browser
Im Betriebsmodus:
6. Das Vorhandensein einer Versionierung im Dateinamen (z. B. 4a8ee185040ac59496a2.main.js)
7. Das Layout kleiner Module in einem oder mehreren Modulen (Chunks)
8. Code wird durch dynamischen Import in Blöcke aufgeteilt

In riot.js Version 4.0 wurde das Modul github.com/riot/webpack-loader angezeigt, das der angegebenen Checkliste vollständig entspricht. Ich werde nicht alle Funktionen der Baugruppenkonfiguration auflisten. Das einzige, worauf ich achten werde, ist, dass ich in dem betrachteten Projekt Module für express.js verwende: Webpack-Dev-Middleware und Webpack-Hot-Middleware, mit denen Sie ab dem Zeitpunkt des Satzes sofort auf einem voll funktionsfähigen Server arbeiten können. Dies ermöglicht insbesondere die Entwicklung universeller / isomorpher Webanwendungen. Ich mache Sie darauf aufmerksam, dass das Modul Hot Overload Modul nur für einen Webbrowser gültig ist. Gleichzeitig bleibt die auf der Serverseite gerenderte Komponente unverändert. Daher ist es notwendig, die Änderungen abzuhören und zum richtigen Zeitpunkt den gesamten vom Server zwischengespeicherten Code zu löschen und den Code der geänderten Module zu laden. Wie das geht, ich werde nur einen Link zur Implementierung bereitstellen: github.com/apapacy/realworld-riotjs-effector-universal-hot/blob/master/src/dev_server.js

Routing


Wenn wir Leo Tolstoi ein wenig umschreiben, können wir sagen, dass alle Engines von JS-Frameworks einander ähnlich sind, während alle damit verbundenen Routings auf ihre eigene Weise funktionieren. Ich stoße oft auf die bedingte Klassifizierung von Routern in zwei Typen: deklarativ und imperativ. Jetzt werde ich versuchen herauszufinden, wie eine solche Klassifizierung gerechtfertigt ist.

Machen wir einen kurzen Ausflug in die Geschichte. Zu Beginn des Internets stimmten URLs / URIs mit dem Namen der auf dem Server gehosteten Datei überein. Wir blättern mehrere Seiten der Geschichte gleichzeitig um und erfahren etwas über das Aufkommen der Modell 2 (MVC) -Architektur. In dieser Architektur wird ein Front-Controller angezeigt, der die Funktion des Routings übernimmt. Ich habe mich gefragt, wer zuerst vom Front-Controller entschieden hat, die Routing-Funktion in einem separaten Block auszuwählen, der dann eine Anfrage an einen der vielen Controller sendet und noch keine Antwort gefunden hat. Es scheint, dass sie alles auf einmal angefangen haben.

Das Routing bestimmte die Aktion, die auf dem Server ausgeführt werden soll, und (transitiv durch den Controller) die Ansicht, die vom Controller generiert wird. Bei der Übertragung des Routings auf die Client-Seite (Webbrowser) wurde bereits eine Vorstellung von der Routing-Funktion in der Anwendung gewonnen. Und diejenigen, die sich in erster Linie auf die Tatsache konzentrierten, dass das Routing die Aktion bestimmt, ein zwingendes Routing entwickelten, und diejenigen, die darauf achteten, dass das Routing letztendlich die Ansicht bestimmt, die dem Benutzer angezeigt werden sollte, entwickelten ein deklaratives Routing.

Das heißt, beim Übertragen von einem Server auf einen Client zum Routing haben sie zwei Funktionen "aufgehängt", die für das Server-Routing charakteristisch sind (Auswählen einer Aktion und Auswählen einer Ansicht). Darüber hinaus sind neue Aufgaben entstanden - dies ist die Navigation durch eine einseitige Anwendung, ohne das HTML-Dokument vollständig neu zu laden, die Bearbeitung des Besuchsverlaufs und vieles mehr. Zur Veranschaulichung werde ich Auszüge aus der Dokumentation des Routers eines äußerst beliebten Frameworks bereitstellen:

... macht es einfach, SPA-Anwendungen zu erstellen. Enthält die folgenden Funktionen

  • Verschachtelte Routen / Ansichten
  • Modulare Routerkonfiguration
  • Zugriff auf Routenparameter, Abfragen, Platzhalter
  • Übergangsanimation basierend auf Vue.js anzeigen
  • Bequeme Navigationssteuerung
  • Automatisches Anbringen einer aktiven CSS-Klasse für Links
  • HTML5-Verlaufsmodi oder Hash mit automatischer Umschaltung in IE9
  • Benutzerdefiniertes Bildlaufverhalten

Bei dieser Option ist das Routing deutlich mit Funktionen überlastet und muss seine Aufgaben auf der Clientseite überdenken. Ich suchte nach einer Lösung, die für meine Aufgabe geeignet war. Als Hauptkriterium habe ich das Routing berücksichtigt:

  1. sollte sowohl auf der Webclient- als auch auf der Webserverseite für universelle / isomorphe Webanwendungen gleich funktionieren;
  2. sollte mit jedem (einschließlich meines gewählten) Frameworks oder ohne dieses funktionieren.

Und ich habe eine solche Bibliothek gefunden, das ist github.com/kriasoft/universal-router . Wenn wir die Idee dieser Bibliothek kurz beschreiben, werden Routen konfiguriert, die eine URL-Zeichenfolge an der Eingabe verwenden und eine asynchrone Funktion an der Ausgabe aufrufen, die die analysierte URL als tatsächlichen Parameter übergibt. Ehrlich gesagt wollte ich fragen: ist das alles? Und wie sollen dann alle damit arbeiten? Und dann fand ich einen Artikel auf medium.com medium.com/@ippei.tanaka/universal-router-history-react-97ec79464573 , in dem eine ziemlich gute Option vorgeschlagen wurde, mit der Ausnahme, dass die push () - Verlaufsmethode möglicherweise nicht umgeschrieben wurde , was nicht der Fall war Ich brauche und was ich aus meinem Code gelöscht habe. Infolgedessen wird der Betrieb des Routers auf der Clientseite ungefähr so ​​definiert:

 const routes = new UniversalRouter([ { path: '/sign-in', action: () => ({ page: 'login', data: { action: 'sign-in' } }) }, { path: '/sign-up', action: () => ({ page: 'login', data: { action: 'sign-up' } }) }, { path: '/', action: (req) => ({ page: 'home', data: { req, action: 'home' } }) }, { path: '/page/:page', action: (req) => ({ page: 'home', data: { req, action: 'home' } }) }, { path: '/feed', action: (req) => ({ page: 'home', data: { req, action: 'feed' } }) }, { path: '/feed/page/:page', action: (req) => ({ page: 'home', data: { req, action: 'feed' } }) }, ... { path: '(.*)', action: () => ({ page: 'notFound', data: { action: 'not-found' } }) } ]) const root = getRootComponent() const history = createBrowserHistory() const render = async (location) => { const route = await router.resolve(location) const component = await import(`./riot/pages/${route.page}.riot`) riot.register(route.page, component.default || component) root.update(route, root) } history.listen(render)

Jetzt wird bei jedem Aufruf von history.push () das Routing eingeleitet. Um in der Anwendung zu navigieren, müssen Sie außerdem eine Komponente erstellen, die das Standard-HTML-Element a (Anker) umschließt, ohne zu vergessen, das Standardverhalten abzubrechen:

 <navigation-link href={ props.href } onclick={ action }> <slot/> <script> import history from '../history' export default { action (e) { e.preventDefault() history.push(this.props.href) if (this.props.onclick) { this.props.onclick.call(this, e) } e.stopPropagation() } } </script> </navigation-link>

Verwaltung des Anwendungsstatus


Anfangs habe ich die Mobx-Bibliothek in das Projekt aufgenommen. Alles hat wie erwartet funktioniert. Nur dass es nicht ganz der Aufgabe entsprach - der Studie, die ich am Anfang des Artikels festgelegt habe. Also wechselte ich zu github.com/zerobias/effector . Dies ist ein sehr mächtiges Projekt. Es bietet 100% der Redux-Funktionalität (nur ohne großen Overhead) und 100% der Mobx-Funktionalität (obwohl in diesem Fall etwas mehr Code erforderlich ist, aber im Vergleich zu Mobx ohne Dekoratoren immer noch weniger).

Die Beschreibung des Geschäfts sieht ungefähr so ​​aus:

 import { createStore, createEvent } from 'effector' import { request } from '../agent' import { parseError } from '../utils' export default class ProfileStore { get store () { return this.profileStore.getState() } constructor () { this.success = createEvent() this.error = createEvent() this.updateError = createEvent() this.init = createEvent() this.profileStore = createStore(null) .on(this.init, (state, store) => ({ ...store })) .on(this.success, (state, data) => ({ data })) .on(this.error, (state, error) => ({ error })) .on(this.updateError, (state, error) => ({ ...state, error })) } getProfile ({ req, author }) { return request(req, { method: 'get', url: `/profiles/${decodeURIComponent(author)}` }).then( response => this.success(response.data.profile), error => this.error(parseError(error)) ) } follow ({ author, method }) { return request(undefined, { method, url: `/profiles/${author}/follow` }).then( response => this.success(response.data.profile), error => this.error(parseError(error)) ) } }

Diese Bibliothek verwendet vollwertige Reduzierungen (sie werden in der Dokumentation zu effector.js genannt), die vielen Menschen in mobx fehlen, aber mit viel weniger Codierungsaufwand als redux. Aber die Hauptsache ist nicht einmal das. Nachdem ich 100% der Funktionalität von Redux und Mobx erhalten hatte, verwendete ich nur ein Zehntel der Funktionalität, die in effector.js enthalten ist. Daraus können wir schließen, dass seine Verwendung in komplexen Projekten die Mittel der Entwickler erheblich bereichern kann.

Testen


Todo

Schlussfolgerungen


Damit ist die Arbeit abgeschlossen. Das Ergebnis wird im Repository github.com/apapacy/realworld-riotjs-effector-universal-hot und in diesem Artikel über Habré vorgestellt.
Demo-Site jetzt realworld-riot-effector-universal-hot-pnujtmugam.now.sh

Und am Ende werde ich meine Eindrücke von der Entwicklung teilen. Die Entwicklung auf riot.js Version 4.0 ist sehr praktisch. Viele Konstrukte sind einfacher zu schreiben als in React. Es dauerte genau zwei Wochen, um sich in den Nachstunden und am Wochenende ohne Fanatismus zu entwickeln. Aber ... Ein kleines aber ... Das Wunder geschah nicht wieder. Das Server-Rendering in React ist 20 bis 30 Mal schneller. Unternehmen gewinnen erneut. Es wurden jedoch zwei interessante Routing- und State Manager-Bibliotheken getestet.

apapacy@gmail.com
17. Juni 2019

Source: https://habr.com/ru/post/de456448/

More articles:


All Articles