Hacker News Reader

I have actually just started a process like this in a personal react project.

The project uses password auth and websockets, and I was starting to get bugs around refreshing things that I couldn't easily fix.

I had implemented this originally using a singleton pattern for an AuthService and a MessageBus for the websockets. I created those at app start and put them in a React Context.

Converting things to xstate is working great, but it's nearly a rewrite. The approach I had stashed state in a couple different places and had a bunch of callbacks passed around. Now all that state is just in the state machine's context, and what were methods turn into pure functions.

One thing that's a little non obvious is that if you have async operations (ie waiting for a new token) you probably want a state for waiting for that, where you invoke the async method followed by transitions on success and failure. The docs reflect this, but it's not narratively obvious.

Anyway, liking it so far. Changing to a state machine is going to hurt if your code already sucks.

Interesting use case, because for a react project with lots of state management, were you not using redux? And if so, were you using Redux Toolkit? https://redux-toolkit.js.org/

The last major react project I worked on I found that RTK kinda functioned as a state machine definition for the project, and let us work on requests states in our components, i.e. if loading do this, if not yet loaded do that, etc.

I guess with this state machine framework you'd also be managing DOM state in one spot which could be kind of nice. In the big project we had to consider Formik managed input fields, buttons, modals, etc.

Hi, I maintain Redux and created RTK.

I'm going to do my best @davidkpiano impression and point out that "Redux, as typically used, is _half_ a state machine" [0] , in that a typical reducer responds to actions regardless of what the current state value might be, whereas a true Finite State Machine always checks the current state first before deciding if the current event is relevant.

You _can_ absolutely write Redux reducers as true state machines. With `createSlice`, you'd generally need to have a field in the slice that's some kind of enum, and check that first inside of a reducer:

    const someSlice = createSlice({
      name,
      initialState: {status: "x", someData},
      reducers: {
        somethingHappened(state, action) {
          if(state.status === "x") {
            // _now_ consider if the "somethingHappened" action is relevant
          }
        }
      }
    })

Very doable, but not the most ideal syntax, since `createSlice` is focused on "here's an action / thing that happened, here's the reducer that handles that".

On the flip side, you can also use XState state machines as Redux reducers. A state machine is, after all, a function that takes a current state value + some event, and returns a new state.... exactly the same as a reducer function!

David and I have been saying for a while that we'd like to have a more official integration between XState and Redux. A while back, Matt Pocock put together an proof of concept for what a `createXStateSlice` might look like [1]. I actually sat down with David a couple weeks ago and we did some further design discussions about the possibility of using the `@xstate/fsm` package (a smaller version of XState's logic) as a starting point, and generating RTK actions based on that. No code yet, but it seems feasible.

[0] https://dev.to/davidkpiano/redux-is-half-of-a-pattern-1-2-1h...

[1] https://github.com/mattpocock/redux-xstate-poc

That's pretty awesome news regarding your conversations.

I hadn't even thought of the `reducers` slice property. I meant more all the thunky features around the `endpoints` property and the hooks that are autogenerated as a result. In our components this meant we could have for example a form that takes an api model as input and can modify that model on submit. So like,

    ...component boilerplate
        const {
            data,
            isLoading,
            isFetching,
            isError,
            isSuccess,
        } = useGetSomeDataQuery();
        const [updateData, { 
            isLoading, 
            isUninitialized, 
            isSuccess, 
            isError
        }] = useSomeDataMutation();

And then right there is all the state we really need to worry about for a given form as we interact with the API. Though again the missing bits are the stuff managed by Formik, like changed but unsubmitted inputs and etc, but those definitions would also be up top near the RTK stuff and so at least while editing it's visually available. Like you said doesn't necessarily pass muster as an actual state machine unless you have lots of checks in your useEffects or wherever else you're reacting to state changes about the entire state of the component.

Producing visual charts is kind of just a neat side effect of state machines. The real benefit is formalizing a process’s possible state flows in a generally consistent and traceable way. You don’t actually need any tool to do this, disciplined convention can accomplish the same (but a tool is a great forcing function to be sure you’re actually doing it, and a well defined static type system can be useful too).

I agree to your main point, but I think you are underestimating the usefullness of visual charts in giving easy overview for people not invested into the code, to see what is going on.

A few thoughts:

1. If you go and reverse-engineer an accurate Statecharts model of the current behavior, it will probably be weird, and not exactly what you would've done if you'd been workig form the model. You might also discover problems, but fixing the model might be tricky.

2. You really need buy-in by the engineers (not only the managers), and for them invest enough in learning how how to model systems well this way. (Example from UML, not Statecharts: it seemed almost everyone using UML tools was only visualizing their class inheritance hierarchy, and only in a management-slides kind of way. Which I'd say is at most 1% of the benefit.)

3. If you start working from models, the code and model had better agree.

(Background: I made a pretty complete Statecharts DSL compiler for Java, circa '97, and previously worked on various tools and methods for purposes like you describe.)

In automotive applications you have to use a State chart tool (i.e. Simulink Stateflow) for logic, or you more-or-less can't pass any modern software certifications.

So if you are asking "will state charts make my software more reliable" => then the industry response is a large renouncing yes. The unanimous opinion is that they are the foundation of systems analysis and reliability.

I think it would be a good day when someone builds a React front-end for Simulink Stateflow that exports JS the same way we export C for automotive.

You probably correctly noted the gap between the founder's understanding and the ability of the engineering team to articulate ongoing concerns.

Stepping past that, which they shouldn't, maybe in that gap, the founder picked a tool, perhaps prematurely. They also sought out a more experienced engineer to bridge the gap. Who knows if the engineering team even noticed the gap and attempted to improve communications somehow.

I've been in these situations many times at various levels. Your analysis feels very spot on... imho you should trust your instincts, you seem very well grounded.

I have in practice found state machines to be best at adding foundations and a mental model for everyone to share. They are bad at making people think they can get simple flow charts of their business processes. The reality has always been, the real world is complex and regular code is already the best abstraction for dealing with it, especially when someone (founder) wants it to be more simple than it actually is.

If you follow a proper state machine design then it should be exportable as a diagram, I’d assume.

I worked in a team that modeled with state machines and it was useful but I was the most junior member at 7 years experience