Skip to content
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

feat: add support for Cmd wrapping (for routing) #936

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

JaredReisinger
Copy link

This is one possible solution for allowing components to wrap any tea.Cmd that comes from a sub-component's Update(). See the comment in the code for other possible options.

Fixes #751


I'm creating this as a draft PR because this seemed like the easiest way to share one possible solution to the "how can a component reliably route a message to the correct subcomponent?" question. There are pros/cons to any of the solutions; this just provides a starting point for the discussion.

This is one possible solution for allowing components to wrap any
`tea.Cmd` that comes from a sub-component's `Update()`.  See the comment
in the code for other possible options.
@DavidS-ovm
Copy link

Would this also be helpful to reduce the custom ID handling in https://github.com/charmbracelet/bubbles/blob/master/spinner/spinner.go ?

@JaredReisinger
Copy link
Author

Well... not necessarily. Here's the problem: the way the spinner currently works, it requires all parent components to pass at least the spinner.TickMsg messages down to their child spinner(s). The solution in the PR is aimed at the parent component/model, not the child. So... it could help the parent to correctly delegate the spinner.TickMsg to the child spinner without the parent having to know it was a spinner.TickMsg. This is a huge value to me as the author of a parent component, because it insulates me from internal changes of the child. The child component adds an all-new message? It's not even an exported type? I don't care, I can blindly wrap the outcoming command and then get an incoming message that's flagged for a specific child.

Back to the spinner... If (and only if) this is the only way that a child spinner gets its message, then yes, the internal ID checking in spinner could probably go away. But if I were the one maintaining spinner, I'd probably leave the ID handling in-place, because I wouldn't trust parent components to always do the "right thing" (e.g. use the solution in this PR), and I'd also want to keep some backward compatibility.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants