[wip] previous state support

[chriddyp]

depends on plotly/dash-renderer#25

experimental usage

# -*- coding: utf-8 -*-importdashfromdash.dependenciesimportInput, Output, PrevInputimportdash_html_componentsashtmlimportdash_core_componentsasdccapp=dash.Dash()
app.scripts.config.serve_locally=Trueapp.layout=html.Div([
html.Button('Button 1', id='button-1', n_clicks=0),
html.Button('Button 2', id='button-2', n_clicks=0),
html.Pre(id='output')
])
@app.callback(Output('output', 'children'), [Input('button-1', 'n_clicks'), Input('button-2', 'n_clicks')],prev_inputs=[PrevInput('button-1', 'n_clicks'),PrevInput('button-2', 'n_clicks') ])defupdate_output(b1, b2, prev_b1, prev_b2):
s=''' Button 1 was clicked {} → {} times and Button 2 was clicked {} → {} times '''.format(prev_b1, b1, prev_b2, b2)
ifb1>prev_b1:
s+='\nWhich means that Button 1 was clicked'elifb2>prev_b2:
s+='\nWhich means that Button 2 was clicked'returnsif__name__=='__main__':
app.run_server(debug=True)

[akhmerov]

Isn't figuring out the source of the click a more common pattern than needing the previous state? The alternative to this PR would be to pass the event emitter and event type to the callback.

[mikesmith1611]

An alternative would be to allow an Output element to have multiple callbacks assigned to it. This way you can have a callback function for each input separately. Although I have no idea if this is even possible!

[chriddyp]

Isn't figuring out the source of the click a more common pattern than needing the previous state?

It may be, but providing the previous state allows you to do both.

An alternative would be to allow an Output element to have multiple callbacks assigned to it.

I'm afraid that this would cause too much ambiguity (for example, what should happen if the same input was in both outputs - would you call both callbacks or just one?) - I think that there was a discussion about this in the community forum somewhere.

[akhmerov]

It may be, but providing the previous state allows you to do both.

Is it guaranteed that all events are possible to get by diffing with the previous state?

[akhmerov]

Another question: is there anything that is not possible to do if the event information is provided to the callback, as opposed to the previous state?

[ned2]

My inclination is that I would also prefer the capacity to determine the origin of the Event/Input/State rather than diffing against a previous state.

Even if you can achieve the desired functionality by diffing a previous state, my hunch is that targeting values based on their source component would provide a more intuitive interface.

As mentioned in #159, I already find the callback function signature a bit unwieldy to keep track of arguments, and the proposed change compounds this issue.

[mattare2]

I have a short-term workaround for this @ned2:

In this scheme, click events are all passed through their individual hidden div functions. The hidden div functions pass a timestamp which in turn is input to my primary callback. Click origins are finally determined by the most recent timestamp passed as input to the primary callback, while their content is passed as a state variable.

[alexcjohnson]

Before I just close this stale PR, let me ask @chriddyp and those who've commented on this thread: now that we have an n_clicks_timestamp property everywhere (and corresponding for other event properties) to tell you the most recent event, is there still a use case for knowing the previous state?

[chriddyp]

In some components, like datatable, its helpful to know the entire previous property to determine "which cells have changed". We introduced that in the component level with dataframe_previous. I can't think of any other components that have a similar need right now, but there could be in the future.

Re 'determining which property has changed': For usability in the future, I think that some type of first-class "which component has changed" would be a better solution than this previous state idea, perhaps as part of a dash.request. global object (mentioned briefly here: #475 (comment)). That would make it more consistent (we wouldn't be depending on component authors to adhere to the convention of the _timestamp property). Also note that not all event properties have the _timestamp property yet (e.g. all of the value properties in the dash-core-components).

[alexcjohnson]

Thanks @chriddyp - good to know about dataframe_previous. Closing this PR, if anyone has things to add to this discussion - ideally along with a specific use case we are not currently serving well - I would love to hear about it but please open an issue.

[chriddyp]

depends on plotly/dash-renderer#25

experimental usage

# -*- coding: utf-8 -*-importdashfromdash.dependenciesimportInput, Output, PrevInputimportdash_html_componentsashtmlimportdash_core_componentsasdccapp=dash.Dash()
app.scripts.config.serve_locally=Trueapp.layout=html.Div([
html.Button('Button 1', id='button-1', n_clicks=0),
html.Button('Button 2', id='button-2', n_clicks=0),
html.Pre(id='output')
])
@app.callback(Output('output', 'children'), [Input('button-1', 'n_clicks'), Input('button-2', 'n_clicks')],prev_inputs=[PrevInput('button-1', 'n_clicks'),PrevInput('button-2', 'n_clicks') ])defupdate_output(b1, b2, prev_b1, prev_b2):
s=''' Button 1 was clicked {} → {} times and Button 2 was clicked {} → {} times '''.format(prev_b1, b1, prev_b2, b2)
ifb1>prev_b1:
s+='\nWhich means that Button 1 was clicked'elifb2>prev_b2:
s+='\nWhich means that Button 2 was clicked'returnsif__name__=='__main__':
app.run_server(debug=True)

[akhmerov]

Isn't figuring out the source of the click a more common pattern than needing the previous state? The alternative to this PR would be to pass the event emitter and event type to the callback.

[mikesmith1611]

An alternative would be to allow an Output element to have multiple callbacks assigned to it. This way you can have a callback function for each input separately. Although I have no idea if this is even possible!

[chriddyp]

Isn't figuring out the source of the click a more common pattern than needing the previous state?

It may be, but providing the previous state allows you to do both.

An alternative would be to allow an Output element to have multiple callbacks assigned to it.

I'm afraid that this would cause too much ambiguity (for example, what should happen if the same input was in both outputs - would you call both callbacks or just one?) - I think that there was a discussion about this in the community forum somewhere.

[akhmerov]

It may be, but providing the previous state allows you to do both.

Is it guaranteed that all events are possible to get by diffing with the previous state?

[akhmerov]

Another question: is there anything that is not possible to do if the event information is provided to the callback, as opposed to the previous state?

[ned2]

My inclination is that I would also prefer the capacity to determine the origin of the Event/Input/State rather than diffing against a previous state.

Even if you can achieve the desired functionality by diffing a previous state, my hunch is that targeting values based on their source component would provide a more intuitive interface.

As mentioned in #159, I already find the callback function signature a bit unwieldy to keep track of arguments, and the proposed change compounds this issue.

[mattare2]

I have a short-term workaround for this @ned2:

In this scheme, click events are all passed through their individual hidden div functions. The hidden div functions pass a timestamp which in turn is input to my primary callback. Click origins are finally determined by the most recent timestamp passed as input to the primary callback, while their content is passed as a state variable.

[alexcjohnson]

Before I just close this stale PR, let me ask @chriddyp and those who've commented on this thread: now that we have an n_clicks_timestamp property everywhere (and corresponding for other event properties) to tell you the most recent event, is there still a use case for knowing the previous state?

[chriddyp]

In some components, like datatable, its helpful to know the entire previous property to determine "which cells have changed". We introduced that in the component level with dataframe_previous. I can't think of any other components that have a similar need right now, but there could be in the future.

Re 'determining which property has changed': For usability in the future, I think that some type of first-class "which component has changed" would be a better solution than this previous state idea, perhaps as part of a dash.request. global object (mentioned briefly here: #475 (comment)). That would make it more consistent (we wouldn't be depending on component authors to adhere to the convention of the _timestamp property). Also note that not all event properties have the _timestamp property yet (e.g. all of the value properties in the dash-core-components).

[alexcjohnson]

Thanks @chriddyp - good to know about dataframe_previous. Closing this PR, if anyone has things to add to this discussion - ideally along with a specific use case we are not currently serving well - I would love to hear about it but please open an issue.

[chriddyp]

depends on plotly/dash-renderer#25

experimental usage

# -*- coding: utf-8 -*-importdashfromdash.dependenciesimportInput, Output, PrevInputimportdash_html_componentsashtmlimportdash_core_componentsasdccapp=dash.Dash()
app.scripts.config.serve_locally=Trueapp.layout=html.Div([
html.Button('Button 1', id='button-1', n_clicks=0),
html.Button('Button 2', id='button-2', n_clicks=0),
html.Pre(id='output')
])
@app.callback(Output('output', 'children'), [Input('button-1', 'n_clicks'), Input('button-2', 'n_clicks')],prev_inputs=[PrevInput('button-1', 'n_clicks'),PrevInput('button-2', 'n_clicks') ])defupdate_output(b1, b2, prev_b1, prev_b2):
s=''' Button 1 was clicked {} → {} times and Button 2 was clicked {} → {} times '''.format(prev_b1, b1, prev_b2, b2)
ifb1>prev_b1:
s+='\nWhich means that Button 1 was clicked'elifb2>prev_b2:
s+='\nWhich means that Button 2 was clicked'returnsif__name__=='__main__':
app.run_server(debug=True)

[akhmerov]

Isn't figuring out the source of the click a more common pattern than needing the previous state? The alternative to this PR would be to pass the event emitter and event type to the callback.

[mikesmith1611]

An alternative would be to allow an Output element to have multiple callbacks assigned to it. This way you can have a callback function for each input separately. Although I have no idea if this is even possible!

[chriddyp]

Isn't figuring out the source of the click a more common pattern than needing the previous state?

It may be, but providing the previous state allows you to do both.

An alternative would be to allow an Output element to have multiple callbacks assigned to it.

I'm afraid that this would cause too much ambiguity (for example, what should happen if the same input was in both outputs - would you call both callbacks or just one?) - I think that there was a discussion about this in the community forum somewhere.

[akhmerov]

It may be, but providing the previous state allows you to do both.

Is it guaranteed that all events are possible to get by diffing with the previous state?

[akhmerov]

Another question: is there anything that is not possible to do if the event information is provided to the callback, as opposed to the previous state?

[ned2]

My inclination is that I would also prefer the capacity to determine the origin of the Event/Input/State rather than diffing against a previous state.

Even if you can achieve the desired functionality by diffing a previous state, my hunch is that targeting values based on their source component would provide a more intuitive interface.

As mentioned in #159, I already find the callback function signature a bit unwieldy to keep track of arguments, and the proposed change compounds this issue.

[mattare2]

I have a short-term workaround for this @ned2:

In this scheme, click events are all passed through their individual hidden div functions. The hidden div functions pass a timestamp which in turn is input to my primary callback. Click origins are finally determined by the most recent timestamp passed as input to the primary callback, while their content is passed as a state variable.

[alexcjohnson]

Before I just close this stale PR, let me ask @chriddyp and those who've commented on this thread: now that we have an n_clicks_timestamp property everywhere (and corresponding for other event properties) to tell you the most recent event, is there still a use case for knowing the previous state?

[chriddyp]

In some components, like datatable, its helpful to know the entire previous property to determine "which cells have changed". We introduced that in the component level with dataframe_previous. I can't think of any other components that have a similar need right now, but there could be in the future.

Re 'determining which property has changed': For usability in the future, I think that some type of first-class "which component has changed" would be a better solution than this previous state idea, perhaps as part of a dash.request. global object (mentioned briefly here: #475 (comment)). That would make it more consistent (we wouldn't be depending on component authors to adhere to the convention of the _timestamp property). Also note that not all event properties have the _timestamp property yet (e.g. all of the value properties in the dash-core-components).

[alexcjohnson]

Thanks @chriddyp - good to know about dataframe_previous. Closing this PR, if anyone has things to add to this discussion - ideally along with a specific use case we are not currently serving well - I would love to hear about it but please open an issue.

[chriddyp]

depends on plotly/dash-renderer#25

experimental usage

# -*- coding: utf-8 -*-importdashfromdash.dependenciesimportInput, Output, PrevInputimportdash_html_componentsashtmlimportdash_core_componentsasdccapp=dash.Dash()
app.scripts.config.serve_locally=Trueapp.layout=html.Div([
html.Button('Button 1', id='button-1', n_clicks=0),
html.Button('Button 2', id='button-2', n_clicks=0),
html.Pre(id='output')
])
@app.callback(Output('output', 'children'), [Input('button-1', 'n_clicks'), Input('button-2', 'n_clicks')],prev_inputs=[PrevInput('button-1', 'n_clicks'),PrevInput('button-2', 'n_clicks') ])defupdate_output(b1, b2, prev_b1, prev_b2):
s=''' Button 1 was clicked {} → {} times and Button 2 was clicked {} → {} times '''.format(prev_b1, b1, prev_b2, b2)
ifb1>prev_b1:
s+='\nWhich means that Button 1 was clicked'elifb2>prev_b2:
s+='\nWhich means that Button 2 was clicked'returnsif__name__=='__main__':
app.run_server(debug=True)

[akhmerov]

Isn't figuring out the source of the click a more common pattern than needing the previous state? The alternative to this PR would be to pass the event emitter and event type to the callback.

[mikesmith1611]

An alternative would be to allow an Output element to have multiple callbacks assigned to it. This way you can have a callback function for each input separately. Although I have no idea if this is even possible!

[chriddyp]

Isn't figuring out the source of the click a more common pattern than needing the previous state?

It may be, but providing the previous state allows you to do both.

An alternative would be to allow an Output element to have multiple callbacks assigned to it.

I'm afraid that this would cause too much ambiguity (for example, what should happen if the same input was in both outputs - would you call both callbacks or just one?) - I think that there was a discussion about this in the community forum somewhere.

[akhmerov]

It may be, but providing the previous state allows you to do both.

Is it guaranteed that all events are possible to get by diffing with the previous state?

[akhmerov]

Another question: is there anything that is not possible to do if the event information is provided to the callback, as opposed to the previous state?

[ned2]

My inclination is that I would also prefer the capacity to determine the origin of the Event/Input/State rather than diffing against a previous state.

Even if you can achieve the desired functionality by diffing a previous state, my hunch is that targeting values based on their source component would provide a more intuitive interface.

As mentioned in #159, I already find the callback function signature a bit unwieldy to keep track of arguments, and the proposed change compounds this issue.

[mattare2]

I have a short-term workaround for this @ned2:

In this scheme, click events are all passed through their individual hidden div functions. The hidden div functions pass a timestamp which in turn is input to my primary callback. Click origins are finally determined by the most recent timestamp passed as input to the primary callback, while their content is passed as a state variable.

[alexcjohnson]

Before I just close this stale PR, let me ask @chriddyp and those who've commented on this thread: now that we have an n_clicks_timestamp property everywhere (and corresponding for other event properties) to tell you the most recent event, is there still a use case for knowing the previous state?

[chriddyp]

In some components, like datatable, its helpful to know the entire previous property to determine "which cells have changed". We introduced that in the component level with dataframe_previous. I can't think of any other components that have a similar need right now, but there could be in the future.

Re 'determining which property has changed': For usability in the future, I think that some type of first-class "which component has changed" would be a better solution than this previous state idea, perhaps as part of a dash.request. global object (mentioned briefly here: #475 (comment)). That would make it more consistent (we wouldn't be depending on component authors to adhere to the convention of the _timestamp property). Also note that not all event properties have the _timestamp property yet (e.g. all of the value properties in the dash-core-components).

[alexcjohnson]

Thanks @chriddyp - good to know about dataframe_previous. Closing this PR, if anyone has things to add to this discussion - ideally along with a specific use case we are not currently serving well - I would love to hear about it but please open an issue.

[chriddyp]

depends on plotly/dash-renderer#25

experimental usage

# -*- coding: utf-8 -*-importdashfromdash.dependenciesimportInput, Output, PrevInputimportdash_html_componentsashtmlimportdash_core_componentsasdccapp=dash.Dash()
app.scripts.config.serve_locally=Trueapp.layout=html.Div([
html.Button('Button 1', id='button-1', n_clicks=0),
html.Button('Button 2', id='button-2', n_clicks=0),
html.Pre(id='output')
])
@app.callback(Output('output', 'children'), [Input('button-1', 'n_clicks'), Input('button-2', 'n_clicks')],prev_inputs=[PrevInput('button-1', 'n_clicks'),PrevInput('button-2', 'n_clicks') ])defupdate_output(b1, b2, prev_b1, prev_b2):
s=''' Button 1 was clicked {} → {} times and Button 2 was clicked {} → {} times '''.format(prev_b1, b1, prev_b2, b2)
ifb1>prev_b1:
s+='\nWhich means that Button 1 was clicked'elifb2>prev_b2:
s+='\nWhich means that Button 2 was clicked'returnsif__name__=='__main__':
app.run_server(debug=True)

[akhmerov]

Isn't figuring out the source of the click a more common pattern than needing the previous state? The alternative to this PR would be to pass the event emitter and event type to the callback.

[mikesmith1611]

An alternative would be to allow an Output element to have multiple callbacks assigned to it. This way you can have a callback function for each input separately. Although I have no idea if this is even possible!

[chriddyp]

Isn't figuring out the source of the click a more common pattern than needing the previous state?

It may be, but providing the previous state allows you to do both.

An alternative would be to allow an Output element to have multiple callbacks assigned to it.

I'm afraid that this would cause too much ambiguity (for example, what should happen if the same input was in both outputs - would you call both callbacks or just one?) - I think that there was a discussion about this in the community forum somewhere.

[akhmerov]

It may be, but providing the previous state allows you to do both.

Is it guaranteed that all events are possible to get by diffing with the previous state?

[akhmerov]

Another question: is there anything that is not possible to do if the event information is provided to the callback, as opposed to the previous state?

[ned2]

My inclination is that I would also prefer the capacity to determine the origin of the Event/Input/State rather than diffing against a previous state.

Even if you can achieve the desired functionality by diffing a previous state, my hunch is that targeting values based on their source component would provide a more intuitive interface.

As mentioned in #159, I already find the callback function signature a bit unwieldy to keep track of arguments, and the proposed change compounds this issue.

[mattare2]

I have a short-term workaround for this @ned2:

In this scheme, click events are all passed through their individual hidden div functions. The hidden div functions pass a timestamp which in turn is input to my primary callback. Click origins are finally determined by the most recent timestamp passed as input to the primary callback, while their content is passed as a state variable.

[alexcjohnson]

Before I just close this stale PR, let me ask @chriddyp and those who've commented on this thread: now that we have an n_clicks_timestamp property everywhere (and corresponding for other event properties) to tell you the most recent event, is there still a use case for knowing the previous state?

[chriddyp]

In some components, like datatable, its helpful to know the entire previous property to determine "which cells have changed". We introduced that in the component level with dataframe_previous. I can't think of any other components that have a similar need right now, but there could be in the future.

Re 'determining which property has changed': For usability in the future, I think that some type of first-class "which component has changed" would be a better solution than this previous state idea, perhaps as part of a dash.request. global object (mentioned briefly here: #475 (comment)). That would make it more consistent (we wouldn't be depending on component authors to adhere to the convention of the _timestamp property). Also note that not all event properties have the _timestamp property yet (e.g. all of the value properties in the dash-core-components).

[alexcjohnson]

Thanks @chriddyp - good to know about dataframe_previous. Closing this PR, if anyone has things to add to this discussion - ideally along with a specific use case we are not currently serving well - I would love to hear about it but please open an issue.

[chriddyp]

depends on plotly/dash-renderer#25

experimental usage

# -*- coding: utf-8 -*-importdashfromdash.dependenciesimportInput, Output, PrevInputimportdash_html_componentsashtmlimportdash_core_componentsasdccapp=dash.Dash()
app.scripts.config.serve_locally=Trueapp.layout=html.Div([
html.Button('Button 1', id='button-1', n_clicks=0),
html.Button('Button 2', id='button-2', n_clicks=0),
html.Pre(id='output')
])
@app.callback(Output('output', 'children'), [Input('button-1', 'n_clicks'), Input('button-2', 'n_clicks')],prev_inputs=[PrevInput('button-1', 'n_clicks'),PrevInput('button-2', 'n_clicks') ])defupdate_output(b1, b2, prev_b1, prev_b2):
s=''' Button 1 was clicked {} → {} times and Button 2 was clicked {} → {} times '''.format(prev_b1, b1, prev_b2, b2)
ifb1>prev_b1:
s+='\nWhich means that Button 1 was clicked'elifb2>prev_b2:
s+='\nWhich means that Button 2 was clicked'returnsif__name__=='__main__':
app.run_server(debug=True)

[akhmerov]

Isn't figuring out the source of the click a more common pattern than needing the previous state? The alternative to this PR would be to pass the event emitter and event type to the callback.

[mikesmith1611]

An alternative would be to allow an Output element to have multiple callbacks assigned to it. This way you can have a callback function for each input separately. Although I have no idea if this is even possible!

[chriddyp]

Isn't figuring out the source of the click a more common pattern than needing the previous state?

It may be, but providing the previous state allows you to do both.

An alternative would be to allow an Output element to have multiple callbacks assigned to it.

I'm afraid that this would cause too much ambiguity (for example, what should happen if the same input was in both outputs - would you call both callbacks or just one?) - I think that there was a discussion about this in the community forum somewhere.

[akhmerov]

It may be, but providing the previous state allows you to do both.

Is it guaranteed that all events are possible to get by diffing with the previous state?

[akhmerov]

Another question: is there anything that is not possible to do if the event information is provided to the callback, as opposed to the previous state?

[ned2]

My inclination is that I would also prefer the capacity to determine the origin of the Event/Input/State rather than diffing against a previous state.

Even if you can achieve the desired functionality by diffing a previous state, my hunch is that targeting values based on their source component would provide a more intuitive interface.

As mentioned in #159, I already find the callback function signature a bit unwieldy to keep track of arguments, and the proposed change compounds this issue.

[mattare2]

I have a short-term workaround for this @ned2:

In this scheme, click events are all passed through their individual hidden div functions. The hidden div functions pass a timestamp which in turn is input to my primary callback. Click origins are finally determined by the most recent timestamp passed as input to the primary callback, while their content is passed as a state variable.

[alexcjohnson]

Before I just close this stale PR, let me ask @chriddyp and those who've commented on this thread: now that we have an n_clicks_timestamp property everywhere (and corresponding for other event properties) to tell you the most recent event, is there still a use case for knowing the previous state?

[chriddyp]

In some components, like datatable, its helpful to know the entire previous property to determine "which cells have changed". We introduced that in the component level with dataframe_previous. I can't think of any other components that have a similar need right now, but there could be in the future.

Re 'determining which property has changed': For usability in the future, I think that some type of first-class "which component has changed" would be a better solution than this previous state idea, perhaps as part of a dash.request. global object (mentioned briefly here: #475 (comment)). That would make it more consistent (we wouldn't be depending on component authors to adhere to the convention of the _timestamp property). Also note that not all event properties have the _timestamp property yet (e.g. all of the value properties in the dash-core-components).

[alexcjohnson]

Thanks @chriddyp - good to know about dataframe_previous. Closing this PR, if anyone has things to add to this discussion - ideally along with a specific use case we are not currently serving well - I would love to hear about it but please open an issue.

[chriddyp]

depends on plotly/dash-renderer#25

experimental usage

# -*- coding: utf-8 -*-importdashfromdash.dependenciesimportInput, Output, PrevInputimportdash_html_componentsashtmlimportdash_core_componentsasdccapp=dash.Dash()
app.scripts.config.serve_locally=Trueapp.layout=html.Div([
html.Button('Button 1', id='button-1', n_clicks=0),
html.Button('Button 2', id='button-2', n_clicks=0),
html.Pre(id='output')
])
@app.callback(Output('output', 'children'), [Input('button-1', 'n_clicks'), Input('button-2', 'n_clicks')],prev_inputs=[PrevInput('button-1', 'n_clicks'),PrevInput('button-2', 'n_clicks') ])defupdate_output(b1, b2, prev_b1, prev_b2):
s=''' Button 1 was clicked {} → {} times and Button 2 was clicked {} → {} times '''.format(prev_b1, b1, prev_b2, b2)
ifb1>prev_b1:
s+='\nWhich means that Button 1 was clicked'elifb2>prev_b2:
s+='\nWhich means that Button 2 was clicked'returnsif__name__=='__main__':
app.run_server(debug=True)

[akhmerov]

Isn't figuring out the source of the click a more common pattern than needing the previous state? The alternative to this PR would be to pass the event emitter and event type to the callback.

[mikesmith1611]

An alternative would be to allow an Output element to have multiple callbacks assigned to it. This way you can have a callback function for each input separately. Although I have no idea if this is even possible!

[chriddyp]

Isn't figuring out the source of the click a more common pattern than needing the previous state?

It may be, but providing the previous state allows you to do both.

An alternative would be to allow an Output element to have multiple callbacks assigned to it.

I'm afraid that this would cause too much ambiguity (for example, what should happen if the same input was in both outputs - would you call both callbacks or just one?) - I think that there was a discussion about this in the community forum somewhere.

[akhmerov]

It may be, but providing the previous state allows you to do both.

Is it guaranteed that all events are possible to get by diffing with the previous state?

[akhmerov]

Another question: is there anything that is not possible to do if the event information is provided to the callback, as opposed to the previous state?

[ned2]

My inclination is that I would also prefer the capacity to determine the origin of the Event/Input/State rather than diffing against a previous state.

Even if you can achieve the desired functionality by diffing a previous state, my hunch is that targeting values based on their source component would provide a more intuitive interface.

As mentioned in #159, I already find the callback function signature a bit unwieldy to keep track of arguments, and the proposed change compounds this issue.

[mattare2]

I have a short-term workaround for this @ned2:

In this scheme, click events are all passed through their individual hidden div functions. The hidden div functions pass a timestamp which in turn is input to my primary callback. Click origins are finally determined by the most recent timestamp passed as input to the primary callback, while their content is passed as a state variable.

[alexcjohnson]

Before I just close this stale PR, let me ask @chriddyp and those who've commented on this thread: now that we have an n_clicks_timestamp property everywhere (and corresponding for other event properties) to tell you the most recent event, is there still a use case for knowing the previous state?

[chriddyp]

In some components, like datatable, its helpful to know the entire previous property to determine "which cells have changed". We introduced that in the component level with dataframe_previous. I can't think of any other components that have a similar need right now, but there could be in the future.

Re 'determining which property has changed': For usability in the future, I think that some type of first-class "which component has changed" would be a better solution than this previous state idea, perhaps as part of a dash.request. global object (mentioned briefly here: #475 (comment)). That would make it more consistent (we wouldn't be depending on component authors to adhere to the convention of the _timestamp property). Also note that not all event properties have the _timestamp property yet (e.g. all of the value properties in the dash-core-components).

[alexcjohnson]

Thanks @chriddyp - good to know about dataframe_previous. Closing this PR, if anyone has things to add to this discussion - ideally along with a specific use case we are not currently serving well - I would love to hear about it but please open an issue.

[chriddyp]

depends on plotly/dash-renderer#25

experimental usage

# -*- coding: utf-8 -*-importdashfromdash.dependenciesimportInput, Output, PrevInputimportdash_html_componentsashtmlimportdash_core_componentsasdccapp=dash.Dash()
app.scripts.config.serve_locally=Trueapp.layout=html.Div([
html.Button('Button 1', id='button-1', n_clicks=0),
html.Button('Button 2', id='button-2', n_clicks=0),
html.Pre(id='output')
])
@app.callback(Output('output', 'children'), [Input('button-1', 'n_clicks'), Input('button-2', 'n_clicks')],prev_inputs=[PrevInput('button-1', 'n_clicks'),PrevInput('button-2', 'n_clicks') ])defupdate_output(b1, b2, prev_b1, prev_b2):
s=''' Button 1 was clicked {} → {} times and Button 2 was clicked {} → {} times '''.format(prev_b1, b1, prev_b2, b2)
ifb1>prev_b1:
s+='\nWhich means that Button 1 was clicked'elifb2>prev_b2:
s+='\nWhich means that Button 2 was clicked'returnsif__name__=='__main__':
app.run_server(debug=True)

[akhmerov]

Isn't figuring out the source of the click a more common pattern than needing the previous state? The alternative to this PR would be to pass the event emitter and event type to the callback.

[mikesmith1611]

An alternative would be to allow an Output element to have multiple callbacks assigned to it. This way you can have a callback function for each input separately. Although I have no idea if this is even possible!

[chriddyp]

Isn't figuring out the source of the click a more common pattern than needing the previous state?

It may be, but providing the previous state allows you to do both.

An alternative would be to allow an Output element to have multiple callbacks assigned to it.

I'm afraid that this would cause too much ambiguity (for example, what should happen if the same input was in both outputs - would you call both callbacks or just one?) - I think that there was a discussion about this in the community forum somewhere.

[akhmerov]

It may be, but providing the previous state allows you to do both.

Is it guaranteed that all events are possible to get by diffing with the previous state?

[akhmerov]

Another question: is there anything that is not possible to do if the event information is provided to the callback, as opposed to the previous state?

[ned2]

My inclination is that I would also prefer the capacity to determine the origin of the Event/Input/State rather than diffing against a previous state.

Even if you can achieve the desired functionality by diffing a previous state, my hunch is that targeting values based on their source component would provide a more intuitive interface.

As mentioned in #159, I already find the callback function signature a bit unwieldy to keep track of arguments, and the proposed change compounds this issue.

[mattare2]

I have a short-term workaround for this @ned2:

In this scheme, click events are all passed through their individual hidden div functions. The hidden div functions pass a timestamp which in turn is input to my primary callback. Click origins are finally determined by the most recent timestamp passed as input to the primary callback, while their content is passed as a state variable.

[alexcjohnson]

Before I just close this stale PR, let me ask @chriddyp and those who've commented on this thread: now that we have an n_clicks_timestamp property everywhere (and corresponding for other event properties) to tell you the most recent event, is there still a use case for knowing the previous state?

[chriddyp]

In some components, like datatable, its helpful to know the entire previous property to determine "which cells have changed". We introduced that in the component level with dataframe_previous. I can't think of any other components that have a similar need right now, but there could be in the future.

Re 'determining which property has changed': For usability in the future, I think that some type of first-class "which component has changed" would be a better solution than this previous state idea, perhaps as part of a dash.request. global object (mentioned briefly here: #475 (comment)). That would make it more consistent (we wouldn't be depending on component authors to adhere to the convention of the _timestamp property). Also note that not all event properties have the _timestamp property yet (e.g. all of the value properties in the dash-core-components).

[alexcjohnson]

Thanks @chriddyp - good to know about dataframe_previous. Closing this PR, if anyone has things to add to this discussion - ideally along with a specific use case we are not currently serving well - I would love to hear about it but please open an issue.