So I’ve been working a lot with state variables lately, and one thing I noticed is that if you have a running action and then a different action updates a state variable used in the first action, it won’t have the updated value until the action is run again.
For example:
myStateVar
Type: number
Initial value: 0
Action 1
if ({{!state.myStateVar}}) {
await {{actions.newAction2.trigger()}};
}
return {{state.myStateVar}}
Action 2
{{state.myStateVar}} = 1
What I’d expect to happen when running Action 1 is:
Enters if because myStateVar initializes with 0
Triggers Action 2, which updates myStateVar to 1
Action 1 returns 1
But in actuality, Action 1 returns 0. When checking myStateVar it also says that its current value is 1.
Now, my question is whether this is the expected/desired behavior the developers intended.
Because I think this could be very useful, say you need a value from a state variable, but the variable hasn’t received its value yet. So you could then use while (...) until the variable has updated.
Looks like this behavior is by design. When an action is called, a copy of the current state value is placed into the state variable. Changes made to this copy inside the action, like state.newVariable = 123, only affect that copy and not the original state.
When another action is triggered, a new copy is created and modified independently.
And at the end of the action, the changes made to the copy, or rather the final value of the copy, are written to the original state, I assume?
If I may ask, what is the reasoning behind this original - copy model? Because if it’s like this, I’d probably stop using state variables and rather define a variable like
<script>
var myVar = 0;
</script>
in the Custom Code section. That way, changes across actions are reflected immediately.
Each {{state.var = 'value'}} immediately writes the change to the variable.
However, due to some limitations, accessing the updated values is restricted within actions, state variables, components, etc., inside JS steps.
We believe that for some of your use cases, it might indeed work better to store the value in window. However, there’s a risk that component updates might not work correctly with that.
But in general, the logic for state, ui, and actions variables inside a JS step is like this:
A JS step is essentially like a JS function that expects parameters like ui, state, actions, and so on.
When the step is executed, the current state is gathered and passed in as those parameters to the function.
Changes to these objects from within the JS step are immediately listened to and update the global app state.
But! Changes to the app’s state do not reflect in the already running step. To get the new values, you need to re-run the step or have it be the next step.
Thank you for the thorough explanation; now it’s clear to me why it works this way. And with the understanding that the variables are updated after each step, I might be able to make it work. Sorry for asking so much lately!
- this is how we know you are using UI Bakery!