Just nosey about the dev team's UI state management experience

[corysimmons]

Hi team! 👋

I know CodeSandbox has went through a few state management libraries. I think mobx-state-tree, then Cerebral, now Overmind. As you have a really large, production app, with lots of UI state, I'm particularly interested in your dev team's thoughts about UI state management. Feel free to answer any of these in any order.

1. What has your experience with each been like?
2. Do you plan to move to anything new, anytime soon?
3. Do you like global state?
4. Is Overmind overkill? That is, if you had it to do over again, would you pick something lighter?
5. What are your thoughts on finite state machines like XState?

Thanks in advance if you choose to answer any of this. Continuing to wish your team well with your company!

@CompuIves

[christianalfoni]

Hi @corysimmons and thanks for your questions! Let me try to answer them to the best of my ability 😄

Some history
Originally CodeSandbox was written in Redux and I actually did a talk on why we moved to Cerebral (Which used mobx-state-tree as the state store): https://www.youtube.com/watch?v=uni-dG6-Rq8. In short Redux at that time had a ton of boilerplate across a multitude of files, making it very hard to reason about the codebase and how thing actually worked. It also had several performance issues in the UI related to the considerations you have to make leaning on traditional "value comparison" of React. Wrote an article about this here: https://itnext.io/updating-uis-value-comparison-vs-mutation-tracking-9f6fe912dd9a. The later move to Overmind was really a matter of moving to TypeScript, it also moved from the rather exotic sequence API of Cerebral to something more approachable as at this point we started growing a team.

Redux: At the time CodeSandbox ran on Redux it was a lot of boilerplate and there was no strong concept of dealing with actual application logic and side effects in Redux. You had thunks, but no strong opinions on how to organise it. Since CodeSandbox has a LOT of complex client side logic, it became very difficult to reason about "What actually happens when you open a sandbox?"

Cerebral: By using the concept of sequences we were able to co locate all the complexity of the logic and make things way more readable. Also with the help of the devtool there was never any question about what state changes were made where and what was actually running at any time in the client, including side effects which it has a first class concept for.

Overmind: With our jump to TypeScript Overmind gave us all the benefits of Cerebral, but with an API surface that was compatible with TypeScript. Overmind is running today and still serves the client well. That said, we have identified new things we want to fix (see point 2.)

2. It is unlikely that we will move away from Overmind on the current client, just because of the complexity of doing so. But we are building something new where we have taken a step further. The general challenge with these state management solutions, including Mobx, redux etc. is that they do not deal very well with asynchronous logic. It is a lot of await and try/catch with untyped errors and not being able to cancel out side effects when the state of the application changes. Also now with a growing team we wanted to embrace React more as it has matured a lot with primitives and patterns in terms of state management. Still it is quite low level, but instead of creating a framework/state management tool, we decided to rather create a React application architecture. This is still a work on progress, but you can read a lot about the ideas here: https://react-states.csb.dev

3. Yes, we like global state 😄 As mentioned before there was a huge challenge in CodeSandbox where a lot of related logic was split between many components, making it very hard to reason about. And nobody like props drilling. But a more important point and mental shift for us is that we do not consider our UI Components the application. The application is a process unrelated to any UI. This is where state and logic is managed. The UI components becomes strict consumers of this state, simplifying their implementation and helps us to focus on the complexity of state/logic and UI separately. It also has benefits in terms of testing and devtooling.

4. Overmind is definitely not overkill as it has allowed us to move faster, not slow us down. The important thing with a growing team is to have a common understanding of how we think about state, logic, side effects, testing, UI etc. Overmind has very strong opinions on this out of the box, but as mentioned we are going "lighter" in terms of just using primitives from React and designing our own strong opinions on top of this to ensure a bigger team has a common understanding of how we implement features in CodeSandbox.

5. One of the biggest shifts in the ecosystem now is state machines. Its biggest challenge for adoption, in my opinion, has been its academic terms and bad examples. Who builds traffic lights on the web? Exploring state machines, also XState, we have identified that there are some core simple ideas that makes up 99% of the benefit of using a concept of state machines. (Here is a video explaining a lot of that: https://www.youtube.com/watch?v=ul_3ABrpj64). There is really no need for a full fledged library and XState does not have the best TypeScript support... as it was not written for TypeScript initially. So we are rather incorporating the main important principles of state machines into our new architecture: https://react-states.csb.dev

I hope these were helpful answers! Please let me know if something was unclear or I missed answering something, we can just continue the thread here 😄 👍

[corysimmons]

@christianalfoni Thank you so much for taking the time to go into all that detail! react-states looks really interesting. I like how the library itself is just a collection of simple utils using React primitives. I'm researching it now looking at the excalidraw-firebase repo (the code looks really clean and explicit/readable 🎉 ).

Few more questions about react-states specifically:

1. Does the useEffect stuff you're doing help with cancelling promises? Sorry if you mentioned this in the video but it was a bit overwhelming.
2. Are you guys introducing react-states in parts of CodeSandbox now? Just curious how react-states scales and
   a bit worried about adopting it until it's been battle tested.

[christianalfoni]

Hi again 😄 Glad it was helpful!

1. The video does not go into much detail on dealing with effects, just that they are a product of a state change. In react-states you see this in more detail with "environment effects". Because of the nature of reducers conditionally handling actions by looking at its current state we do not actually use promises at all, we use subscriptions (events in the current docs). Let me know if you have any more questions about that shift 😄

2. We are using it for "the next big thing", but we are still iterating on the terminology we use and also how many utils should be part of the package itself, and what is specific to us. But we do plan to talk a lot more about this as we release the new product sometime next year 😄

[corysimmons]

we use subscriptions (events in the current docs)

Nice :D

how many utils should be part of the package itself

I will say that the original 3 utils (transition, transform, exec) seemed very approachable and refreshing, whereas seeing the "Convenience utilities" in the docs was a bit scary (but might be nicer/easier with more real-world examples). I wonder if breaking those out to their own docs page, and possibly even their own @react-states/utils package) would help for adoption. Not super important, especially since react-states seems mostly internal at this point.

Thanks again for all your help. It's always really interesting to see how big projects handle these sorts of things.