remove _timestamp properties

[gvwilson]

The _timestamp properties have been essentially useless since callback_context was introduced - they should be removed. cc @alexcjohnson @AnnMarieW

[AnnMarieW]

I agree - but do you think it's still important for other languages? Not sure if that's important if they are no longer being supported.

Here is an R example

Also is it necessary in the DataTable?

[alexcjohnson]

IMO since this is a major version bump of Dash, if other languages want to upgrade their dependencies on the main components it’s reasonable to ask them to support the callback_context pattern as well.

[alexcjohnson]

Yes, I think we can remove this from DataTable, also html:

dash/components/dash-html-components/scripts/generate-components.js

Line 140 in 0d9cd2c

'n_clicks_timestamp': PropTypes.number,

I have a vague recollection of there being a reason to keep it for Store, but if we don’t have an example of this then probably that too is no longer applicable.

dash/components/dash-core-components/src/components/Store.react.js

Line 219 in 0d9cd2c

modified_timestamp: PropTypes.number,

[gvwilson]

Thanks @alexcjohnson and @AnnMarieW - @T4rk1n, please pull it out. (I love deleting code in the morning...)

[T4rk1n]

I have a vague recollection of there being a reason to keep it for Store

I think that is what we have that can trigger a callback without an input on the data itself. Like you may want to update some last saved element but don't need the data to be transfered.

[gvwilson]

@T4rk1n @alexcjohnson @AnnMarieW please thumbs-up if you believe we can remove _timestamp properties in the upcoming release.

[AnnMarieW]

Yes - all except Store per comments above

[alexcjohnson]

Does that same argument apply to DataTable data_timestamp? Otherwise the props are all small so no reason not to fully transfer them, seems like this is just a performance hack for very large props

[alexcjohnson]

TBH though I’m not sure that’s a good enough reason to keep these props around. It’s a very niche case (how often do you really care that something changed but not care what the new value is?), and the same could be accomplished with a small clientside callback bound to the full prop outputting to another prop (an extra store just for this purpose, for example) then you use that as the input to your serverside callback that doesn’t need the full data transferred.