Ability to prevent initial callback from firing

[alexcjohnson]

@chriddyp started prototyping this in #1123 and I'm preparing a new PR that will supersede #1123 with a more complete implementation and tests. But a question about how this should work regarding later callbacks:

Currently if all of the inputs to callback C are themselves outputs to other callbacks A and B, we effectively do not treat C as an "initial callback" - that is, it won't trigger without one of its inputs changing, so if A and B both raise PreventUpdate on page load (or layout chunk load), C will not be called.

The question is how this should apply to prevent_initial_call - if A and B both have prevent_initial_call=True, is that equivalent to PreventUpdate so C should not fire? Or is it as though A and B are simply not considered initially and the initialization chain should start at C?

My initial reaction is that this case is not the same as PreventUpdate and C should fire. My reasoning:

• Presumably in this situation you've set the initial values for A and B as part of the layout - so it's not so much that you're preventing an update, it's just that for performance reasons you've already made the update happen.
• If you do want C to fire and we automatically prevent it, you'd have to do something super hacky like add an extra input. On the other hand, if we allow it to fire and you don't want that, all you have to do is set prevent_initial_call=True on C as well.

Anyone care to argue the other side? @Marc-Andre-Rivet @chriddyp @christianwengert do you agree?

[Marc-Andre-Rivet]

@alexcjohnson Initial reaction is also that prevent_initial_callback != PreventUpdate. By setting prevent_initial_callback=True you are excluding these callbacks from the initial callback graph and effectively making follow up callbacks the initial ones.

As we want to conserve backward compatibility, we will want prevent_initial_callback=False to be the default. This raises the issue that once you set True for one callback it might be necessary for the app developer to set all other callbacks to True explicitly to avoid the runaway behavior described above. Would it be possible to add a global prevent_initial_callback as part of this PR. The callback parameter would then serve to override the global/default one as needed. Allowing full flexibility / minimal code changes from the app developer in all scenarios.

[alexcjohnson]

As we want to conserve backward compatibility, we will want prevent_initial_callback=False to be the default.

Absolutely.

Would it be possible to add a global prevent_initial_callback as part of this PR. The callback parameter would then serve to override the global/default one as needed.

That's a good idea, should be an easy add. I'd call the global one prevent_intitial_callbacks though.

[rpkyle]

If you do want C to fire and we automatically prevent it, you'd have to do something super hacky like add an extra input. On the other hand, if we allow it to fire and you don't want that, all you have to do is set prevent_initial_call=True on C as well.

Personally I also prefer that C should fire -- I can imagine why an app developer would want to take advantage of this, and if I understand correctly, this seems to be what a more experienced user of Dash would expect (outside of suspending initial execution of A and B) under the circumstances.

[chriddyp]

👍 That reasoning is sound to me

[christianwengert]

I also agree, I would expect C to fire unless explicitly silenced. I also think that this is a more advanced dash feature.
My use case did not involve callback chains so far, but was to silence callbacks for dynamic inputs (pattern matching) for performance reasons, e.g. if you dynamically add many inputs (several dozens) to the layout the app gets unresponsive for a few seconds because all callbacks are called.