You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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.
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
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.
Activity
AnnMarieW commentedon Oct 29, 2024
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 commentedon Oct 30, 2024
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_contextpattern as well.alexcjohnson commentedon Oct 30, 2024
Yes, I think we can remove this from
DataTable, also html:dash/components/dash-html-components/scripts/generate-components.js
Line 140 in 0d9cd2c
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
gvwilson commentedon Oct 30, 2024
Thanks @alexcjohnson and @AnnMarieW - @T4rk1n, please pull it out. (I love deleting code in the morning...)
T4rk1n commentedon Oct 31, 2024
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 commentedon Nov 1, 2024
@T4rk1n @alexcjohnson @AnnMarieW please thumbs-up if you believe we can remove
_timestampproperties in the upcoming release.AnnMarieW commentedon Nov 1, 2024
Yes - all except
Storeper comments abovealexcjohnson commentedon Nov 1, 2024
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 commentedon Nov 1, 2024
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.
AnnMarieW commentedon Nov 18, 2025
closed as not planned per comment #3148 (comment)