React-native Redux Sollte Geschäftslogik in Aktionen oder Reduzierungen sein

Question

Ich habe begonnen, am reactnative - redux Projekt zu arbeiten. Ich bin völlig neu in diesem funktionalen Paradigma. Meine Frage ist einfach: Ich habe verschiedene Login/Anmeldeoptionen und eine davon ist Facebook. In meiner Aktionsdatei erhalte ich Token von Facebook. Ich sollte es zur Überprüfung an den Server senden. Diese Anforderung kann mehrere Ergebnisse zurück

• Dieser Benutzer ist neu, öffnen neue Benutzerseite
• Dieser Benutzer bereits vorhanden und genehmigt, offene Anwendungsseite
• Dieser Benutzer ist bereits vorhanden, aber hasnt genehmigt SMS-Bestätigung noch offen sms Bestätigungsbildschirm

und die Frage ist; Wo sollte ich diese Logik setzen? Sollte ich alles bei Aktionen machen oder einfach Events zum Reducer schicken und es entscheiden lassen. Ich bin darüber verwirrt.

Dank

Answer 1

Per den Redux FAQ entry on "where should my business logic live?":

genau keine einzige klare Antwort gibt es, was Stücke von Logik in einem Druckminderer oder eine Aktion Schöpfer gehen sollten. Einige Entwickler bevorzugen "fette" Action-Ersteller, mit "dünnen" Reduzierern, die einfach die Daten in einer Aktion aufnehmen und sie blind in den entsprechenden Zustand verschmelzen. Andere versuchen, Aktionen so klein wie möglich zu halten und die Verwendung von getState() in einem Aktionsersteller zu minimieren. (Für die Zwecke dieser Frage, andere Asynchron-Ansätze wie Sagas und Observablen fallen in der „Aktion Schöpfer“ Kategorie.)

Dieser Kommentar fasst die Dichotomie schön:

Nun, das Problem ist, was zu in den Action-Creator und was in den Reducer, die Wahl zwischen fetten und dünnen Action-Objekten. Wenn Sie die gesamte Logik in den Aktionsersteller einfügen, erhalten Sie fette Aktionsobjekte, die im Grunde die Aktualisierungen für den Status deklarieren. Reduzierer werden rein, dumm, add-this, entfernen Sie das, aktualisieren Sie diese Funktionen. Sie werden leicht zu komponieren sein. Aber nicht viel von Ihrer Geschäftslogik wird da sein. Wenn Sie mehr Logik in den Reducer legen, erhalten Sie nette, dünne Action-Objekte, die meisten Ihrer Datenlogik an einem Ort, aber Ihre Reducer sind schwieriger zu komponieren, da Sie möglicherweise Informationen von anderen Zweigen benötigen. Sie enden mit großen Reduzierern oder Reduzierern, die zusätzliche Argumente von oben in den Staat nehmen.

Ich besprach auch die Idee von „dick“ und „dünn“ Reduzierungen in meinem Blogbeitrag The Tao of Redux, Part 2 - Practice and Philosophy.