Reagieren auf Rails-Integration

Die kurze Antwort lautet, dass Sie React-Komponenten in JSX schreiben, die von den in den herkömmlichen Ansichten geschriebenen DOM-Elementen getrennt sind. React benötigt die vollständige Kontrolle über die DOM-Elemente, die es gut verarbeitet, oder Sie werden es die ganze Zeit bekämpfen (obwohl begrenzte Verwendung erfolgreich sein kann, kann es fragil sein).

Auf die Gefahr hin, dass ich nicht wirklich antworte, was Sie zu lernen beabsichtigen, hier sind ein paar Gedanken, die helfen könnten:

• Erstens, erkennen Sie, dass ReactJS immer noch ziemlich jung und Integration ist mit Rails noch jünger: Best Practices werden noch entdeckt und entschied, dass es genauso darum geht, einen Weg zu finden und ihn zu machen erfolgreich, da es darum geht, einen besten Weg auszuwählen.
Zweitens sind Hybridtechniken, bei denen die Probleme nicht gut voneinander getrennt sind, im Allgemeinen schwer zu organisieren und auf leicht erweiterbare Weise zu verwalten. ReactJS ist eine Ansichtstechnik, so dass es schwierig werden kann, Ihre Ansichtsmechanik zu trennen, wenn Sie versuchen, Ansätze auf unorganisierte Weise zu mischen, insbesondere weil ReactJS sich der DOM-Verwaltung nähert. Außerdem arbeiten Sie mit der Schnittmenge zweier unterschiedlicher Ökosysteme und die Unterstützung ist daher dünner.

• Sie haben wahrscheinlich drei Hauptansätze:

  • minimal JS (mit RoR auf die klassische Weise, wo JS die Ansicht erweitert,
  • Verschieben Sie den Großteil Ihrer Ansichten zu ReactJS mit minimaler RoR-Ansicht Konstruktion und
  • separate Service-Layer (mit RoR zur Bereitstellung einer API für AJAX mit einem separaten Web-Service verwenden, der die Benutzeroberfläche geschrieben darstellt in ReactJS (und so ReactJS nicht direkt in Rails integrieren)

• Es gibt zweifellos viele Variationen zu diesen Themen, aber diese sind wahrscheinlich die wichtigsten.

Ich habe nur an einigen Apps gearbeitet, die das tun, also nimm meine Kommentare mit einem Körnchen Salz. Für neue Apps tendiere ich jedoch zu einem separaten Service-Layer-Ansatz, da die Tooling-Software so viel einfacher ist. Ich neige dazu, ReactJS nur in einer bestehenden App zu verwenden, wenn ich einen besonders JS-schweren Teil einer Ansicht habe und diese Funktionalität gut begrenzt ist.

Minimal ReactJS

In klassischen Rails-Ansichten neigen wir dazu, JS nur zu verwenden, um die Ansicht mit clientseitigem Verhalten zu erweitern: Die meisten View-Berechnungen werden serverseitig durchgeführt, und dann lässt JS einfach verschiedene Aspekte des DOM für bestimmte Zwecke manipulieren. Dies kann mit React schwierig sein, da React die Verantwortung für seine Elemente des DOM übernimmt, um den Status aktualisiert zu halten. Aber Sie können ReactJS immer noch für Elemente Ihrer Seite verwenden, als ob Sie eine Teilansicht in Rails rendern würden, solange diese "teilweise" gut begrenzt ist.

Verwenden Sie das React-Rails-Juwel, lassen Sie Ihre Ansicht einfach eine React-Komponente so darstellen, als ob Sie eine partielle Komponente verwenden würden, und lassen Sie diese Komponente dann direkt mit den entsprechenden Elementen umgehen, indem Sie AJAX-Aufrufe verwenden, wenn Sie während des Clients mehr vom Server benötigen benutzen. Dies führt zu einer begrenzten, fokussierten Trennung von Bedenken und Sie können die herkömmlichen JS-Techniken verwenden, um andere DOM-Informationen der Seite zu erfassen, die Ihre Komponente umgeben (obwohl dies schwierig und chaotisch werden kann, wenn Sie mehr tun als nur sehr begrenzte Formen davon). - sollte wahrscheinlich überdenken, wenn Sie viel davon tun.)

Der Hauptvorteil dieses Ansatzes besteht darin, dass Sie damit beginnen können, ReactJS in eine bestehende Anwendung einzuführen und die Funktionalität zu migrieren, wenn Sie es für nützlich halten. Für bestimmte clientseitige intensive Dinge, wie zum Beispiel einige Formularfelder mit starker clientseitiger Interaktion, die aber gut begrenzt sind, kann diese Technik ein guter Kandidat sein.

ReactJS-Ansichten von Rails

Bei diesem Ansatz könnten wir Rails verwenden, um die Ansichtslayouts (d. h. den HTML-Wrapper, aber keinen Inhalt) zu rendern und dann die spezifischen Ansichten entweder ReactJS-only oder konventionellere ERB / ​​Haml / Slim-Ansichten zu lassen. Bei diesem Ansatz würde die Rails-Ansicht lediglich eine React-Hauptkomponente für die Seite erstellen und dann den Rest in ReactJS ausführen, um diesen Teil (normalerweise den gesamten Inhaltsbereich) in seiner eigenen JSX zu verwalten. Auf diese Weise wird Ihr JSX immer noch aus Ihrer Asset-Pipeline bedient, aber Sie haben wirklich die Kernpräsentation der Seite von React behandelt und Rails nur für die minimalen Zwecke von Layouts verwendet und einigen Sichten erlaubt, mit ReactJS zu arbeiten andere als Rails-basiert.

Wie ich es beschrieben habe, gehe ich eher von einer mehrseitigen App aus. Wenn Sie eine einzelne Seite App schreiben, würde diese Technik Rails wahrscheinlich einfach auf eine triviale Weise für die Präsentation verwenden.

Dennoch gibt es einige Vorteile:

• Auch hier können Sie Techniken für verschiedene Seiten kombinieren und anpassen, um ReactJS nach und nach in eine App zu integrieren. sagen, als eine Möglichkeit, einige Ansichten zu konvertieren, bis alle Ansichten React-basiert sind. Dann ist es einfacher, auf den separaten Service-Layer-Ansatz zu wechseln, wenn Sie möchten.
• Sie können weiterhin die Ansichten verwenden, um den ReactJS-Komponenten einige Informationen vom Controller zu liefern, wenn sie zum ersten Mal gerendert werden, da Ihre Ansicht weiterhin die React-Komponente initiiert. Für zusätzliche Informationen, sobald React seine Unterkomponenten verarbeitet, müssen Sie immer noch AJAX verwenden (nicht wirklich anders als jede andere JS-Funktionalität).
• Wie Sie darauf hinweisen, unterstützt Rails Sie immer noch bei CSRF und diesen anwendungsweiten Bedenken.

Separate Service-Layer

Bei diesem Ansatz werden Ansichten vom Back-End-Dienst vollständig getrennt. Schreiben Sie Ihre Rails-Anwendung als einen API-Server, der JSON vollständig rendert. Die gesamte Kernlogik wird immer noch in Controllern und Modellen behandelt, so dass ein Teil des Designs weitgehend intakt ist. In der Tat brauchen Sie dafür keine klassischen Rails. Andere Frameworks wie Grape oder der Rails-Api-Edelstein sind möglicherweise besser geeignet, da sie leichter sind, da Sie keine Ansichten anzeigen oder diese Helfer benötigen.

Dann schreiben Sie eine separate ReactJS-basierte App (denken Sie daran, dass ReactJS auch serverseitig sein kann), die sich nur auf die Präsentation konzentriert und nur Ihren RoR-API-Service verwendet, um Informationen abzurufen und zu posten.

Überlegungen zu diesem Ansatz:

• Sie erhalten eine klare Trennung der Bedenken: Ihre Rails-App (oder was auch immer) konzentriert sich auf die Data / Logic-Ebene als Service und Ihre ReactJS-App konzentriert sich auf die Präsentation. Es gibt einen Trend zur Verwendung von Rails auf diese Weise und Sie erhalten eine andere Möglichkeit, Ihre Anwendung horizontal zu skalieren.
• Werkzeuge sind viel einfacher, da beide homogener sind (automatisiertes Testen allein ist viel einfacher). Es gibt ein etabliertes Ökosystem rund um RoR und eines um JS- und ReactJS-Apps, aber die Schnittmenge dieser Ökosysteme ist viel spärlicher, so dass Sie in den anderen beiden Techniken eher mit dem Werkzeug kämpfen müssen. Mit separaten Ebenen ist dies kein Problem.
• funktioniert gut für neue Anwendungen, aber wahrscheinlich ist es viel schwieriger, einen vorhandenen zu konvertieren (Sie müssen sowohl Ihre Controller als auch Ihre Ansichten gleichzeitig konvertieren).

Viel Glück!

UPDATE (9/2/2015) Sie können diesen blog-Beitrag erhellend finden: Ссылка durch Blaine Hatab (3/2015). Der Beitrag skizziert drei Ansätze, die der oben skizzierten Gliederung auf hoher Ebene ähneln, aber für ein vollständigeres Bild des weiteren Vorgehens gedacht sind. Die drei Ansätze, die sie auflisten, sind

• Methode 1: Reagieren Sie innerhalb von Rails mit react-rails
• Methode 2: React / Flux Frontend App innerhalb von Rails
• Methode 3: Getrennte Rails API und React / Flux Frontend App

Sie finden diese Beschreibung möglicherweise nützlicher und bietet Referenzen an, um weitere Details zu sehen.