Live data from Hacker News

useStateMachine: A ½ kb state machine hook for React

github.com

41–50 of 103 posts

Re: useStateMachine: A ½ kb state machine hook for React

#41

Earlier quoted context omitted.

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

Not true, see Gaeron's direct reply in the thread you linked to, that's been the standard for 3 years and works like a charm - useEffect specifically is the hook for handling async functions ("impure effects").

Notice the words "pass to useEffect" in the parent comment, and the code snippet in the grandparent they are commenting on. The type of the callback function that useEffect accepts is () => void rather than () => Promise. What's not true about that?

Re: useStateMachine: A ½ kb state machine hook for React

#42
post #10

I 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…

>You forget one value in your dependency list and the weirdest things happen.

This is what I hate in angular1 , there are at least 3-4 ways you can mess up a simple data-binding and there is no error or warning to inform you that something is not right so you waste a lot of time to figure it out.

I used react a few years back but it seems that this days it got hyper complex.

Re: useStateMachine: A ½ kb state machine hook for React

#43
post #41

Earlier quoted context omitted.

Not true, see Gaeron's direct reply in the thread you linked to, that's been the standard for 3 years and works like a charm - useEffect specifically is the hook for handling async functions ("impure effects").

Notice the words "pass to useEffect" in the parent comment, and the code snippet in the grandparent they are commenting on. The type of the callback function that useEffect accepts is () => void rather than () => Promise . What's not true about that?

I reworded it to make it a bit more clear (at least, I thought so) — "pass an async function to useEffect", meaning the argument supplied to useEffect itself, rather than "use directly within" which is ambiguous. Re-added "directly" to hopefully make even more clear. Sorry for the confusion!

Re: useStateMachine: A ½ kb state machine hook for React

#44
post #10

Earlier quoted context omitted.

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…

> 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. I really like Vue 3’s Composition API as a much easier-to-use (IMO) implementation of hooks. It’s conceptually very similar to React Hooks, but the method that defines them only runs once, when the component is instantiate…

The entire concept of reactive objects brings back memories of extreme pain from KnockoutJS days (and terrible performance in complex scenarios to boot). I prefer just working with plain old data structures.

Re: useStateMachine: A ½ kb state machine hook for React

#45
post #5
post #2

Isn'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.

It's only a FSM if the users litter a guard function all over the place, otherwise this is just some deeply nested non-sugar on top of useReducer.

Re: useStateMachine: A ½ kb state machine hook for React

#46
It’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 FSMs. Very testable and the nature of the pattern means you can have a lot of confidence in your state being valid. I highly recommend trying it out even if you don’t adopt this hook or xstate (you can make a FSM fairly easily)

Re: useStateMachine: A ½ kb state machine hook for React

#47

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

This is a Finite State Machine meaning there are a limited set of states and state transitions allowed. useReducer doesn’t have any of the state/transition validation logic which makes it an infinite state machine. Both are very useful. Different use cases though.

Re: useStateMachine: A ½ kb state machine hook for React

#48
post #10

I 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…

[deleted]

Re: useStateMachine: A ½ kb state machine hook for React

#49

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

that's pretty much how I feel, too. I really love the flow of hooks and I write a ton of them -- majority of the logic I write tend to end up in hooks and I really love that.

There's something to having a function that can hold state or load its state on mount, etc.

Re: useStateMachine: A ½ kb state machine hook for React

#50

Earlier quoted context omitted.

> 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. I really like Vue 3’s Composition API as a much easier-to-use (IMO) implementation of hooks. It’s conceptually very similar to React Hooks, but the method that defines them only runs once, when the component is instantiate…

The entire concept of reactive objects brings back memories of extreme pain from KnockoutJS days (and terrible performance in complex scenarios to boot). I prefer just working with plain old data structures.

I prefer working with just plain old setup functions, that are called once.
Post reply on HN