Reputation: 2564
I'm curious if getting an action result is a valid approach, and if it is then how to do that?
For example let's say I have a page with form for creating entities, after successful entity creation I'd like to redirect user to entity's detail view, otherwise (on failure) update the form by error messages. I'd like to perform that without mixing up application layers (eg. to not redirect user in epic/effect after success).
I have a few approaches to this problem in mind:
(observable pattern) dispatch a "trigger" action (entity_add
), then dispatch a success (entity_add_success
) or failure (entity_add_failure
) action somewhere in my epic/effect, wait for failure or success action and do an action - this approach has a noticable drawback: other entities may be created meanwhile and how to distinguish the failure/success actions of entities in that case?
(callback pattern) dispatch a trigger action with additional callback parameter which should be called when action result becomes determined, this approach has a drawback as well (not as big as the previous one though): possibility of creating callback hell.
(service pattern) give up at using flux in that case, use services directly, design drawback: mixing application layers
I'd be glad to hear any ideas.
Upvotes: 2
Views: 85
Reputation: 5632
I used the second option (attaching a callback to the initiating action) several times successfully. It is the best tradeoff in my opinion. I don't see the risk of deeply nested callbacks ("callback hell") because usually, I just need to trigger a single action and then do something simple like navigate to another page.
Upvotes: 1