No, that would make for a circular dependency, sin...

# ballast

[Casey Brooks]

No, that would make for a circular dependency, since the InputHandler is set in the Repository’s constructor. What you can do is create an Input that can be sent from both the sideJob and the corresponding method of the Repository

[rocketraman]

Not sure how that helps... sending the input is not the problem. The problem is acting on the input based on some logic which currently resides in the repo.

What I'm thinking of doing right now is extracting that logic into a separate class that can be injected into both the input handler and the repo.

[Casey Brooks]

By having the Repository interface method do nothing but send an Input, then the logic for doing that thing is kept in 1 place: the InputHandler. Regardless of whether the UI layer requested that change (through the Repository interface) or it was requested from some action within the Repository layer (the sideJob or EventBus), it will get processed in the same way and have access to the same State and dependencies in all cases

[Casey Brooks]

But maybe I’m just not understanding your use-case correctly. Could you send me a code snippet to see what you’re trying to do?

[rocketraman]

To close the loop here, I believe the idea is that the repository interface serves as the entry point for actions taken by the view (or as user-visible state that needs to be observed by the view), but that the repository implementation itself shouldn't do much except post inputs and events or observe states.

It's the input handler that should contain the logic to make remote calls in response to those inputs, and update state in response.