Ist Redux nicht nur ein verherrlichter Weltstaat?

Lesezeit: 6 Minuten

Benutzer-Avatar
Ryan Peschel

Also habe ich vor einer Woche angefangen, React zu lernen, und ich bin unweigerlich auf das Problem des Zustands gestoßen und wie Komponenten mit dem Rest der App kommunizieren sollen. Ich habe mich umgesehen und Redux scheint der Geschmack des Monats zu sein. Ich habe mir die gesamte Dokumentation durchgelesen und finde, dass es eigentlich eine ziemlich revolutionäre Idee ist. Hier meine Gedanken dazu:

Staat wird allgemein als ziemlich böse und eine große Quelle von Fehlern in der Programmierung angesehen. Anstatt alles in Ihrer App zu verteilen, sagt Redux, warum nicht alles in einem globalen Zustandsbaum konzentrieren, den Sie ändern müssen, um Aktionen auszuführen? Hört sich interessant an. Alle Programme benötigen einen Status, also stecken wir ihn in einen unreinen Bereich und modifizieren ihn nur von dort aus, damit Fehler leicht aufzuspüren sind. Dann können wir auch einzelne Zustandsteile deklarativ an React-Komponenten binden und sie automatisch neu zeichnen lassen, und alles ist schön.

Allerdings habe ich zwei Fragen zu diesem ganzen Design. Zum einen, warum muss der Zustandsbaum unveränderlich sein? Angenommen, ich interessiere mich nicht für Zeitreise-Debugging, Hot Reload und habe bereits Rückgängig/Wiederherstellen in meiner App implementiert. Es scheint nur so umständlich, dies tun zu müssen:

case COMPLETE_TODO:
  return [
    ...state.slice(0, action.index),
    Object.assign({}, state[action.index], {
      completed: true
    }),
    ...state.slice(action.index + 1)
  ];

An Stelle von:

case COMPLETE_TODO:
  state[action.index].completed = true;

Ganz zu schweigen davon, dass ich ein Online-Whiteboard erstelle, nur um zu lernen, und jede Zustandsänderung so einfach sein könnte wie das Hinzufügen eines Pinselstrichs zur Befehlsliste. Nach einer Weile (Hunderte von Pinselstrichen) kann das Duplizieren dieses gesamten Arrays extrem teuer und zeitaufwändig werden.

Ich bin mit einem globalen Zustandsbaum einverstanden, der unabhängig von der Benutzeroberfläche ist, die über Aktionen verändert wird, aber muss er wirklich unveränderlich sein? Was ist falsch an einer einfachen Implementierung wie dieser (sehr grober Entwurf. geschrieben in 1 Minute)?

var store = { items: [] };

export function getState() {
  return store;
}

export function addTodo(text) {
  store.items.push({ "text": text, "completed", false});
}

export function completeTodo(index) {
  store.items[index].completed = true;
}

Es ist immer noch ein globaler Zustandsbaum, der durch ausgegebene Aktionen verändert wurde, aber extrem einfach und effizient ist.

  • „Zum einen, warum muss der Zustandsbaum unveränderlich sein?“ — dann müssen Sie einen Algorithmus bereitstellen, um festzustellen, ob sich Daten geändert haben. Es ist nicht möglich, es für eine beliebige Datenstruktur zu implementieren (wenn sie veränderlich ist). Nehmen immutablejs und verwenden return state.setIn([action.index, 'completed'], true); Boilerplate zu reduzieren.

    – zerkms

    29. Oktober 2015 um 20:46 Uhr


  • PS: return state.map(i => i.index == action.index ? {...i, completed: true} : i);

    – zerkms

    29. Oktober 2015 um 20:52 Uhr

Benutzer-Avatar
lorefnon

Ist Redux nicht nur ein verherrlichter Weltstaat?

Natürlich ist es das. Dasselbe gilt jedoch für jede Datenbank, die Sie jemals verwendet haben. Es ist besser, Redux als In-Memory-Datenbank zu behandeln, auf die sich Ihre Komponenten reaktiv verlassen können.

Die Unveränderlichkeit ermöglicht eine sehr effiziente Überprüfung, ob ein Teilbaum geändert wurde, da es sich auf eine Identitätsprüfung reduziert.

Ja, Ihre Implementierung ist effizient, aber der gesamte virtuelle Dom muss jedes Mal neu gerendert werden, wenn der Baum irgendwie manipuliert wird.

Wenn Sie React verwenden, wird es schließlich einen Unterschied zum tatsächlichen Dom machen und minimale Batch-optimierte Manipulationen durchführen, aber das vollständige Top-Down-Re-Rendering ist immer noch ineffizient.

Bei einem unveränderlichen Baum müssen zustandslose Komponenten nur prüfen, ob sich die Teilbäume, von denen sie abhängen, in ihrer Identität von den vorherigen Werten unterscheiden, und wenn ja, kann das Rendern vollständig vermieden werden.

  • Ist das nicht ein bisschen voreilige Optimierung? Woher wissen wir auch, dass die Kosten für das ständige Duplizieren unveränderlicher Objekte geringer sind als für das erneute Rendern des DOM (würde das virtuelle DOM von React diese Kosten nicht auch stark mindern?)

    – Ryan Peschel

    29. Oktober 2015 um 21:16 Uhr


  • Nun, GUI-Bibliotheken dieser Art der Optimierung für eine lange Zeit (Referenz: bitquabit.com/post/the-more-things-change) Außerdem ist die Verwaltung einer unveränderlichen Datenstruktur nicht so kostspielig, wie Sie vielleicht denken – wenn beispielsweise ein Knoten geändert wird, muss nur eine einzige Kette von Eltern verkettet werden – der Rest der Knoten bleibt unberührt. So werden wir das nicht duplizieren gesamte Datenstruktur für jede Aktion – wir verwenden die Unterkomponenten, die sich nicht geändert haben, wieder, um eine neue Datenstruktur aufzubauen.

    – Lorefnon

    29. Oktober 2015 um 21:27 Uhr

  • Auch Reacts Virtual DOM-Sache ist nicht gerade dunkle Magie – Zitat aus React-Dokumentation: „Das Generieren der minimalen Anzahl von Operationen, um einen Baum in einen anderen umzuwandeln, ist ein komplexes und gut untersuchtes Problem – Die hochmodernen Algorithmen haben eine Komplexität in der Reihenfolge von O(n3), wobei n die Anzahl der Knoten im Baum ist.

    – Lorefnon

    29. Oktober 2015 um 21:30 Uhr

  • Der Grund, warum React in der Praxis viel besser abschneiden kann, ist, dass: React auf Heuristiken angewiesen ist – also: „Wenn Sie keine stabilen Schlüssel bereitstellen (z. B. durch Verwendung von Math.random()), werden alle Unterbäume jedes Mal neu gerendert werden. Indem die Benutzer die Wahl haben, den Schlüssel zu wählen, haben sie die Möglichkeit, sich selbst ins Knie zu schießen.“ Genauso wie Sie React helfen können, indem Sie stabile Schlüssel bereitstellen, können Sie React auf die gleiche Weise helfen, indem Sie unveränderliche Datenstützen bereitstellen.

    – Lorefnon

    29. Oktober 2015 um 21:30 Uhr

  • In Bezug auf Ihre Reihe von Pinselstrichen beziehen Sie sich bitte auf: facebook.github.io/immutable-js/docs/#/List Zitat aus Dokumenten: Listen sind geordnete indizierte dichte Sammlungen, ähnlich wie ein JavaScript-Array. Listen implementieren Deque, mit effizientem Hinzufügen und Entfernen sowohl am Ende (push, pop) als auch am Anfang (unshift, shift).

    – Lorefnon

    29. Oktober 2015 um 21:32 Uhr


Ja, so ist es!!! Da es keine Kontrolle darüber gibt, wer eine bestimmte Eigenschaft / Variable / einen bestimmten Eintrag in den Speicher schreiben darf, können Sie dies praktisch dispatch irgendein action Von überall aus ist der Code tendenziell schwieriger zu warten und sogar spaghetti, wenn Ihre Codebasis wächst und/oder von mehr als einer Person verwaltet wird. Ich hatte die gleichen Fragen und Probleme mit Redux, als ich anfing, es zu verwenden, also habe ich eine Bibliothek erstellt, die diese Probleme behebt:
Es wird genannt Yassi:
Yassi löst die von Ihnen erwähnten Probleme, indem es keine Boilerplate hat, um den Eintrag im Geschäft zu deklarieren, indem Sie Anmerkungen verwenden (use @yassit('someName'))
Das Aktualisieren des Werts dieses Eintrags erfordert keine Aktionen/Reduzierer oder andere umständliche Codeschnipsel, sondern aktualisieren Sie einfach die Variable like

1176850cookie-checkIst Redux nicht nur ein verherrlichter Weltstaat?

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy