The Dash framework provides a
setProps function for propagating information back from to Dash from the React layer. So, for example, to trigger a callback listening for the
load property, you would use code like,
As per my experience this code works consistently as it doesn’t depend on previous state of the
load property. Now say instead we want to increment counter (similar to the
n_clicks property of buttons),
props.load == undefined ? 1 : props.load + 1
In some cases this works. In some cases, the
props.load variable is never updated in the React layer, so the counter is never incremented beyond one. However, if I update it manually,
props.load = props.load == undefined ? 1 : props.load + 1
it works consistently. Does anyone know is this behavior is intentional? Is the last code snippet best practice, or should the
setProps function update the react property also?
I’m wondering if this isn’t related to the issue of updating the object in place verse creating a new object.
I know that sometimes, especially with linked variables, this can be an issue. We actually encounter this with
rowData in the grid. Thus, it can’t be used reliably as a trigger, but the pulling the state gives the proper value.
Isn’t this why the useState and useEffect hooks etc have been created in react >16.8. to better handle change detection? Anyway the clue is, as you stated, you need to update correctly in react otherwise you get the described behavior
@jinnyzor Interesting hear to hear that you have faced some of the same challenges. My gut feeling align with yours, i.e. that unexpected behavior is probably due to some scoping/reference issue. Do you see any downside with setting the value “manually” to ensure that it is updated? Do you know if there is any reason that this isn’t the default behavior in Dash (it would be pretty easy to implement)
@jcuypers I was under the impression that it wasn’t necessary as Dash is already keeping track of/updating state via the
setProps function. Is that wrong?
We typically set it manually, with the rowData though, it’s impossible because the underlying grid manipulates in place.
Even comparing previous to current state doesn’t work. This seems to be how React in general works.
The useState and other things for React might be able to handle it, however, if something underlying is directly linked to the property, I’m not sure that this would even be able to fix it.
We will sometimes build propsToSet in the event that there are a lot of properties that need to be set at once, like when the grid is ready, there are a bunch of functions that need to trigger to get the settings passed to it to display properly.
Otherwise, all of our stuff I think we make a variable and then pass that to setProps.
@Emil not sure tbh. I just wanted to express my experiences with react directly when I studied it a bit. I didn’t look under that part of the Dash code