Live data from Hacker News

useStateMachine: A ½ kb state machine hook for React

github.com

61–70 of 103 posts

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

#61
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…

Regarding useCallback, you can probably skip it in most cases, unless the extra renders are a problem for you.

Linters should help with missing dependencies.

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

#62
post #57

Can anyone provide an example of a situation where something like this is a pragmatic solution? Please also provide the drop dead simple version too and explain why this would be more elegant and intuitive in comparison. Types of examples I am not interested in seeing: - a DropDown list using a state machine (or something similarly simple that’s been solved a million times in a simple way). Edit: I just think stuff l…

I think the value of a state machine is treating all of the associated states in a single conceptual model or level. You can definitely do everything directly in a bunch of if statements and tracking state in separate variables, but that opens yourself to more potential bugs, higher maintenance cost, less big picture understanding, and even larger performance costs (separate codes means the compiler can't optimize as…

I’ll concede I came with a contentious tone, which is probably resulting in a similar retort by a few of you that is mostly using appeal to authority to justify your claims (eg just learn computer science bro, you must not know it).

Sporadic business logic/spaghetti code is a problem in any application. State machines will not magically avoid this. In fact, it should be just as susceptible to it. When sphagetti code shows up under a complex architecture like this, you could be in a world of hurt. There won’t be a few if-statements for you to unwrap, but instead a maze of cascading state updates. Another common thing I’ve seen is the granularity of capturing any and all state updates, and then some. It’s very tedious.

Anyway, I’ve been dead wrong about 70% of things in life before, so I’d be happy to look at a non trivial app written with xstate if anyone’s got a repo.

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

#63

Can anyone provide an example of a situation where something like this is a pragmatic solution? Please also provide the drop dead simple version too and explain why this would be more elegant and intuitive in comparison. Types of examples I am not interested in seeing: - a DropDown list using a state machine (or something similarly simple that’s been solved a million times in a simple way). Edit: I just think stuff l…

Auth logic or similar. Somewhere area in app that may be genuinely complicated and can't go wrong, where you need granular control over a set of states which often have sub states, and where there are things like remote requests to different services occurring. And you can just write this stuff as basically lots of nested if statements but... As an actual example, I have a state machine in an app I work on: 1. check…

That’s actually a good use case, thanks for sharing.

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

#64
post #57

Earlier quoted context omitted.

I think the value of a state machine is treating all of the associated states in a single conceptual model or level. You can definitely do everything directly in a bunch of if statements and tracking state in separate variables, but that opens yourself to more potential bugs, higher maintenance cost, less big picture understanding, and even larger performance costs (separate codes means the compiler can't optimize as…

I’ll concede I came with a contentious tone, which is probably resulting in a similar retort by a few of you that is mostly using appeal to authority to justify your claims (eg just learn computer science bro, you must not know it). Sporadic business logic/spaghetti code is a problem in any application. State machines will not magically avoid this. In fact, it should be just as susceptible to it. When sphagetti code…

Sorry if I was flippant. Here is an example of a minute timer app, which replicates Android's timer app behavior using statecharts: https://codesandbox.io/s/xstate-vue-minute-timer-viz-1txmk

Allow popups to see a live visualization of the statechart.

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

#65

Earlier 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

you're right, good catch. Usually it's the TS compiler that prevents me doing that.

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

#66
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…

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.

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

#68
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

Really? I've been working with hooks for months, with code in production, and I hardly ever pass more than one or two items to the dependency list. The only time I really had any trouble with dependencies was when I was updating appContext inside a hook.

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

#70
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.

There's an eslint plugin specifically for detecting this, which should probably be considered mandatory.

Post reply on HN