Multi-model message routing

[relvacode]

I have an applicaton that displays multiple models at once. What I want to do is deliver the message to the same model that sent the message.

One suggestion mentioned here #649 is that you just propagate the message to all models, and the model should be in charge of handling messages it owns.

However this isn't a pattern used everywhere. For example the list in bubbles responds to all messages for lists https://github.com/charmbracelet/bubbles/blob/master/list/list.go#L757

What I'd like to be able to do is intercept model commands and annotate their messages with the return route. That way, when messages come back I could route them to the right destination.

Or, ideally it would be possible to implement some event loop interceptor at each routing layer to isolate independent parts of the program; run commands, deliver their messages to the target model and propagate an update for re-draw back to the main tea program.

Main Program ---> Router [Event Loop] 1---> Model
  | --------------- |        | <-----------1 |
                                      2---> Model
                             | <-----------2 |

Having bubbletea provide abstractions to do this would be nice, but its something I could write myself by re-implementing the behaviour of the program event loop.

However I can't implement either approach because sequenceMsg is private:

bubbletea/commands.go

Line 44 in c267762

type sequenceMsg []Cmd

So it's impossible to unroll and intercept inner messages, unlike BatchMsg which is public.

[meowgorithm]

So technically speaking the "canonical" solve for this would be to add some logic in your top level update to route messages to the correct children, and altering them if necessary along the way as data in The Elm Architecture naturally flows down.

We should probably make sequenceMsg public à la BatchMsg, though, as well as implement the (very simple) pattern in which models only respond to their own messages for the rest of the Bubbles library.

[JaredReisinger]

I opened a draft PR (#936) with one possible solution. It's pretty minimal; just enough to allow me to ensure I can route a message to the subcomponent that returned any given tea.Cmd.

Yes, if sequenceMsg were public, then this Wrap() helper (and WrappedMsg) could be implemented by anyone who needed to. But it made sense to me that bubbletea could be a bit opinionated about "the right way" to solve the problem, and avoid having dozens of duplicate implementations floating around.

Please note that my particular solution—a single int value grafted around the actual message—is very minimal. It could as easily be an interface{}, or Wrap() could itself take a function to wrap the final message (Wrap(cmd Cmd, wrapper func(msg Msg) Msg) Cmd), to give the caller the maximum amount of flexibility. I decided on simple ints , though, because the Elm Architecture pattern suggests simple values for messages. I didn't even want to allow the possibility for someone to attempt wrapping with "a pointer to the subcomponent model"... that pointer might not refer to the actual subcomponent model by the time the message is delivered! By using an int, it forces the caller to figure out a clean mapping between the wrapping ID value and the final message recipient.