Skip to content

remove _timestamp properties #3055

Closed
Closed

Description

@gvwilson

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

Activity

  1. AnnMarieW commented on Oct 29, 2024

    @AnnMarieW
    Collaborator

    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?

  2. alexcjohnson commented on Oct 30, 2024

    @alexcjohnson
    Collaborator

    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.

  3. alexcjohnson commented on Oct 30, 2024

    @alexcjohnson
    Collaborator

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

    '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.

    modified_timestamp: PropTypes.number,

  4. gvwilson commented on Oct 30, 2024

    @gvwilson
    ContributorAuthor

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

  5. T4rk1n commented on Oct 31, 2024

    @T4rk1n
    Contributor

    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.

  6. gvwilson commented on Nov 1, 2024

    @gvwilson
    ContributorAuthor

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

  7. AnnMarieW commented on Nov 1, 2024

    @AnnMarieW
    Collaborator

    Yes - all except Store per comments above

  8. alexcjohnson commented on Nov 1, 2024

    @alexcjohnson
    Collaborator

    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

  9. alexcjohnson commented on Nov 1, 2024

    @alexcjohnson
    Collaborator

    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.

  10. removed
    P1needed for current cycle
    on Nov 18, 2025
  11. AnnMarieW commented on Nov 18, 2025

    @AnnMarieW
    Collaborator

    closed as not planned per comment #3148 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions