
Explicit State Machines in React - daneburkland
https://www.afforded.space/state-machines-in-react/
======
runawaybottle
This kind of app architecture looks so disgusting, can’t be on board with
this.

I posted this article earlier today, but it will probably get lost:

[https://blog.usejournal.com/reducing-the-pain-of-
developing-...](https://blog.usejournal.com/reducing-the-pain-of-developing-
apps-cd10b2e6a83c)

It does a good job of explaining why the developer friendliness of this
architecture is an impediment.

Edit:

I just don’t know even know what to say about how common this actions/reducer
stuff is. Like really? We went from:

    
    
      fetch(url).then().error()
    

To this switch statement nonsense?

I’m at a loss for words at how little effort we’re putting into reducing
boilerplate, and making good usable apis.

~~~
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](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 :)

~~~
runawaybottle
Well, do write the dense blog post because it acts as something more
substantial for surveyors who may not put more thought into it other than ‘I
guess this and stuff like Redux is how to do web apps now’. Usage of these
patterns is not an insignificant decision without trade offs, and by no means
right for every app. I can similarly make a case that some of the features you
outlined for tweets could be done in a sensible intuitive way that doesn’t
introduce an explicit state machine.

I’ll leave a good dense article on developer friendliness of some of these
apis that you may want to address as well, since a larger symptom of the
architecture you suggest is boilerplate:

[https://christianalfoni.com/articles/taking-immer-one-
step-f...](https://christianalfoni.com/articles/taking-immer-one-step-further)

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

