[Feature Request] allow for callbacks without Inputs

[ghaarsma]

I would like to request a feature enhancement to allow for callbacks to not have an input, but rely on having a State and an initial call / load to perform useful work.

Currently Dash does not allow for callbacks without inputs. I think this makes sense in most cases and the check/limit will aid most novice Dash developers.

My counter example is where we have a callback that does have a State (but no real Inputs), but depending on the value of the State, during the initial load will fetch some values from a external database and update Options and Value of a dcc.Dropdown

At the moment we solve this be adding a fake-input in the following way:

    layout = html.Div(
        [
            dcc.Dropdown(id=f"my-dropdown"),
            dcc.Interval(id="fake_input", n_intervals=0, max_intervals=0, interval=1),
        ]
    )

    @callback(
        Output("my-dropdown", "options"),
        Output("my-dropdown", "value"),
        Input("fake_input", "n_intervals"),
    )

But this makes the callback map much messier and larger then it needs to be, specially if you have multiple drop downs.

I have tried to comment out the 3 JS lines that does the check in dash_renderer.dev.js and everything seems to work just fine as intended for my particular use case.

So: keep the check mostly as is, but allow for callbacks that lack Inputs, but have States and have prevent_initial_call as False. Optionally, If we think it's to dangerous to allow no-input-callbacks in the general sense, we could add a kwarg to the callback to bypass the check. Something like: allow_no_inputs = True for individual edge cases like my counter example.

[gvwilson]

@T4rk1n thoughts on this? Is it in keeping with the architecture of Dash or too far away?

[T4rk1n]

You can usually just put an Input on a property that is not going to change like an id to get that effect.
Example

app.layout = html.Div(id="content")

@callback(Output("content", "children"),  Input("content","id"))
...

[ghaarsma]

Greg, Philippe,

Thank you for your consideration. If have implemented the workaround as suggested by @T4rk1n , which I like better then my original dcc.Interval fake input. But that leaves me with the following:

1. We have a very large callback map, for a large application. See the spaghetti below.

2. There are currently 96 locations in our repo/app where I would have to add fake inputs. Almost all because of callbacks that have a State, but no real input to fill in Dropdowns.
3. I have don't some benchmarking (Chrome Dev tools) that shows we could reduce (re)load times by about ~100 mSec, due to reduced amount of scripting on the browser side, caused by a smaller callback map.

At the moment check for zero input size callbacks (!inputs.length) is done on the client side (dependencies.js). Would it not make more sense on the Python side, so we can easily make the check more sophisticated?

1. You can report what the callback name is and where it is located.
2. It will still work fine if dash debug=False. Right now you get no warnings/errors (unless you open up browser dev tools) and your dash website will likely not load.
3. Some validation (validate_background_inputs) is already done on the Python side, so it will not be the first!
4. On the Python side we can Error if no inputs and no state and Warn if only states. Or add a kwarg per callback to limit/control checking.

If it helps, I would like to contribute. Not sure if I can totally pull that off as the JS side is a bit intimidating, but I'm willing to give it a try.

[T4rk1n]

Would it not make more sense on the Python side, so we can easily make the check more sophisticated?

Pushing those validation to the frontend was a design decision since we used to have more than just the Python backend (r,julia). We don't really support those anymore, but the concept has other benefits too like being easier to defer to debug mode so it doesn't impact performance of production apps.

The background callbacks used to be Python only which is why they have validation there.

You can report what the callback name is and where it is located.

This could be added to the dependencies as a key like func_name and used in the frontend message too, would be especially useful now that callbacks output can be duplicate.

For the implementation of no inputs/initial callback you could just remove the !inputs.length check and instead fire those callbacks initially.

We have this action to hydrate the initial outputs:

dash/dash/dash-renderer/src/actions/index.js

Lines 50 to 55 in 6afd6f9

	export function hydrateInitialOutputs() {
	return function (dispatch, getState) {
	validateCallbacksToLayout(getState(), dispatchError(dispatch));
	triggerDefaultState(dispatch, getState);
	dispatch(setAppLifecycle(getAppState('HYDRATED')));
	};

And getting those callbacks without inputs to show in this function:

dash/dash/dash-renderer/src/actions/dependencies_ts.ts

Line 265 in 6afd6f9

export const getLayoutCallbacks = (

[ghaarsma]

@T4rk1n , I noticed Persistent callbacks#3771. We installed Dash 4.2.0rc03 and gave it a try on our simplified test application. It worked great for us.

Thank you for considering this feature request.