7 ms·

Everything starts simple. > If your app isn't complicated, I'd just useState Your very trivial example of a button with a counter, gets very complicated as so

by midrus 5y ago

Everything starts simple. > If your app isn't complicated, I'd just useState Your very trivial example of a button with a counter, gets very complicated as soon as you need the counter value available outside of its children... like in a header or the sidebar, etc. See? Now tell me how you do this, without rerendering the entire application on each change. "Just use useState" works fine as long as it is local state, and you're sure it will stay local in the future. Which is also compatible with XState and any other solution as long as you don't go crazy like reduxallthethings.

ojkelly 5y ago
I don't think an FSM will own your entire state in any sufficiently complex app. Especially considering things like Apollo in the GraphQL world that excel at remote and local state. If you don't yet have an FSM controlling your UI, then it's hard to understand what it replaces. If you only have a few screens, then it's possibly more overhead than it's worth. When you start getting complex, and you can't hold every view and how to get to every other view in your head - then it starts to become useful. Start with the router. All the normal access rules can be implemented with an FSM. But additionally, you can pre-empt changes and block transitions before they happen. Next multi-step forms. The contents of the forms can stay in whatever state system you're using for them. You just need to expose enough information that you need in your state machine to transition between steps. I've found an FSM is a helpful place to store form state _per step_ when that step is completed. And finally the rest of your application flows (note not state). > Your very trivial example of a button with a counter, gets very complicated as soon as you need the counter value available outside of its children... like in a header or the sidebar, etc. See? Now tell me how you do this, without rerendering the entire application on each change. Not the parent comment but, XState manages this problem the same way Redux does with a `useSelector` hook[0]. [0] https://xstate.js.org/docs/packages/xstate-react/#useselector-actor-selector-compare-getsnapshot https://xstate.js.org/docs/packages/xstate-react/#useselecto...
- midrus 5y ago
  You're saying the same thing I'm saying.

by midrus 5y ago

ojkelly 5y ago

I don't think an FSM will own your entire state in any sufficiently complex app. Especially considering things like Apollo in the GraphQL world that excel at remote and local state. If you don't yet have an FSM controlling your UI, then it's hard to understand what it replaces. If you only have a few screens, then it's possibly more overhead than it's worth. When you start getting complex, and you can't hold every view and how to get to every other view in your head - then it starts to become useful. Start with the router. All the normal access rules can be implemented with an FSM. But additionally, you can pre-empt changes and block transitions before they happen. Next multi-step forms. The contents of the forms can stay in whatever state system you're using for them. You just need to expose enough information that you need in your state machine to transition between steps. I've found an FSM is a helpful place to store form state _per step_ when that step is completed. And finally the rest of your application flows (note not state). > Your very trivial example of a button with a counter, gets very complicated as soon as you need the counter value available outside of its children... like in a header or the sidebar, etc. See? Now tell me how you do this, without rerendering the entire application on each change. Not the parent comment but, XState manages this problem the same way Redux does with a `useSelector` hook[0]. [0] https://xstate.js.org/docs/packages/xstate-react/#useselector-actor-selector-compare-getsnapshot https://xstate.js.org/docs/packages/xstate-react/#useselecto...

midrus 5y ago
You're saying the same thing I'm saying.