The "eventBus" naming is a bit confusing. Its call...

# ballast

[rocketraman]

The "eventBus" naming is a bit confusing. Its called an event bus, and it seems that events are sent to it via post*Event*, but the way you listen to it is via an observe*Inputs*FromBus. Can the naming be clarified?

[Casey Brooks]

I’d be open to a rename, what would you propose?

[rocketraman]

I'm not sure. This is my understanding:

1) an EventBus can carry Any data -- but it has to be something that another VM/repository will read via handleInput or handleEvent, so effectively it has to be either an Input or an Event.

2) postEvent is doing double-duty -- it posts `Event`s for the VM but it also writes to the event bus.

Is all that right?

[Casey Brooks]

My intention when setting it up is to generically provide a means of cross-Repository communication, and to not really impose much around what exactly that could be. And it’s a loose coupling, where the InputHandler for any given Repository didn’t need to actually have the EventBus injected into it to be able to send values into it, and using postEvent to write to the bus seemed like the easy way to do that. But now that I think about it, it’s being injected in anyway to read from the bus, so that doesn’t really make sense. The EventBus is already there, so it would probably make more sense to just write directly to it.

As far as the values that could be posted to the EventBus, it’s intentionally generic. A use-case I had in mind for it was some ClearCache object that each Repository could listen for and clear itself, rather than having to post the specific Input for each Repository

[rocketraman]

Agreed on writing directly to event bus -- that will be much clearer.

I saw the ClearCache example in the docs but it confused me. My repository can handle events or inputs, so how would it see the generic ClearCache object?

[Casey Brooks]

It would listen for the generic token, and then respond by sending its own specific Input in response. The EventBus is basically just a SharedFlow, and you can collect from it without using observeInputsFromBus. So you would do something like this:

object ClearCache

// in Repository1
observeFlows(
    key = "Observe ClearCache",
    params.eventBus
        .filterIsInstance<ClearCache>()
        .map { Repository1Contract.Inputs.ClearAllCaches },
)

// in Repository2
observeFlows(
    key = "Observe ClearCache",
    params.eventBus
        .filterIsInstance<ClearCache>()
        .map { Repository2Contract.Inputs.ClearAllCaches },
)

// elsewhere in your application
eventBus.emit(ClearCache) // only send 1 value, but multiple Repositories will react to it and clear themselves

[rocketraman]

That makes sense. Showing this example in the docs would be very helpful.

So for naming, I might consider:

EventBus - I'm of two minds here: first "event bus" has a well-known specific and valid meaning, but second that "event" here conflates with the use of "event" elsewhere
postEvent - do not post to the event bus, as discussed
observeInputsFromBus - rename to observeBus or observeEventBus (or whatever EventBus becomes) because "inputs" conflates with the use of "input" elsewhere