3 ms·

I recently had a conversation about joining a startup with a really interesting, but complicated, product mostly actualized in a complex JavaScript spa (react).

I recently had a conversation about joining a startup with a really interesting, but complicated, product mostly actualized in a complex JavaScript spa (react). They wanted a more senior engineer to join so as to help untangle some of the complications and lead the juniors (that built the thing already? Unclear) out of some kind of rats nest they'd been coded into. I never saw the code so I'm not exactly sure what this meant. Anyway the founder asked me to look into this xstate platform before our call and asked a lot of questions about my understanding of state machines. The founder had this idea that if the team built out a bunch of state charts using this product and like, diagrammed their entire app, that was their ticket out of whatever sticky situation they were in. I was pretty skeptical at the time and remain so now. This seems like an interesting analysis method, and implementing SPAs in a state machine way (each component being a state machine) is alright I guess, but, especially for a startup, building out these charts feels like a waste of time. To me it seems like fielding early customer feedback and driving features is more important. My guess is that the engineers had a pretty good idea what was going on but were struggling to explain it in a way the founder understood, or maybe were slowing down on feature implementation, I don't really know, but I'm always so skeptical of slapping more tools and plugins and diagrams onto the stack of things the engineering team has to worry about. I'm curious if anyone has been on a team in a situation as I've vaguely described here and found state charts useful in getting them out of a hole?

robopsychology 3y ago
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
eyelidlessness 3y ago
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).
- hutzlibu 3y ago
  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.
migf 3y ago
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.
- komali2 3y ago
  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/ 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.
  - acemarke 3y ago
    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-1hd7 https://dev.to/davidkpiano/redux-is-half-of-a-pattern-1-2-1h... [1] https://github.com/mattpocock/redux-xstate-poc https://github.com/mattpocock/redux-xstate-poc
Jailbird 3y ago
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.
neilv 3y ago
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.)
aetherspawn 3y ago
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.
cloverich 3y ago
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.

robopsychology 3y ago

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

eyelidlessness 3y ago

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

hutzlibu 3y ago
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.

migf 3y ago

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.

komali2 3y ago
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/ 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.
- acemarke 3y ago
  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-1hd7 https://dev.to/davidkpiano/redux-is-half-of-a-pattern-1-2-1h... [1] https://github.com/mattpocock/redux-xstate-poc https://github.com/mattpocock/redux-xstate-poc

Jailbird 3y ago

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.

neilv 3y ago

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

aetherspawn 3y ago

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.

cloverich 3y ago

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.