Open 2Ryan09 opened 7 months ago
Thanks @2Ryan09 - makes sense, but I’m worried about confusion between the no_update
value and the NoUpdate
class (of which normally no_update
is the lone instance). Is there a relevant convention we can use to make this distinction clear? Rename the class NoUpdateType
or something, ala None
/ NoneType
?
Unfortunately I don't believe there are any accepted conventions for this other than the they styled as CapWords.
NoUpdateType
seems like a perfectly reasonable solution to me. Will update the PR.
On a higher note, should
NoUpdate
be aTypedDict
?
Because of its JSON serialization? @T4rk1n correct me if I'm wrong but I think that's just for internal use with background callbacks, shouldn't be visible to users.
On a higher note, should
NoUpdate
be aTypedDict
?Because of its JSON serialization? @T4rk1n correct me if I'm wrong but I think that's just for internal use with background callbacks, shouldn't be visible to users.
Because, from what I can gather, NoUpdate
can be entirely represented by {"_dash_no_update": "_dash_no_update"}
and two methods within either compare it to that dictionary or just check it is of that type.
Is there a relevant convention we can use to make this distinction clear? Rename the class NoUpdateType or something, ala None / NoneType?
NoneType
is a special case, it isn't actually defined it's just the return type of type(None)
. The correct typing for None
is -> None
not NoneType
.
Because, from what I can gather, NoUpdate can be entirely represented by
{"_dash_no_update": "_dash_no_update"}
and two methods within either compare it to that dictionary or just check it is of that type.
Yes, I guess we could add the check in to __eq__
of NoUpdate
to get ==
operator to work with the dict syntax.
NoUpdate on the user side is mostly just a singleton and the api we have is return dash.no_update
or the old raise PreventUpdate
. I can see some error coming from return NoUpdate
instead of return NoUpdate()
because isinstance(NoUpdate, (NoUpdate,))
is false so maybe add an additional check for that case in the staticmethod.
Enable more comprehensive type hinting of dash callback methods by exposing
dash._callback.NoUpdate
.Given
callback()
andclientside_callback()
are already imported up, is there any reason not to also exposeNoUpdate
?A Minimal Dash App with comprehensive python typing: