Hi, can you provide an example of post processing?...

# mvikotlin

[Artyom Bambalov]

Hi, can you provide an example of post processing? Do you have any plans to add PostProcessor like in MVICore? Thanks

[Arkadii Ivanov]

Hello. PostProcessor is not required in MVIKotlin, because you always has the access to the current state. You are able to dispatch(Cmd1) , then get the updated state via getState() , and then perform additional actions if needed and dispatch another commands dispatch(Cmd2).

[Artyom Bambalov]

It can lead to too complicated logic in my opinion. Post Processor looks like a good concerns segregation

[Arkadii Ivanov]

Well, avoiding PostProcessor and NewsPublisher was one of the main ideas at the very beginning. I provided some comparison with MVICore in the discussion. The rationale for this is as follows:
1. PostProcessor is rarely needed according to my experience with MVICore
2. When it is actually needed - this means that you need to perform additional actions after updating the state, based on the new state. So you can't just concat two actions together. But firstly perform the action A, then perform action B based on the new state.
3. Adding PostProcessor is quite noisy - a. You need to introduce Action classes; b. You need to convert your Actor (aka Executor in MVIKotlin) from processing Intents to process Actions; c. You need to add a mapper from Intents to `Actions`; d. Finally you need to add the PostProcessor class.
Instead, MVIKotlin provides the ability to dispatch Cmd to the Reducer , read the new state straight away and continue the job. The segregation of concerns can be addressed by extracting dedicated private methods for different actions.

[Artyom Bambalov]

Thanks. I got your point.

So, another question. Is this code legal from the best practices side?

override fun executeIntent(
		intent: MviIntent,
		getState: () -> MviState,
	) {
		when (intent) {
			is SomeIntent1 -> {
				doWork1(getState)
			}
            is SomeIntent2 -> {
                doWork2()
            }
		}
	}

	private fun doWork1(getState: () -> MviState) {
		scope.launch {
            val condition: Boolean = ///
            ///
            if (condition) {
                executeIntent(
                    SomeIntent2,
                    getState
                )
            }
		}
	}

[Arkadii Ivanov]

It is good enough. I would call doWork2 directly instead of executeIntent(SomeIntent2, getState), though.

[Artyom Bambalov]

I just want to keep them unbound directly. As you said, "purity vs boilerplate"

[Arkadii Ivanov]

By purity vs boilerplate I meant that in MVICore there is no getState function, you receive the state as a value. So all functions look purer. But you have to write more code if you need to check the updated state.

Personally I don't see anything wrong by calling dedicated functions directly, instead of executeIntent. They are all private, I would prefer calling dedicated functions instead of more generic.
But it is up to you, no strict rules here.

[Artyom Bambalov]

Okay, thank you