search

cassiozen / useStateMachine

The <1 kb state machine hook for React
MIT License
2.38k stars 47 forks source link

useMachine return undefined in production environment #81

Closed s1e-parkplus closed 2 years ago

s1e-parkplus commented 2 years ago

I used useStateMachine in a Nextjs project. It is working fine in the development environment, and it run fine when I locally run Next's build files generated after running build command. However, when I deploy it on a server, the server complains nothing is returned by useStateMachine. Can you suggest any way to resolve this?

image

devanshj commented 2 years ago

The documentation is a bit outdated, there's a breaking change as per #72 so now instead of let [machine, send] = useStateMachine(...) you'd let machine = useStateMachine(...) and later for send you'd machine.send(...). Also instead of machine.value you'd check machine.state.

So looks like your server is installing the latest version and locally you have older version. Sorry for the inconvenience, perhaps just beta version things :P

devanshj commented 2 years ago

@cassiozen could you in the mention in the readme in the beginning that the docs are a bit outdated (linking to the PR for change) in the meantime before we update the docs?

cassiozen commented 2 years ago

Will do. Will also work on the docs soon(ish).

s1e-parkplus commented 2 years ago

Thanks for the suggestion, I fixed the package version and it is working now. I can't find any example either on the npm website or GitHub repo of how to use these new APIs. Can you put an example of how to use these new APIs?

I am using 1.0.0-beta.3 and it is working fine. Can you tell what is new in new versions apart from new APIs? Is there any big benefit of switching to version 3 in terms of functionality?

devanshj commented 2 years ago

The api change is made to accommodate a future feature that is a method called sendT (which is a stricter version of send just like nextEventsT is a stricter version of nextEvents) along with another method called hasState. So as of now, there are no extra advantages of the current api.

It'll take a lot of words to explain the advantage of sendT, which I'll do eventually, but for now the gist is machine.send("FETCH") compiles, machine.sendT("FETCH") will not but if(machine.hasState("idle")) machine.sendT("FETCH") will compile. That is to say, with sendT you can only send events of the current state.

One can sometimes make a mistake like <Button isDisabled={machine.hasState("idle")} onClick={() => send("CANCEL")}>Fetch</Button> but after this api one could leverage the types we'd provide to write something like <MachineButton machine={machine} state="idle" onClick={() => "CANCEL"} /> and now you'd get an error because the event "CANCEL" doesn't exist on "idle" state (only "FETCH" does).

This library is still in beta and lacks a considerable amount of documentation, which will be there soon!