I have an InputHandler which does some "external" ...

# ballast

[rocketraman]

I have an InputHandler which does some "external" stuff that falls outside of the MVI model. When I do this, Ballast tells me the input was not handled successfully, and I have to add a noOp call or wrap the logic in a side job. It seems a bit odd to me that if my input handler does this:

doSomething()
setState { ... }

its ok. But if my input handler just does:

doSomething()

then I have to either do

doSomething()
noOp()

or

sideJob { doSomething() }

Am I missing something about how the API is supposed to work and/or about the safety of calling doSomething()?

[Casey Brooks]

This is intentional, designed to help you avoid doing things incorrectly. The MVI model need to maintain its “finite state machine” to ensure its purity, so doing things “outside of the MVI model” shouldn’t really be done lightly.

noOp() is there more to help when first writing your Contract, to be able to send the Input and build the corresponding UI without necessarily implementing it in the InputHandler just yet. Another use-case for it is more complex handling that may have several branches of code updating state, posting events, etc. but one particular branch ignoring the Input for some reason. You would mark that branch as noOp() to signify that you intend for nothing to happen there.

For this example, it sounds like putting that doSomething() into a sideJob would be the way to go. Since you don’t need to update the State or send an Event as the result of doSomething(), it shouldn’t need to be executed immediately and sideJob is that kind of “managed” fire-and-forget mechanism