You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I believe this is likely deliberate, but I've noticed the data field in the store is set to null when a subsequent action fails. This is problematic in scenarios where data is being updated and an update fails - in such a case it might be preferable to be able to elect to keep the data in place since it's not actually outdated (indeed the update failed).
Was this a deliberate design decision? Perhaps I'm not seeing a caveat in my logic here?
The text was updated successfully, but these errors were encountered:
It was a design decision as, with null, there is no doubt the method call failed.
My sense is that you want to use the state as a one-record cache rather as wiring to Feathers. This would be similar to #24 where the suggestion was to write a custom reducer acting on the same FULFILLED and REJECTED actions. That reducer would maintain its own store referring to feathers-reducer's state.
It seems there are needs that sit on top of feathers-redux but I haven't had the time to clarify in my mind exactly what they are. As always, suggestions are welcome.
I believe this is likely deliberate, but I've noticed the
data
field in the store is set tonull
when a subsequent action fails. This is problematic in scenarios where data is being updated and an update fails - in such a case it might be preferable to be able to elect to keep the data in place since it's not actually outdated (indeed the update failed).Was this a deliberate design decision? Perhaps I'm not seeing a caveat in my logic here?
The text was updated successfully, but these errors were encountered: