Redux: Ist Redux 'Zeit gekommen und vorbei?

https://github.com/rackt/redux/issues/464

Viele Leute sind ziemlich zufrieden mit Redux. Sie sollten herumfragen - ich bin nicht wirklich qualifiziert, diese Frage zu beantworten. Ich würde sagen, wenn Ihre App a la Facebook sehr datenintensiv ist (viele verschachtelte Entitäten mit komplexen Beziehungen), ist es eine gute Idee, in ein GraphQL-Backend zu investieren und Relay zu lernen. Ich habe nur gute Dinge darüber gehört.

Redux ist natürlich expliziter und löst das deklarative Abrufen von Daten nicht für Sie. Es gibt Versuche, Redux und GraphQL zu

Redux ist viel niedriger als Relay und nicht mehr "Vergangenheit" als einfache JS-Objekte und -Funktionen "Vergangenheit". Relais ist ein Framework, und Redux, ohne die Überprüfung der geistigen Gesundheit, verfügt über zehn 10-Liner-Funktionen. Daher sollte es keine Überraschung sein, dass sie unterschiedliche Bereiche haben. Wählen Sie aus, was für Sie am besten funktioniert, und lassen Sie es uns wissen.

Das deklarative Abrufen von GraphQL ist erstaunlich, erstklassig. Relay verfügt jedoch hauptsächlich über eine HoC-API, die per se nicht deklarativ ist. Wenn Relay eine flexiblere API anbieten würde, die vom Komponentenbaum entkoppelt ist, könnte eine ordnungsgemäße Redux-Bindung geschrieben werden?

Ich denke, es sind zwei Arten von Systemen, die zwei unterschiedliche Probleme lösen.
Dieses Ticket ist wie Tischler, die fragen, ob die Zeit des Hammers abgelaufen ist.
Graphql-basierte Systeme sind meiner Meinung nach eine überentwickelte Lösung für viele Apps. Umgekehrt sind Apps mit komplexen Datenstrukturen höchstwahrscheinlich unterentwickelt, wenn sie mit Redux erstellt werden.

Graphql-basierte Systeme sind meiner Meinung nach eine überentwickelte Lösung für viele Apps. Umgekehrt sind Apps mit komplexen Datenstrukturen höchstwahrscheinlich unterentwickelt, wenn sie mit Redux erstellt werden.

Guter Weg, um es auszudrücken; So fühle ich mich auch.

@gaearon mach weiter so mit redux! Eines der besten Werkzeuge! Ich benutze es in 5 großen und 2 kleinen Apps in meiner Firma und liebe es!

@gaearon mach weiter so mit redux! Eines der besten Werkzeuge! Ich benutze es in 5 großen und 2 kleinen Apps in meiner Firma und liebe es!

:100:

Ich denke, sie sind nicht dasselbe:

• Relay - zum Lösen des Datenabrufmanagements vom Server
• Redux - zur Lösung der Zustandsverwaltung von Anwendungen

Viele komplexe Anwendungen enthalten einen Status, der nicht mit dem Server zusammenhängt, den Sie verwalten müssen. Ich werde argumentieren, wenn Sie Relais verwenden, werden Sie sehen, dass Sie am Ende auch Redux brauchen. Im Gegenteil, Relay scheint ein sehr schöner Schub zu sein, aber nur für Server-bezogene Dinge

Die Frage ist, in welcher Beziehung Relay zu flussmittelinspirierten Designmustern steht. Wo endet Relay, wann brauchen wir Redux? Ist Relay Flux 2.0?

Das Todo-Relay-Beispiel: Macht es Redux überflüssig?

Vielleicht gibt es eine Möglichkeit, Ihrem Reduzierer mitzuteilen, wie und wann er sich auf und von GraphQL abbilden soll? Nicht etwas zu sagen, das nicht komplex ist, aber was ist der einfachste Weg, dies sinnvoll zu machen.

Sie müssen mehr darüber erfahren, was Relais ist. Es sind nicht ein paar hundert Codezeilen, die sicher sind!

@oriSomething Du bist nicht ganz richtig. Relais löst auch viel Staatsmanagement.

@gyzerok Ich habe den clientseitigen Anwendungsstatus gemeint

@oriSomething Ja, ich spreche über den clientseitigen Anwendungsstatus

@gyzerok Ich muss es verpasst haben. Kannst du mir einen Link dazu geben?

@oriSomething gibt es keinen speziellen Link, da Relay ihn implizit verwaltet. Vielleicht können Sie versuchen, FB-Gespräche über Relay zu sehen. Sie sprechen darüber, wie Relay das Cache-Problem löst. Clientseitiger Anwendungscache = Status. Ich erinnere mich nicht an ein bestimmtes Gespräch, sorry.

@oriSomething der einzige Ort, an dem Entwickler eine explizite hier .

@gyzerok ok, gibt es in diesem Fall eine

@oriSomething Wenn ich Sie richtig verstanden habe, Datennormalisierung auf dem Client und zum Zusammenführen von Daten aus Abfragen in einem einzigen Speicher.

@oriSomething yes, es tut => https://facebook.github.io/relay/img/Guides-Containers-HOC-Relay.png
Überprüfen Sie: https://facebook.github.io/relay/docs/guides-ready-state.html#content

Nur wenn auf dem Client nicht genügend Daten vorhanden sind, sendet Relay eine Anfrage an den Server, um weitere Daten zu erhalten.

Redux ist viel niedriger als Relay und nicht mehr "Vergangenheit" als einfache JS-Objekte und -Funktionen "Vergangenheit". Relais ist ein Framework, und Redux, ohne die Überprüfung der geistigen Gesundheit, verfügt über zehn 10-Liner-Funktionen. Daher sollte es keine Überraschung sein, dass sie unterschiedliche Bereiche haben.

Deshalb habe ich slim-redux.js nur zum Spaß erstellt - eine Version von Redux ohne Kommentare, Entwicklerwarnungen und Überprüfung der

@IwanKaramazow Ich denke, ich war nicht klar genug, was ich damit sagen

@oriSomething kannst du ein Beispiel geben?

Stimmen Sie @mattapperson voll und

@IwanKaramazow Ich denke, @oriSomething spricht zum Beispiel über den clientseitigen Formularstatus

Ich bin wegen GraphQL von Redux => Relay umgezogen. Die meisten Ressourcen in meiner Anwendung waren hierarchisch. Sie machten natürlich Sinn, verschachtelte Einheiten zu sein. Es war erstaunlich, einen Cache dieser Modelle in Redux zu behalten. Ich hatte eine vernünftige Sicht auf meine Daten und konnte mit den fantastischen Redux-Devtools schnell iterieren.

Aber ohne GraphQL musste ich mehrere Roundtrips durchführen, um Remote-Ressourcen dem Redux-Baum zuzuordnen.

1. / resource1-list
2. / resource2-list? resource1 =
3. / resource3-list? resource2 =

Offensichtlich ist dies ein Problem mit REST, nicht mit Redux. Hätte ich früher einige Redux-GraphQL-Bindungen gesehen, würde ich diese vielleicht verwenden. Die Übernahme von Relay hat sich in meiner Anwendung kaum geändert. Anstelle von @connect ich Relay.createContainer . Beide Produkte haben dieselbe Architekturvision mit unterschiedlichen APIs. Ich habe einen kurzen Beitrag dazu geschrieben.

Ich verwende derzeit sowohl Redux als auch Relay / Graphql und obwohl Relay für das Abrufen von Daten erstaunlich ist, kann ich mir vorstellen, immer Redux zu verwenden. Ich benutze derzeit Redux aus zwei Gründen und kann mir vorstellen, in Zukunft weitere Gründe zu finden

1) Verschiedenes Status, der von Komponenten geteilt werden muss, die nicht in der Datenbank vorhanden sind
2) Formularvorbereitung. Ich habe tatsächlich einen Teil meiner Anwendung, in dem ich eine Symbolleistenkomponente mit einer Senden-Schaltfläche und eine Bedienfeldkomponente habe, die alle meine Eingabefelder enthält. Wenn ich das Formular eingebe, entprelle ich meine Eingabe in einem in Redux gespeicherten "Formularreduzierer", damit meine Symbolleiste vor dem Senden auf die Daten zugreifen kann.

Auch Redux Devtools ist fantastisch.

Mann oh Mann. Ich habe heute über Relay gelesen und muss zugeben, dass der Code weder leicht zu lesen noch leicht zu verstehen ist. Ich habe mir einige Beispiele für Redux angesehen und konnte die Kernkonzepte durch einfaches Lesen des Codes erfassen.

Das Tutorial oder das Todo- Beispiel wirken alles andere als elegant. Ich denke, React und FLUX sind stolz darauf, einfach zu sein. Ich habe dieses Gefühl noch nicht von Relay.

Angesichts der starken Bindung von Relay an React und der relativen Komplexität der meisten Apps war ich in letzter Zeit mehr an Falcor interessiert. Aufgrund seiner vielversprechenden Benutzeroberfläche passt es sehr gut zu dem asynchronen Verhalten in Redux. Und weil es von React entkoppelt ist, kann ich es überall in meiner App einfacher verwenden. Außerdem ist das serverseitige Rendern noch nicht vollständig gebacken , was für mich

Ich mag auch React -Resolver , der einer Art "Relay Lite" ähnelt. Dies ist möglicherweise das Beste für sehr einfache Projekte oder Projekte, die auf REST-APIs von Drittanbietern basieren.

@timdorr Haben Sie versucht, Ihren gesamten Bundesstaat in Falcor zu speichern? Wenn Ihre Reduzierungen beispielsweise ein Falcor-Objekt verwenden.

Noch nicht. Ich bin immer noch im experimentellen Modus und habe größere Fische zum Braten bei meinen Projekten, daher habe ich ihm noch nicht genug Aufmerksamkeit geschenkt.

Ich habe mit Falcor herumgespielt und kann es nur empfehlen. Tatsächlich arbeite ich gerade daran, eine Redux-App in ein Falcor-Backend zu integrieren. Es gibt Ihnen nicht die Abfrageaggregation von Relay, aber es hat eine sehr ausgefeilte Cache-Schicht in seiner Client-Bibliothek, die ein Überholen verhindert. Ich denke, das ist vielleicht gut genug, aber die Zeit wird es zeigen.

@gaearon Wie ist das Schreiben einer React-Webanwendung mit deklarativem Datenabruf mit dem Schreiben derselben App in Elm zu vergleichen?

Mir scheint, der Hauptunterschied besteht darin, dass das Abrufen von Daten mit Relay & GraphQL deklarativer ist (Elm fordert Sie auf, eine URL anzugeben, und es liegt an Ihnen, die zurückkommenden Daten zu sortieren), und alles andere ist in Elm deklarativer .

Tatsächlich scheint es, dass das Elm-Ökosystem von einer Portierung von Relay / GraphQL profitieren könnte.

In Bezug auf die Abfrageaggregation gibt es die Model.batch-Methode . Es dauert entweder ein Intervall (in Millisekunden) oder einen Scheduler, aber ich finde nicht viel Dokumentation zu Schedulern.

Wenn es Ihnen nichts ausmacht, wenn ich Sie frage, wie integrieren Sie Redux und Falcor? Alle meine Versuche haben mich frustriert.

Ich würde mich auch für ein Redux-Falcor-Beispiel interessieren. Ich habe alle Falor-Dokumente gelesen und bin damit einverstanden, dass es viel einfacher ist als Relay / Graphql. Wenn auch weniger mächtig.

Informationen zu der Beziehung von Redux zu Relay und zur sinnvollen Verwendung finden Sie unter: https://github.com/facebook/relay/issues/114

Das Wesentliche ist, dass Relay möglicherweise Daten aus mehreren Quellen (Backend, lokale kurzlebige Daten usw.) verarbeitet und somit andere Flux-Implementierungen ersetzt, die Sie möglicherweise verwenden.

https://github.com/facebook/relay/issues/168#issuecomment -135169255:

Beachten Sie, dass Relay eine Implementierung des Flux-Musters ist (kann sich Flux selbst ersetzen? ;-).

Wir verwenden sowohl Redux als auch Relay stark bei OpenGov. Es ist wahr, dass unser Ordner reducers/ seit dem Wechsel zu Relay viel kleiner geworden ist. Wir haben jedoch festgestellt, dass Redux für die lokale Statusverwaltung auf Anwendungsebene immer noch sehr nützlich ist. Vielleicht wird Relay es eines Tages auch in diesem Bereich ersetzen. Aber wie @josephsavona es einmal ausdrückte, ist die "Redux-Architektur" wirklich nur ... Funktionen :) Selbst wenn Sie eines Tages von Redux aus der Bibliothek wechseln, werden Sie wahrscheinlich weiterhin unveränderliche Statusaktualisierungen, reaktiven Datenfluss und Reduzierer verwenden Funktionen usw. auf absehbare Zeit. Das ist der wertvolle Teil von Redux IMO, nicht unbedingt die Bibliothek mit <100 Zeilen, die in diesem Repo vorhanden ist. (Oh, und die Community natürlich.)

Ich würde sagen, wenn Ihre App a la Facebook sehr datenintensiv ist (viele verschachtelte Entitäten mit komplexen Beziehungen), ist es eine gute Idee, in ein GraphQL-Backend zu investieren und Relay zu lernen.

Einverstanden, aber ich würde behaupten, GraphQL + Relay ist eine gute Investition, selbst für Apps mit bescheidener Größe, insbesondere für neue Projekte, die von vorne beginnen.

Was haltet ihr von https://github.com/gyzerok/adrenaline?

Nicht genau passend, da es kein Relay verwendet, aber was halten Sie von diesem einschätzenden Full-Stack-Ansatz aus der Meteor-Community? https://github.com/mattkrick/meatier

Nur eine tiefe Architektur wie GraphQL / Relay oder Datomic / Om.Next kann das Objekt- / relationale Impedanzproblem lösen ... Hier sind meine Gedanken - Feedback wird geschätzt.

GraphQL / Relay: Das Ende von Redux?

Es sieht so aus, als ob sich viele Leute für dieses Thema interessieren (Relay / Redux, GraphQL und Reduzierung der Komplexität). Ich arbeite an einem Entwurf für einen einfachen, aber funktionalen GraphQL-Client, der sehr gut mit dem Redux-Ansatz für den App-Status zusammenarbeitet.

Neugierig, was die Leute über diese Designprinzipien denken: https://github.com/apollostack/apollo-client/pull/7/files?short_path=83772ba

Ich füge hier nur meine 2 Cent hinzu: Ich glaube nicht, dass Redux ein Ende hat. Es ist einfach und schön und in vielen Fällen ausreichend. Das JS-Ökosystem ist so schnell und schwer aufrechtzuerhalten, und Redux ist wie React in gewisser Weise ein Meilenstein, auf den wir uns für einige Zeit verlassen können. Wir können unseren Workflow einfach nicht jeden Monat weiterentwickeln (oder zumindest nicht), und ich denke, Redux ist derzeit eine wirklich gute Option. Relay (und das Abrufen von Daten im Allgemeinen) ist bei vielen Projekten einfach nicht erforderlich…

@gaearon Es ist ein paar Monate her, seit Sie diesen Beitrag verfasst haben, und Sie haben gerade auf einer React-Konferenz einen Vortrag über Redux gehalten. Wo würden Sie sagen, dass wir uns jetzt in Bezug auf die GraphQL-Integration mit Redux im Vergleich zu Relay / oder einer Kombination aller drei befinden?

@likeabbas Wenn Sie nach einer GraphQL-Redux-Integration suchen, versuchen Sie es mit Apollo Client: http://docs.apollostack.com/apollo-client/index.html

Wir haben noch keine 100% ige Feature-Parität mit Relay, aber wir nähern uns.

@gaearon , um die Frage von @likeabbas zu wiederholen : "Wo würden Sie sagen, dass wir uns jetzt in Bezug auf die GraphQL-Integration mit Redux im Vergleich zu Relay / befinden, oder vielleicht eine Kombination aller drei?"

Ein paar kurze Gedanken. Redux ist ein generisches Framework, das ein Gleichgewicht zwischen gerade genug Struktur und gerade genug Flexibilität bietet. Als solches bietet es Entwicklern eine Plattform, um eine angepasste Statusverwaltung für ihre Anwendungsfälle zu erstellen und gleichzeitig Dinge wie den grafischen Debugger oder die Middleware wiederzuverwenden. Dieser Anwendungsfall scheint nicht zu verschwinden. Anstatt "ist Redux 'Zeit gekommen und gegangen", wäre eine vielleicht interessantere Frage: Wenn Sie einen GraphQL-Client erstellen, ist es sinnvoll, auf Redux aufzubauen?

Worauf ich antworten würde, dass es nicht klar ist, dass es eine richtige Antwort gibt. Das Bauen auf Redux kann von der Integration profitieren (gemeinsam genutzte Tools, gemeinsam genutzte Daten), während das Erstellen eines benutzerdefinierten Ansatzes mehr Arbeit bedeutet, jedoch domänenspezifischere Tools ermöglicht und möglicherweise eine bessere Leistung ermöglicht. Wie bei vielen Dingen in der Softwareentwicklung kommt es auf den Anwendungsfall an!

@ Josephsavona : Das ist eine großartige Zusammenfassung von Redux! Möglicherweise müssen wir das irgendwo für die Dokumente stehlen :)

Ja, der Titel dieses Threads ist nicht optimal und die Frage scheint irgendwie erschöpft zu sein. Vielleicht ist es Zeit, die Diskussion an einen anderen Ort zu verlegen.

>.> lock the issue

Ich werde das einfach schließen. Ich bin mir nicht sicher, ob überhaupt eine Lösung zu finden ist. Redux funktioniert für einige Leute und das ist gut genug für mich.

Hoppla, falscher Knopf. Entschuldigung 😄