React-SPA: best practice, um mit Aktionen nach einer Action umzugehen?

[dedlfix]

Tach!

Leider gibt es aber auch das Problem, dass ich Fehler, die von der API kommen, nicht mitbekomme. Das durch Redux-Thunk zurück gegebene Promise läuft nie in den Catch-Fall, es löst nur immer die then-Aktion aus.

Ich verwende nur das was in Angular drin ist, also RxJS. Und vielleicht weißt du bereits das, was ich an allgemeinen Dingen sagen kann. In Angular werden neben Netzwerkfehlern auch die Status 4xx und 5xx zu Fehlern umgeschrieben und landen im catch. Das ist wohl aber nicht überall üblich, beziehungsweise einige vertreten die Ansicht, dass es kein HTTP-Fehler ist, wenn die Anwendung nicht kann. Fehler haben dann als 200 zurückzugehen und müssen auf Anwendungsebene behandelt werden, durch Unterscheidung, ob ein Error-Objekt oder ein Datenobjekt in der Antwort steckt.

Eine weitere Erkenntnis, die ich die Tage erst machen musste: RxJS arbeitet ja mit Observables, quasi eine Weiterentwicklung der Promises. Events werden sozusagen als Array betrachtet, oder zumindest etwas, über das man iterieren und auf das man array-like Operatoren (map, filter, etc.) anwenden kann. Das betrifft auch Einmal-Events wie eine Response auf einen HTTP-Request. Als Verwender erstellt man eine Subscribtion und von der wird im Falle eines neuen Ereignisses der next-Handler oder der error-Handler aufgerufen. Nun ist es aber so, dass ein Fehler ein Observable kaputtmacht. Wenn die Subscriber also einen error-Callback-Aufruf bekommen, melden sie sich vom Observable ab. Neue Subscriber erkennen den Fehlerzustand und melden sich gleich gar nicht erst an. Wenn man also abwechselnd gute und schlechte Nachrichten senden möchte, ohne dass der Stream kaputtgeht, ist man auch hier gezwungen, Fehler eine Ebene weiter oben anzusiedeln. Die beiden Vorschläge waren, alles über next abzuwickeln und mit Fallunterscheidung die guten von den Fehler-Objekten zu unterscheiden, oder zwei Streams zu nehmen, über den einen kommen die Gut-Meldungen, über den anderen die Fehlermeldungen. Sieht beides nicht toll aus. next- und error-Handler wäre einfacher zu implementieren und zu verstehen gewesen. Mit anderen Worten: Das Behandeln(müssen) von Fehlern in der Anwendungsschicht ist durchaus gewollt.

dedlfix.