useStateMachine: A ½ kb state machine hook for React
1–10 of 103 posts
Re: useStateMachine: A ½ kb state machine hook for React
#2Isn't the useReducer hook already an interface for building state machines? The clue is in the signature of reducer functions, the signature as exactly the same as textbook state transition functions...
Re: useStateMachine: A ½ kb state machine hook for React
#3I can't get over how amazing hooks are and how resistant I initially was to them.
They encapsulate logic so well and do an amazing job being this isolated data/event source.
I find that I reuse them far more than I reuse components.
Re: useStateMachine: A ½ kb state machine hook for React
#4So I think this is basically an abstraction on top of useReducer which itself is kind of a state machine pattern.
It’s a little verbose more my liking but I think it could be powerful for large apps with lots of states.
Re: useStateMachine: A ½ kb state machine hook for React
#5Isn't the useReducer hook already an interface for building state machines? The clue is in the signature of reducer functions, the signature as exactly the same as textbook state transition functions...
The general use reducer is a infinite state machine, while this is a finite state machine. The normal reducer can allow your app to be in any state, while finite state machines let you list the only possible states (like ON, OFF, UNKNOWN; or DRAFT,SENT,BOUNCED) - and offers state transition functions to move between them that can refuse to move unless certain conditions are met.
Re: useStateMachine: A ½ kb state machine hook for React
#6I can't get over how amazing hooks are and how resistant I initially was to them. They encapsulate logic so well and do an amazing job being this isolated data/event source. I find that I reuse them far more than I reuse components.
They fit so well into React it's crazy.
But they're also soooo idiosyncratic which makes them rather ugly on a general level.
Re: useStateMachine: A ½ kb state machine hook for React
#7Thanks for including the comparison to xstate; that's where my mind immediately went when I first saw this. Are there any plans to create a visualizer, similar to what xstate has?
Re: useStateMachine: A ½ kb state machine hook for React
#8I can't get over how amazing hooks are and how resistant I initially was to them. They encapsulate logic so well and do an amazing job being this isolated data/event source. I find that I reuse them far more than I reuse components.
They fit so well into React it's crazy. But they're also soooo idiosyncratic which makes them rather ugly on a general level.
They also come with many restrictions and rules on correct and efficient usage, not all of them checked by ESLint, that make the learning curve a bit brutal.
But yes, insanely useful once you get the hang of them, they enable forms of abstraction and composability that you'll sorely miss when working in other UI frameworks.
Re: useStateMachine: A ½ kb state machine hook for React
#9I'm excited to try this. I've tried xstate many times and always struggled with the typescript, if this Just Works I'll be v happy
Re: useStateMachine: A ½ kb state machine hook for React
#10I can't get over how amazing hooks are and how resistant I initially was to them. They encapsulate logic so well and do an amazing job being this isolated data/event source. I find that I reuse them far more than I reuse components.
Interesting. I have the opposite experience, the more I use them the more clunky they feel.
* If there’s only useState, then everything is mostly fine. All is good.
* To avoid unnecessary re-rendering you’ll have to move callbacks into useCallback. These callbacks then also need to specify all of their dependencies. So many lines of code that are merely noise.
* They encourage having state locally in the component which often breaks down the moment you slightly tweak the design. So much refactoring!
* Dealing with any other (callback-based, stateful) API is confusing. If you want something to execute once initially you can use useEffect with an empty dependency list, but note that then there’s no way of accessing updates values (in callbacks) and everything will reflect the initial state. Often you’ll have to use useRef just to keep track of the current state. Or maybe useState?
* Debugging is painful. You forget one value in your dependency list and the weirdest things happen. Suddenly you have callbacks running in different rendering scopes with different values.
They feel very “brittle”: Once it works the code looks pretty, but when there’s a slight change of requirements you need to rethink everything.