-
Notifications
You must be signed in to change notification settings - Fork 56
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
PlutoUI's Select type has the order of the pairs wrong #159
Comments
Thanks for pointing this out, I keep getting confused about this myself! It looks like I allowed |
Great! Thank you so much - the feauture is really helpful ^_^ Do you have any thought on my feeling that it would be more logical to have the first item in the pair be the displayed one, and the second to bind to the variable? It is so massivly breaking that it is probably not worth it, but I am curius about your thoughts. |
Right! Like you say, it's too breaking to change now, but I also get confused sometimes. I think both make sense |
Yhea, there is not a clear answer, and I can see that both make some sense. I guess the best solution then is to make the order really clear in the documentation ^_^ |
Copy of this discourse post:
The
Select
type allows the user to create down-down menus with the@bind
macro. Awesome feature.The current behaviour is
The docs for
Select
look like this:So in the language of the docs,
"1"
is the key, and"one"
is the value. key=>value is consistent withDict
, and feels right. But it feels to me as the entry visible in the drop-down is the key, used to index to the right value. The key has a name that makes sense, but the value is what you are really interested in. But currently, the opposite is the case.Additionally,
keys
are of type string, butvalues
are of type any. I want variables to have any type, but drop-down entries to have typeString
. The other way around, which is currently the case, makes no sense:Could I be right in saying that the first value, the key of type
String
, should be shown in the drop-down? And that the second value, the value of typeAny
, should be bound to the variable? It makes more sense, and is a lot more powerful.The text was updated successfully, but these errors were encountered: