Concatenated Effects - response ordering

[rhysm94]

Hi all,

I'm currently hitting a bit of a wall with regards to the concatenate function on Effect.

In the app I'm working on, we need to make multiple API calls on launch. The order of the API call responses really matters, as they return data that we write to our database, for which foreign keys matter. i.e. The first API call might return some Foo instances, which need to be written before the next API call's Bar instances are written, as the Bar has an ID field referencing a Foo, which might not be present in the database if they're not written in the correct order.

We're currently wrapping all our action up into a concatenate, as the documentation says it dispatches Effects one after the other. However, it doesn't seem to wait for the previous Effect to complete before sending the next Effect. Due to the size of the responses, the network, or whatever, the order in which we send the actions isn't necessarily the order in which we receive them. i.e. we might get the Bar response before the Foo response, which causes havoc with our database.

I know we could probably wrap this up into a dependency, with just one call from the Reducer, but this seems to fly against the testability enabled by TCA. I've personally already made that choice once before, when juggling API calls and database writes, and I'd just like to know if there's a better way using the tools TCA/Combine already gives us?

I've put a sample project up showing exactly what I mean here: TCA-ActionChain
I've simulated the API async nature by adding a random delay onto each response action.

If anyone has any ideas, I'd greatly appreciate them!

Thanks!

[filblue]

Your side-effectful effects are not really concatenated. The three getXYZ messages are fired one after another synchronously, which causes the actual effects to start more or less instantly and they have no means to respect each others' lifecycles.

The concatenation of the effects in your case can be achieved by concatenating actual jobs, like:

.concatenate(
    Effect(value: .getFooResponse(.success("Hello, World!")))
        .delay(for: .seconds(env.randomNumberGen()), scheduler: env.mainQueue)
        .eraseToEffect(),
    Effect(value: .getBarResponse(.success(3.14159265)))
        .delay(for: .seconds(env.randomNumberGen()), scheduler: env.mainQueue)
        .eraseToEffect(),
    Effect(value: .getBazResponse(.success(5)))
        .delay(for: .seconds(env.randomNumberGen()), scheduler: env.mainQueue)
        .eraseToEffect()
)

Is there any reason for you to have the getXYZ actions at all?

[filblue]

If for some reason you really do need those getXYZ actions, you may consider firing only the getFoo, and start the second request after the first one completes,

case .getFooResponse(let result):
	return Effect(value: .getBar)

, which will be effectively hard-coding the sequential nature of the calls in your reducer without leveraging Effect.concatenate at all.

[fabstu]

You can also use .flatMap and return from it the next effect. If you need the output you have to somehow pass that along though maybe.

[rhysm94]

Your side-effectful effects are not really concatenated. The three getXYZ messages are fired one after another synchronously, which causes the actual effects to start more or less instantly and they have no means to respect each others' lifecycles.

This is kinda what I was worried was happening 😬

Is there any reason for you to have the getXYZ actions at all?

Yep - each getXYZ action triggers a separate URLSession task to get some data from our server.
I know in my example project that I've hardcoded the responses, but in the real app, they're coming back from a server, so I can't just immediately start with concatenating responses. The delay method is only there to simulate the variance in time with API responses.

[mbrandonw]

You have two options to fix this. You can either use .flatMap like @fabstu suggested:

environment.apiClient.requestA()
  .flatMap { environment.apiClient.requestB($0) }
  .flatMap { environment.apiClient.requestC($0) }

Or you can kick off the next effect when one completes:

case .tap:
  return environment.apiClient.requestA()
    .map(AppAction.responseA)

case let .responseA(.success(data)):
  return environment.apiClient.requestB(data)
    .map(AppAction.responseB)

case let .responseB(.success(data))
  return environment.apiClient.requestC(data)
    .map(AppAction.responseC)

case let .responseC(.success(data)):
  ...

But as @filblue mentioned, .concatenate only concatenates the effects you provide right there at the call site, it does not concatenate the effects that are later returned by other actions in the reducer.

[3a4oT]

I was surprised by that behavior of .concatenate as well.

it does not concatenate the effects that are later returned by other actions in the reducer.

That is very unfortunate and confusing.

[mbrandonw]

The alternative would also be confusing in its own way. Maybe even more so.

If you returned .concatenate(effect1, effect2) and the actions emitted by effect1 mutated the state, would you expect those mutations to be visible to effect2? That would not be possible to do, but some may expect that to be the case.

I think the key to understanding why the behavior is this way is to understand that sending an action into the store results in two distinct processes. First, the reducer is run so that all state mutations can be made. And then, all the effects returned by the reducer are gathered up and executed. Those two processes are completely independent, even if it's an effect that caused the action to be sent into the store.

Hope that helps.

[3a4oT]

Thanks! that's make sense but I would love at least have that alternative and not invent a bike each time I need it =) It almost always be a right tool for chained network requests.