#Can XState replace "conditions"?

1 messages · Page 1 of 1 (latest)

dapper nova
#

Hello, I am curious if it is possible to replace conditions like if with xstate?
I currently have a lot of nested conditions and they look complicated. I would like to rewrite them into declarative way, just to have everything in one place and to have a visualizer.
I have some input data, a lot of complicated-nested conditions, and finite final UI states.
In fact I do not have state transitions, just initial data -> logic -> ui components to show

Is it possible and it is worth to use xstate for such cases?

jolly ridge
#

Maybe/probably, i guess it depends on your problem!

#

your logic will end up mapping to two different concepts in xstate/state machines

#

some of your logic will disappear, because the states of your machine will encode what should happen in what "situation"

#

if this event comes in while we're in this state, do this

#

and then you have "guards"

#

when this event comes in and we're in this state AND this guard returns true (i.e. "request is valid") then do this

#

guards can look at the context of your machine in order to make decisions

dapper nova
#

Is it possible to have condition "after" condition, so xstate checks first condition and then go inside and check nested condition and so on, so visually you can see how the logic "flows". Because otherwise I would have just super complex guard and there will be no benefits from plenty of ifs

jolly ridge
#

sure, just have a guarded transition, and in the next state it goes to you can have another guarded entry or always transition

#

that will give you the branching that I think you want

#

basically you need to use guards in conjunction with states

#

if you just have loads of guards isn't going to be a mess, they're only meant for simple if, else-if, else logic

#

I think there were plans to add special boolean logic helpers for guards so you could visualise things like if (guard-a and guard-b) or guard-c then transition

#

@spare venture am I imagining this?

#

so have a more generic guard and specify some parameter when you reference it

dapper nova
#

I do no quite understand how can I have one condition after condition, the visual editor only allows "State" after "Transition"

jolly ridge
#

you can have more conditions inside the state, you can right click on the state and "add self transition"

#

and you can make that transition an "always" transition by selecting it and clicking on the "i" icon on the right

#

and setting the trigger to always

shut mortar
#

You can do something like this for splitting up the if-statements. In the example, it even does an call to some other service to model "asynchronous" evaluations in an if-statement hell.

jolly ridge
#

yeah exactly like that, the states act as nodes to branch out from

dapper nova
#

Wow, looks like what I needed, thank you very much guys ❤️