search

yoshuawuyts / barracks

:mountain_railway: action dispatcher for unidirectional data flows
MIT License
177 stars 22 forks source link

new hook idea: onActionDone() #46

Open yoshuawuyts opened 8 years ago

yoshuawuyts commented 8 years ago

Called when an action is done; allows catching timers, and internally provide a stack trace for the done() callbacks - also allows to keep track of which actions are in transit and when they're completed :sparkles:

nickpeihl commented 8 years ago

I'm currently looking for a way to put my choo app in a "busy" state with a loading indicator (spinner) while async processes are running. I think this might be the answer.

yoshuawuyts commented 8 years ago

I'm currently looking for a way to put my choo app in a "busy" state with a loading indicator (spinner) while async processes are running. I think this might be the answer.

Uehhhh, this would be triggered for all actions - it doesn't feel like a great solution to your specific itch hey. Maybe applying reference counting wrappers around your xhr calls and a subscription that sets the state might be a better solution

edit: also these hooks can be considered globals - tying them to specific app logic def doesn't feel great (beyond calling send())

edit: yeah maybe this would work as a last resort solution; def def def not recommended - feels like overloading the application is not a great idea

nickpeihl commented 8 years ago

OK. Thanks for the input. Maybe the subscription is the way to go. :smile_cat:

timwis commented 8 years ago

@nickpeihl I'd recommend putting "isLoading" into your state and having your effects start by calling a reducer that sets it to true and then set it to false when the effect is done

nickpeihl commented 8 years ago

@timwis This is a good idea. If I understand correctly, isLoading could be placed in the app namespace with the appropriate effects/reducers. But the async function I'm running is called from an effect in another model. My understanding is that it isn't appropriate for one model to call effects on another model. So maybe it's better to do this in a view with appropriate callbacks?