Ryan Waldheim

I just pushed the minimal possible change in my mind: renaming `NoUpdate` to `NoUpdateType` and exposing it. This does not implement the behavior @ndrezn mentions as it will still be...

In an attempt to keep the implementation of this PR at a minimum and, if I'm interpreting the conversation correctly up until now, is there any objection to the current...

> > any lingering comments from you? > > I'd rather we fix the cases where using `NoUpdate` would be creating an error instead of renaming the variable in hope...

Unfortunately I don't believe there are any accepted conventions for this other than the [they styled as CapWords](https://peps.python.org/pep-0008/#type-variable-names). `NoUpdateType` seems like a perfectly reasonable solution to me. Will update the...

On a higher note, should `NoUpdate` be a [`TypedDict`](https://typing.readthedocs.io/en/latest/spec/typeddict.html#typeddict)?

> > On a higher note, should `NoUpdate` be a [`TypedDict`](https://typing.readthedocs.io/en/latest/spec/typeddict.html#typeddict)? > > Because of its JSON serialization? @T4rk1n correct me if I'm wrong but I think that's just for...

I can confirm this issue is still present in Dash 3.0.4.

Are there any plans to address community issues/pull requests in this repo?

This appears to be a deliberate decision made by the dash team. [Link](https://github.com/plotly/dash/blob/9140d3a5f97c190127fc097ecc09d0651bb72215/components/dash-table/src/dash-table/derived/header/content.tsx#L244). Manually removing that flag, it results in an invalid prop combination as specified by [validFSP](https://github.com/plotly/dash/blob/a1049defacd6e490837013d1f75949e94dfce33a/components/dash-table/src/dash-table/dash/validate.ts#L31) As to...