[daneburkland]

`whateverYouNeedToDo` needs to have knowledge of the application's state. Spreading application logic around event handlers is problematic. In sufficiently complex applications, we're better off simply 'passing messages' (https://en.wikipedia.org/wiki/Message_passing). Perhaps I'll start on a follow-up post which better outlines those benefits :)

[runawaybottle]

Can give me an example?

Let’s say I need to update state.tweets, what do I need to know here?

I know the fetch got handled, then I have my state and new data, what does message passing solve here? Or even better, if it solves something, how do you justify this level of scaffolding that it warrants that trade off?

Edit:

I’ll make one other suggestion. If you believe for sufficiently complex apps something like what you are suggesting makes sense, then provide that sufficiently complex example.

It’s very hard for people to assess this stuff on a simple request/response handler. By this I mean it actually gets used in the simplest possible use cases, where it has no business being used.

[daneburkland]

Whether the user has switched from "Home" -> "Latest Tweets", whether the app has encountered an error since the request was made, whether the user has interacted with a previously loaded tweet, whether the user has quickly scrolled and another request is pending.

Thanks for the feedback. The benefits of modeling application logic with state machines are increasingly apparent as complexity grows. But that complexity makes for a dense blog post :)