plotly / dash-core-components

OBSOLETE: now part of https://github.com/plotly/dash
https://dash.plotly.com
MIT License
270 stars 147 forks source link

Remove _timestamp properties, or fix & standardize? #467

Open romainmartinez opened 5 years ago

romainmartinez commented 5 years ago

Hello,

A minor problem appeared when using an Input component. The n_submit_timestamp property returns a string (e.g. '2019-02-23T16:39:12.076Z') while other components such as Button returns an int (e.g. 1550939942322).

I often use the following command to find out which button was last pressed and I can't use it with Input:

np.nanargmax(np.array([btn_1_n_clicks_timestamp, btn_2_n_n_clicks_timestamp, btn_3_n_n_clicks_timestamp], dtype=np.float)

Maybe you should standardize the two outputs.

alexcjohnson commented 5 years ago

We have a better solution to this - which has already been merged and will be in the next release: callback context, that directly tells you which input(s) triggered the call plotly/dash#608

Having mismatched behavior for these is definitely a problem, but the solution - if callback context takes care of every case people were using *_timestamp for - may be to simply deprecate, and eventually remove, all the *_timestamp props.

alexcjohnson commented 5 years ago

Dash 0.38 is released including dash.callback_context. I'll leave this issue open as a proxy for deciding whether to remove these props completely or fix them, once we get a bit more feedback on callback_context.

alexcjohnson commented 5 years ago

The current proposal is to deprecate - and eventually remove - all _timestamp properties except for modified_timestamp in the Store component, which has the additional functionality of testing deep equality so we can avoid a repeat callback if the same data is stored twice.

romainmartinez commented 5 years ago

Sounds great. In my use of dash, I only use _timestamp to know which is the last element used among an input list so I'm OK with to deprecate.