Is there quick primer on what and why of state machines?
Author here. Yes, I made a series of videos about it, starting here: https://youtu.be/N0OaRdJuVlc
useStateMachine: A ½ kb state machine hook for React
71–80 of 103 posts
Re: useStateMachine: A ½ kb state machine hook for React
#72Earlier quoted context omitted.
Seconded. Plus, you start writing wrapper functions for standard Javascript APIs (e. G. window.setInterval) to force them into Reacts data model.
Why would you do that? What’s wrong with this? useEffect(() => { const interval = setInterval(myFunc, 1000) return () => clearInterval(myInterval) },[]) I think one of the keys to React is not to fear the boilerplate. If you find yourself typing the same code too often, there’s probably a higher level abstraction that you should find, way above the level of setInterval. I find coders often try to DRY up low level cod…
in my experience is better to have customs hooks like useTimeout (react-use library is awesome) so is easier to test. Mocking hooks feels nice, mocking the browser API not so much...
Re: useStateMachine: A ½ kb state machine hook for React
#73Earlier quoted context omitted.
> 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? I'm not sure if I understood what you mean, but note that useState accepts not only the updated state…
Note that you shouldn’t (can’t?) actually pass an async function directly to useEffect, since it returns a promise: https://github.com/facebook/react/issues/14326
I usually use an IIFE to encapsulate the async block inside the useEffect. Works like a charm!
Re: useStateMachine: A ½ kb state machine hook for React
#74Earlier quoted context omitted.
Was just discussing this with a friend this morning. It might be better to describe it in terms of trade-offs versus the overuse of the ‘over-abstraction’ allegation. So, in a lot of cases in the UI, we are turning what is very recognizable and traditionally understood code into a new form to fit the state-machine world view in a more 1:1 way. Again, it’s a trade off. What did we gain from this transformation? I don’…
Did you start programming with OOP or Functional programming? Did learning how to programming in the other form seem difficult to understand why you would do things that way, or seem obtuse vs just using the ways you already know? I think using state machines is just a very different way of looking at code, and it does take some mind bending to think that way; but once you do, it's much easier to blend the code toget…
[deleted]
Re: useStateMachine: A ½ kb state machine hook for React
#75It’s interesting to me how certain design patterns get rediscovered over the years. A few years back FSM’s were a dirty word for crusty Java devs. I myself avoided them for that reason. Then one day I had a perfect use case for one and took the plunge and was amazed by how useful a pattern it is. I’m embarrassed at how long it took me to get hip to it. I’m writing a feature at my job right now that makes heavy use of…
Finite state machines will never not be useful for the same reason regular expressions will always be useful. They're a supremely simple model of computation, making them easy to reason about. The problem with state machines in Java is not the state machine's fault, it's Java's fault.
I feel like you are refuting a point I didn’t make. I was just talking about how we re-discover patterns. My feelings on Java have nothing to do with it.
Re: useStateMachine: A ½ kb state machine hook for React
#76I 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 wh…
> Debugging is painful. You forget one value in your dependency list and the weirdest things happen
This should never happen. The only downside to hooks is that the eslint plugin is _required_, not optional. It is not worth the pain without it, but you'll be in a Whole New World once you do it. Since you can auto-fix every time, it'll become second nature and you'll never forget a dependency again. You can focus on getting your application to work.
Re: useStateMachine: A ½ kb state machine hook for React
#77Earlier quoted context omitted.
My experience is mixed but mostly positive. - Agreed about useState (and useReducer). They’re simple and they get the job done. - Agreed about useCallback as well, it’s a lot of boilerplate. - State in general is a hard problem to deal with, but I’m not sure how hooks in particular encourage it? Class components had the same issue. - IMO, useEffect is a huge footgun. I understand how it works, I understand how closur…
+1 for that eslint plugin, I was just idly wondering if something like that existed earlier this week. Thanks.
Unless your app is peculiar in some way I’d recommend using something like Create React App, which includes it automatically. https://create-react-app.dev
Re: useStateMachine: A ½ kb state machine hook for React
#78Earlier quoted context omitted.
Was just discussing this with a friend this morning. It might be better to describe it in terms of trade-offs versus the overuse of the ‘over-abstraction’ allegation. So, in a lot of cases in the UI, we are turning what is very recognizable and traditionally understood code into a new form to fit the state-machine world view in a more 1:1 way. Again, it’s a trade off. What did we gain from this transformation? I don’…
Did you start programming with OOP or Functional programming? Did learning how to programming in the other form seem difficult to understand why you would do things that way, or seem obtuse vs just using the ways you already know? I think using state machines is just a very different way of looking at code, and it does take some mind bending to think that way; but once you do, it's much easier to blend the code toget…
How are state machines "a very different way of looking at code"? It's basically assembly with jumps as state transitions. A decent programmer already understands this from assembly lessons (and avoids doing it by hand, leaving it to the compiler).
Re: useStateMachine: A ½ kb state machine hook for React
#79Earlier quoted context omitted.
> 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? I'm not sure if I understood what you mean, but note that useState accepts not only the updated state…
Note that you shouldn’t (can’t?) actually pass an async function directly to useEffect, since it returns a promise: https://github.com/facebook/react/issues/14326
True, you cannot do that in useEffect, it will throw you error. And probably your linter will tell you. You can't even use your own or third party hooks in side useEffect. This also throw error I don't know why?
Re: useStateMachine: A ½ kb state machine hook for React
#80Isn'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.
This still mostly sounds like a useReducer. With TypeScript you can guarantee the built code only respects a finite state shape. Depending on the dispatched action, you can just default to returning the previous state - refusing to move unless certain conditions are met.