daneburkland

Agreed! Always trade offs. Will give that a read. Thanks again.

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 :)

`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 :)

What do you do inside of the then and error blocks? _That_ is what this post (and state machines) are concerned with. Passing messages to a single entity (reducer in this case) that decides how to handle them, rather than spreading that logic across components, event handlers etc.

In terms of boilerplate, libraries like Xstate do a great job on that front. The goal here is to provide a from-the-ground-up overview of using explicit state machines.

Totally. Interesting parallel I hadn't considered. Set-it-and-forget-it SaaS is a sweet place to be :)

Agree, culture is perhaps the elephant in this room.