Live data from Hacker News

useStateMachine: A ½ kb state machine hook for React

github.com

31–40 of 103 posts

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

#31
post #28
post #20

Earlier quoted context omitted.

Criticism is not negativity. It's valuable when someone in the room challenges ideas and pushes back over-abstraction (if done respectfully and constructively).

Can you even describe the use of a state machine for UIs as "over-abstraction"? To me it seems more like an "under-abstraction", since one usually compiles a more abstract definition into a state machine - often a regular expression or some kind of grammar.

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’t think we get enough back from this trade to structure our code in this new way.

Or to be clear, why would I trade my ability to read a few simple fetch calls that update a simple DOM element for this version? What is the outsized return here?

Just my 2 crypto.

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

#32

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 using a state machine can make the resulting code more elegant in some cases by coupling state changes and effects. But that’s not why they are useful. In my experience, they have been useful because they help map (even mentally) all individual possible states a piece of code can be in, and how the code should behave in each case. In the process, I usually discover and deal with more edge cases, more combination of states and behavior, and as a consequence the code is bigger/fatter. But also more robust.

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

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

Seconded. Plus, you start writing wrapper functions for standard Javascript APIs (e. G. window.setInterval) to force them into Reacts data model.

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

#34

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

We're constantly working on improving the TypeScript experience with XState; there are some new things like `createModel()` that might help!

Actions defined in options are the killer for me at the minute (and guards, but actions are more important generally). I've had to resort to using enums (+ type guards + coercions) for everything. Have you any idea on if/when can get these in the model API? At the minute the API is nice, but not particularly useful with only context & events. The type gen library seems to be a sticking plaster more than anything else: it's clever, but building an NPM package on the fly seems super fiddly (and flat out doesn't work with newer Yarn setups), so movement forward on inference without it would be great

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

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

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

You can use a boolean ref for this in the useEffect to keep track whether it was the first render or not. https://reactjs.org/docs/hooks-faq.html#can-i-run-an-effect-...

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

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

> 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

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

#37
post #33
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…

Seconded. Plus, you start writing wrapper functions for standard Javascript APIs (e. G. window.setInterval) to force them into Reacts data model.

... which is a good idea anyway because you want your code to be testable.

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

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

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 closures work, but it is by far the biggest source of hook-related bugs I’ve experienced.

- This eslint plug-in will solve your dependency list woes: https://www.npmjs.com/package/eslint-plugin-react-hooks

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

#39
post #33

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

... which is a good idea anyway because you want your code to be testable.

...this makes no sense at all.

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

#40

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

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").
Post reply on HN