Skip to content

Conversation

@ianhi
Copy link
Contributor

@ianhi ianhi commented Jan 27, 2026

PR summary

Addresses the core issue underlying: #24039

Prior to this you could only have one callback associated with the onselect of any of the selectors which is limiting. This PR expands that to use a CallbackRegistry internally (like the other widgets) whcih allows handling multiple onselect callbacks.

I used the name on_select instead of on_changed to differentiate from the value selection widgets vs these selectors. I also tried to keep back compat with the possible use case of directly assigning to onselect.

For consistency with other widgets the selectors now also check for self.eventson before firing the callbacks

🤖 Idea and direction by me. I used claude to do the typing. Iterated through several implement review cycles locally before posting

PR checklist

New code should use `on_select` to register callbacks.
This property may be deprecated in a future release.
"""
return self._onselect
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rather than keeping the state 2x, we should pull this out of the _observers and raise if there is more than one.

Similarly for the setter, we should fail if there is more than one. That will keep us from having to add any new state.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm worried that disallowing setting onselect when there are multiple registered leaves no way for the user to de-register that initial callback, becasue it's callbackid is hidden from inside init.

👍 on not saving it separately though

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

currently no one has more than one registered callback so no existing code should break, but if someone writes new code that mixes the two then we drive our self to a maybe inconsistent state. By erroring if the behavior is ambiguous in a mixed usage we can avoid that without leaving latent bugs for new usage (because it should error while they are writing it) and without breaking existing users / forcing a migration.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

currently you can deregister by setting None (I think), that would be straight forward to keep the behavior of.

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

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants