Ich erstelle ein Front-End für ein Suchsystem, bei dem fast alle Benutzeraktionen dieselbe asynchrone Aktion auslösen müssen, um die Suchergebnisse erneut abzurufen. Wenn ein Benutzer beispielsweise ein Schlüsselwort eingibt, müssen wir @ abrufe/api/search?q=foo, und wenn sie später eine Kategorie auswählen, holen wir/api/search?q=foo&categoryId=bar. Ich hatte ursprünglich separate Aktionstypen fürFETCH_RESULTS, SELECT_CATEGORY, DESELECT_CATEGORY usw. Ich habe einen Ersteller für asynchrone Aktionen für @ erstellFETCH_RESULTS, aber die anderen sind synchron. Je mehr ich darüber nachdenke, desto mehr müssen sie die Ergebnisse vom Backend erneut abrufen und den App-Status basierend auf der Antwort vom Backend aktualisieren.

Wäre es für mich sinnvoll, den einzelnen Async-Action-Creator für jede Änderung zu verwenden? Oder ist es besser, asynchrone Aktionsersteller für jede einzelne Benutzeraktion zu verwenden (Schlüsselwort, Kategorie oder Filter auswählen)?

Ich denke, der Vorteil von granularen Aktionen wäre, dass die Ereignisse genauer widerspiegeln, was der Benutzer getan hat (z. B. wenn der Benutzer eine Kategorie ausgewählt hat), anstatt in die Nutzlast zu schauen, um herauszufinden, was sich tatsächlich geändert hat, aber sie sind sich alle ziemlich ähnlich.