-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Picking input prop(s) #6
Comments
There is no list packing, only tuples. So I don't think there's any incompatibility.
Yeah, this is a compelling argument for another approach. With the current approach, I like the symmetry of the packing structure between the property specification and the function input value. So I think I'd prefer encoding the "stateness" in the string somehow.
I used But I don't feel that strongly about parens vs brackets. I like brackets a little more since I think it looks better when using tuple packing (no consecutive parens). |
But right now in
If we allow It would generate a tuple when supplied multiple unnamed params: And it would generate a dict when supplied even a single named param: I suppose mixing named and unnamed args would be an error. |
Oh, I see. I thought you were thinking that something about the
doh. I guess that would be a 2.0 backward incompatibility. Really too bad we didn't come up with this design before Return values of tuples are still different from lists right? e.g. you can't return a tuple to satisfy multiple outputs can you? |
I believe you can return either a tuple or list - for the most part we have not made a distinction between these. Isn't that what you get when you do |
Ok, There's more incompatibility here than I thought then. |
I do have one issue with this props function syntax
I'm assuming that the scalar string case would produce a scalar prop value:
But then there's no way to represent length-1 tuples. Granted, directly specifying length-1 tuples is an unusual thing to do, but when writing generic code that generates these inputs/outputs from plugins, I think it would be more common. So I think I still prefer the getitem syntax where
|
no longer applicable to current design |
For changing the prop of an input from the default
value
, right now we have eg:The great thing about this syntax vs
dcc.DatePickerSingle().date
is you can easily pick multiple values and pack them into either a list or a dict for your function - and we should allow you to do either of those with the regular id/prop callback definitions too (though list packing would probably have to be a breaking change due to how we unlisted outputs, inputs, and state in dash 1.x)I don't get why it's formatted to look like a dict though - to me it's more like a method modifying the component's "value" to be some prop(s) other than
value
.Also: what if you want one prop as input and another as state? For example a
dcc.Store
withdata
as state,modified_timestamp
as input? And per #5, what if you wantmodified_timestamp
to be aTrigger
, or hidden? We could imagine making tuples:dcc.Store().props(("modified_timestamp", "state"), "data")
or take advantage of the fact that props can't have dots in them:
dcc.Store().props("modified_timestamp.hidden", "data")
The text was updated successfully, but these errors were encountered: