đź“Ł Dash v1.11.0 Release - Introducing Pattern-Matching Callbacks

Dash Python
25

Good question. And in fact exploring the edge cases of behavior in v1.10 added a little more nuance. I mostly mean strictly Input, but let me give some more detail:

  • If none of the Input items are present, we will not fire the callback, regardless of whether some, all, or none of the Output and State items are present. So if some of the Output and State items are present and others are missing, that’s totally fine as long as none of the Input items are present.
  • The only exception is if all of the Input items have multi-item wildcards (ALL/ALLSMALLER) AND at least one Output item is present
  • If any Input items are present (or the multi-item exception), we will fire the callback, and it’s an error if any of the Output or State items is missing.

Now when an Output of a callback we DON’T fire is an Input to another callback, does that other callback fire on initial load? My first reaction was “yes of course it should!” but actually in v1.10 it depends: it will only fire if it has another Input, that either is not itself an Output, or is an Output of a callback that fired.

There is a rationale in which this exact pattern makes sense: if we think of the un-fired callback as effectively having raised a PreventUpdate. That’s behavior Dash has always had, a callback will not get called initially if all of its inputs were prevented from updating. And you could certainly say that this callback was prevented from updating its outputs by a lack of inputs!

On the other hand if we think of the un-fired callback as effectively not even existing until its inputs exist, then its output isn’t an output at all at that point, so the other callback should always get its initial call.

I’m not sure one of these answers is more right than the other, so I’m inclined to go with the PreventUpdate model for stability with v1.10 and before. But I’m open to discussion (as long as it’s quick - I’m working on the fix now :smile:)

2 Likes