[daneburkland]

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.

[runawaybottle]

A lot of my feedback is less about what the article is hoping to investigate, and more about the proliferation of these types of patterns in codebases.

We can still contain the logic on how to handle that request in a single function:

  fetch(url).then(updateState(whateverYouNeedToDo(response))

I don’t think explicit state machine orchestration helps app architecture when we have been succinctly achieving the same thing with way less needlessness.

So I guess a lot of my frustration is that this stuff is literally in someone’s bootstrapped todo app right now, or crud app. The normalization of articles like this in effect normalized code like this everywhere. I’d like to at least just yell back a little to reverse some of these trends that got adopted with little thought about trade offs.

In other words, don’t even think about reaching for the explicit state machine scaffolding if all you really want to do is use immutable data and a fetch request. Ironically, the thing that needs to be explicitly declared is this warning.

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