Multi output callbacks support.

[T4rk1n]

Release candidates

pip install dash==0.38.0rc1

Add multi output callbacks support.

• Use a list/tuple of Output as output in callbacks.
• Return a tuple/list of value from the callbacks
  • The returned list must have the same length as the list of output
  • The output props are applied in the order they were declared in the output list.

Usage example:

import dash

import dash_html_components as html
import dash_core_components as dcc
from dash.dependencies import Output, Input, State
from dash.exceptions import PreventUpdate

app = dash.Dash(__name__)
app.scripts.config.serve_locally = True

app.layout = html.Div([
    html.Button('OUTPUT', id='output-btn'),

    html.Table([
        html.Thead([
            html.Tr([
                html.Th('Output 1'),
                html.Th('Output 2')
            ])
        ]),
        html.Tbody([
            html.Tr([html.Td(id='output1'), html.Td(id='output2')]),
        ])
    ]),
])


@app.callback([Output('output1', 'children'), Output('output2', 'children')],
              [Input('output-btn', 'n_clicks')],
              [State('output-btn', 'n_clicks_timestamp')])
def on_click(n_clicks, n_clicks_timestamp):
    if n_clicks is None:
        raise PreventUpdate

    return n_clicks, n_clicks_timestamp


if __name__ == '__main__':
    app.run_server(debug=True, port=6060)

Needs plotly/dash-renderer#91

Tests will fails until I release a rc version of dash-renderer, this is kind of breaking changes as no apps will run if they don't have the right version of dash-renderer (The json payload changed).

Todos:

• rc versions for tests
• re-enable callback validation
• add integration test

[sdementen]

hello,
I just saw the 1.0.0 announcement #469 but could not find this topic in it (multiple output).
Is it too early for it to be included ?

[T4rk1n]

@sdementen This is a standalone update. You can try it right now with:

pip install dash==0.36.0rc1
pip install dash-renderer==0.17.0rc1

[T4rk1n]

@rmarren1 Please review.

[rmarren1]

This allows you to define multiple callbacks to the same output.

For example, adding

@app.callback(Output('output1', 'children'),
              [Input('output-btn', 'n_clicks')])
def on_click(n_clicks):
    if n_clicks is None:
        raise PreventUpdate

    return 'something else'

to the example you give above results in a race condition (sometimes Output 1 is 'something else', sometimes it is the number of clicks).

I think this just needs logic changed in the condition throwing exceptions.CantHaveMultipleOutputs

[rmarren1]

I think we should eventually allow multiple callbacks to be defined for an output component on the condition that those input sets are disjoint (e.g. I1, I2 -> O1 and I3, I4 -> O1 can be simultaneously defined but not I1, I2 -> O1 and I2, I3 -> O1 ). Definitely the scope of this PR, but something to keep in mind as a future possibility when doing above ^

[alexcjohnson]

I think we should eventually allow multiple callbacks to be defined for an output component on the condition that those input sets are disjoint

This discussion might belong in #475, but I'm skeptical of both the idea of multiple callbacks and the disjoint exception. I guess you're imagining cases where one set of inputs disappears and another appears? But you could still have some other global setting that factors in to the final output... so seems to me the cleaner way to handle it is to make the output depend on all of the inputs, but the conditionally-available ones are wildcarded somehow - eg @chriddyp's #475 (comment)

[rmarren1]

Is the idea to make this configurable by the user?

[rmarren1]

Or is this for backward compatibility?

[T4rk1n]

It's for backward compatibility.

[T4rk1n]

@rmarren1

I think this just needs logic changed in the condition throwing exceptions.CantHaveMultipleOutputs

I added validation for multi output and changed CantHaveMultipleOutputs to DuplicateCallbackOutput. There's two tests for the logic, think of any other test cases ?

[rmarren1]

I think there will be an issue encoding the IDs of multi-output callbacks as an ASCII-delimited string, since there will be a backwards compatibility issue with apps that use the ASCII characters we choose as delimiters.

One idea: We already blacklisted ., so we can transform [output1.prop1:output2.prop2] to ...output1.prop1..output2.prop2..., e.g. replace [ and ] with ... and replace : with .., pretty hacky but it should work.

Another idea is to use a different key for self.callback_map. The retrieval of callbacks is an internally facing API and it appears the only reason we use the output ID to identify these is that it is naturally unique per callback. We could use hash(frozenset(['output1.prop1', 'output2.prop2'])), and then just pass a list of outputs back-and-forth between the front-end and back-end like we do with the output id, re-computing the hash when needed. I think this may be more natural, e.g. to test if a callback is multi-output on the front-end you just see if the output is a list rather than if it starts with [.

[alexcjohnson]

Excellent work @T4rk1n, this is going to make a lot of people happy 🎉 💃
I'll leave it up to you how to manage the renderer-dash dependency tango as these two PRs are merged 😅

[alexcjohnson]

@T4rk1n I've already merged this but... was --force-reinstall just for debugging or do we need it going forward if we're using git branches in requirements files?