Redux: Vorschlag: Umbenennen von "Filialen" in "Reduzierstücke"

-1 die Lernkurve in diesem Repo fühlt sich bereits steil an. Machen wir es nicht noch steiler, indem wir eine neue Terminologie für neue Flussmittelbenutzer einführen.

Intern können sie Reduzierer genannt werden, halten Sie sie öffentlich als Speicher, damit es einfacher ist, zu groken.

Ich finde es ehrlich gesagt verwirrender, wie es jetzt ist. Völlig anekdotisch, aber ich habe mehrere Leute im IRL erlebt, die sich darüber Gedanken gemacht haben, wie ein "Laden" staatenlos sein könnte.

Die Hauptmerkmale von "Geschäften" im traditionellen Flux sind, dass sie 1) den Zustand halten und 2) Änderungsereignisse ausgeben. Beides trifft in Redux nicht zu.

Ich stimme zu, dass wir die Terminologie klären und in einigen Fällen eine bessere Benennung finden müssen.
Ich denke, als ersten Schritt sollte es etwas JSDoc geben, dann würde auch ein Terminologieabschnitt helfen.
Generell müssen wir ein gewisses Maß an Konstanz aufrechterhalten.

Ich frage mich, ob es einen Begriff gibt, der nicht nach FP klingt, aber auch kein „Laden“ ist.
Domänen?

OTOH heißt es bereits Redux, also klingt zumindest „Reducer“ verwandt.

Wie wäre es mit "Schrittaktualisierungen" oder "Steppern", die Ihren Zustand einen Schritt nach vorne bringen. Ich habe gesehen, dass dies in der Elm-Literatur verwendet wird, mit einer Funktion namens step , update oder next

Domains enthalten node.js-Gepäck.

Sie sind keine Speicher in ihrer Funktionsweise, aber Sie legen Ihre Zustandslogik dort immer noch ähnlich wie Flux-Speicher. Sie sind Staatsmanager, wie es sich für Flux-Läden gehört.

Reducer ist jedoch in Ordnung, wenn Sie seinen Namen ändern möchten.

Vor allem, weil "Reduzierer" eine genaue Beschreibung dessen ist, was sie eigentlich sind :)

Updater? Klingt beschreibend + weniger snobistisch als Reduzierer.

Ich mag reducer auch

Ich glaube, ich verstehe nicht, warum "Reducer" snobistisch ist. Ist es nicht besser, den eigentlichen Begriff zu verwenden, als einen neuen zu erfinden, der weniger aussagekräftig ist?

Ich denke, beides kann gültig sein, und es hängt davon ab, aus welcher Sicht Sie es sehen: ein _Reduzierer_ von Aktionen (in den Zustand) oder ein _Aktualisierer_ des Zustands.

"Updater" impliziert, dass es mutativ ist. "Reducer" macht deutlich, dass Sie einen neuen Zustand zurückgeben und den alten nicht ändern.

Das ist ein starker Pluspunkt, denke ich, kann bei dem Problem helfen, dass Redux mit Mutationen nicht richtig funktioniert

Ich schätze die Notwendigkeit, Redux für Leute, die mit FP nicht vertraut sind, freundlich zu halten, aber wir können das mit einer besseren Dokumentation lösen. Ich mag die aktuellen Dokumente, aber auf den ersten Blick sind sie etwas überwältigend. Eine gute Dokumentationsseite, die die vertrauten Dinge (Action Creators, Reducer Logic) über die fortgeschrittenen Dinge (Middleware, Hot Reloading) stellt, wäre sehr hilfreich.

Und doch müssen wir, dem schnellen Wachstum der folgenden hier nach zu urteilen, etwas richtig machen :)

Ich bin offen dafür, "Stores" in "Reducers" zu ändern, wenn dies zusammen mit besseren Dokumenten geschieht.

Das wesentliche Element besteht darin, die „Es ist wie Flux, aber besser, keine Sorge“-Atmosphäre zu bewahren. Ich möchte nicht, dass die Leute denken, dass es Reflux oder so ähnlich ist, was wie Flux klingt, aber einige seiner schönen Eigenschaften bricht. Ich möchte auch nicht, dass sie denken, dass sie FP lernen müssen. Solange wir das beibehalten können, bin ich mit dieser Änderung einverstanden.

Vorschlag, bei dem ich mir weniger sicher bin: Wenn wir die Redux-Klasse in Store umbenennen (denken Sie daran: Ihre beiden Zwecke bestehen darin, den Zustand zu halten und Änderungsereignisse auszugeben), dann wird die API der obersten Ebene:

const store = createStore(reducers);

<Provider store={store} />

Das kommuniziert die Idee ziemlich gut, denke ich. Reduzierer sind der Ort, an dem Ihre Geschäftslogik liegt, aber sie selbst sind keine Geschäfte.

Ich mag das, obwohl sich store.dispatch dann falsch anfühlt.

Ja, das ist die eine Sache, die ich nicht wirklich mag, aber die anderen Methoden machen Sinn: store.getState() , store.setState() , store.subscribe()

Jetzt, wo ich darüber nachdenke, „verschicken“ wir nicht wirklich etwas.
Ugh, Namensgebung ist ein Kaninchenbau.

Ok, was wir bisher haben sind:

• Aktion (Schöpfer)
• (speichern) Reduzierstück
• Middleware-Funktionen
• Callback (Hörer) Funktionen
• etwas, das die Funktionsaufrufkette auslöst (genannt Dispatcher)
• etwas, das den veränderlichen Zustand hält (mit Settern und Gettern)

Vielleicht können wir einen Schritt zurücktreten und die Namensgebung überdenken?

Vielleicht ist store.dispatch nicht so schlimm. Wir können nur erklären, dass wir anstelle vieler Stores einen einzigen Store haben und Sie ihn aus Reducers zusammenstellen. Keine Stores = kein separater Disponent erforderlich, daher ist dispatch direkt im Store verfügbar.

@gaearon Ich stimme zu.

@emmenko Gute Zusammenfassung. Bei jeder Aufschlüsselung der Terminologie sollte zwischen _Aktionsersteller_ und _Aktionen_ unterschieden werden. Es sollte auch zwischen der _Dispatcher_- oder _Dispatch-Strategie_, die Middleware + Reducer umfasst, sowie der _Dispatch_-Methode, die einen _Dispatch-Zyklus_ auslöst, unterschieden werden.

Lass uns das machen:

• Benennen Sie Geschäfte in Reduzierstücke um
• Benennen Sie die „Redux-Instanz“ gemäß https://github.com/gaearon/redux/issues/137#issuecomment -113252359 in Store um
• Erklären Sie, dass Sie, wenn Sie in traditionellen Flux Stores die Augen zusammenkneifen, Reduzierstücke darin gefangen sehen

Möchte jemand die neuen Docs-Bemühungen leiten? Es bedarf einiger Strukturierung: ein Glossar, eine README-Datei, ein einfaches Tutorial für die Inbetriebnahme und vielleicht eine ausführlichere Anleitung zu Designentscheidungen.

@gaearon Ich werde mich freiwillig melden, um dies zu leiten :) Ich habe bereits eine Gliederung begonnen.

Danke :+1:

Ich werde mich freiwillig melden, um das zu leiten

Vielen Dank! :+1: :+1: :+1:

Persönlich hätte ich als Endergebnis wirklich gerne eine automatisch generierte Website mit:

• Einstieg
• Tutorials
• Live-Beispiele

...und als nettes Feature:

• generierte Dokumentation a-la docco (zB: wie jasmine ), damit der Quellcode klar erklärt wird

Aber mit Markdown und jsdoc anzufangen ist natürlich ein erster Schritt ;)

Richtig, ich denke, der erste Schritt besteht darin, die Dokumentation in Markdown-Form zu schreiben, dann können wir sie auf eine wirklich schöne Dokumentationsseite portieren. :+1: auch für JSDoc. Ich werde heute Abend noch einen letzten Versuch unter https://github.com/gaearon/redux/pull/87 unternehmen, aber ich bin mir nicht sicher, ob sich Flow-Anmerkungen an dieser Stelle lohnen, es sei denn, wir befreien die Codebasis von Funktionsüberladungen. (Oder es sei denn, jemand bringt mir bei, wie man sie richtig tippt, ohne dass sich Flow beschwert.)

Ich denke, Flow hat keine Priorität.

+1 für Geschäfte, die als Reduzierer bezeichnet werden.

Ich habe diese eher deklarativen, staatenlosen Dinge nicht gerne als Geschäfte bezeichnet.

Ich mag die neuen Namensideen. Ich würde auch vorschlagen, Connector in Subscription . Connector ist sehr allgemein gehalten, und obwohl ich bekomme, dass es den Status und den Dispatcher von Redux mit seinen Kindern verbindet, denke ich, dass ein Abonnement eine bessere Beschreibung dessen ist, was passiert. Es ist ein bisschen umständlich, dass Sie mit Ihrem Abonnement einen Dispatcher mitnehmen, aber ich denke, das ist in Ordnung.

-1 für Läden, die als Reducer bezeichnet werden, als Name ist es für neue Benutzer (zumindest diejenigen ohne funktionale Programmierkenntnisse) nicht sehr intuitiv. Vielleicht wären Updater oder Transformer besser oder Store Updater, wenn wir es expliziter machen wollten.

„Transformers“ wurden schon einige Male vorgeschlagen. Es deutet nicht auf eine veränderliche Natur wie Updater hin, ist zugänglicher als Reducer und trägt nicht die „Speicher“-Konnotation von Stores.

Wie gefallen euch Transformatoren?

+1 für Reduzierstücke

Ein gutes Argument für „Reduzierer“ ist, wie @faassen auf Twitter anmerkte, der [].reduce() : (state, action) => state . Bla bla bla"

eckig verbreitet sich wie ein Lauffeuer und verwendet Wörter wie

• Direktive
• isolieren
• transkludieren

Ignorieren von Programmierung, Transformieren und Reduzieren sind verschiedene Dinge. Ich würde den Namen wählen, der am genauesten ist.

Wenn sie keine Daten speichern, nennen Sie sie nicht Stores.

Wandeln Sie von einer Form in eine andere um oder reduzieren Sie von vielen Werten auf einen?

Transformator => Karte
Reduzierer => reduzieren

Klingt für mich nach reduziert.

Ich bin auch für reducers ! :+1:

Lassen Sie sich von Elm inspirieren. https://github.com/evancz/elm-architecture-tutorial#the-basic-pattern

Das beste Wort wäre update . Store ist Unsinn, es war schon immer "Model". Sie müssen das Rad nicht neu erfinden oder die Leute verwirren.

Mein Problem damit, sie Updater zu nennen, ist, dass die Leute denken könnten, dass sie mutativ sind. Wenn die Namensgebung helfen kann, die nicht-mutative Natur zu verdeutlichen, wäre das ein großer Bonus.

Wandeln Sie von einer Form in eine andere um oder reduzieren Sie von vielen Werten auf einen?

Ich akkumuliere. „Wie eine Aktion einen Zustand in den nächsten Zustand verwandelt.“ Konzeptionell reduzieren sie über viele Aktionen den anfänglichen (undefinierten) Zustand, und die Memoisierung ist nur eine Optimierung.

Zustandstransformator

Versuchen Sie, so viel wie möglich nicht neu zu erfinden/wiederentdecken. Die Leute nennen es reduce , scan , fold und update .

reducer scheint aus Javascript-Perspektive korrekt zu sein...
Sehen Sie nicht den Wert, um es von einem Konzept einer anderen Sprache zu benennen, auch wenn es genauer ist.

Habe keinen festen Standpunkt dazu, was es sein sollte, aber IMO sollte es etwas sein, das die Art der Berechnung am genauesten darstellt. Wenn dies für die meisten Programmierer ein unverständliches Wort ist, kann dies durch Dokumentation ausgeglichen werden.

@vramana es ist kein map , es ist ein reduce , da es die zuvor angesammelten state und ein neues action und ein neues state zurückgibt

Wenn Sie ein Array aller Aktionen Ihrer App hätten, würden Sie diese Funktion verwenden, um es auf den endgültigen App-Zustand zu reduzieren:

function reducer(state, action) {
  // switch (action.type) ...
  // return state;
}
const finalState = allAppActions.reduce(reducer, initialState);

Was Sie nun wirklich haben, ist ein stream von actions in der Zeit, was konzeptionell dasselbe ist wie ein Array, aber in der Zeit (Sie können es auf stream von state s).

Ich stelle es mir gerne als Projektion (von einem Ereignisprotokoll auf eine Datenstruktur) vor.
DB-Leute nannten dies früher "materialisierte Ansichten".

Ich mag reduzieren oder falten, es wird von verschiedenen Communities gut verstanden

Ich bevorzuge Transformers gegenüber Reducern: Es ist klar, was es aus dem normalen englischen Gebrauch des Wortes bedeutet.

Reduzierstücke.
Erstens ist es eine Javascript-Bibliothek und Javascript hat [].reduce(reducer, initialState) .
Zweitens ist Redu(cer)x bereits im Bibliotheksnamen enthalten.
Drittens, https://blog.javascripting.com/2015/06/19/flux-no-more-stores-meet-reducer/ , verwenden andere Personen und Bibliotheken den Begriff „Reduzierer“.

Reducer ist genau und hat einen Präzedenzfall in Vanilla JS. Keine Ahnung, wie man das verbessern könnte.

Reduzierstücke soll es dann sein.

(Verfolgen Sie den Fortschritt in #140)

Gelegentlich finde ich alte Diskussionen, die sie „Läden“ nennen, und staune, wie lächerlich verwirrend das im Nachhinein war.

"Staatscontainer"?

Ja, das war eine gute Abwechslung :)