API for EnvironmentLess Stores about swift-composable-architecture HOT 5 CLOSED

This is worth having a discussion about. Thanks @natemann!

Early on we played with some helpers for Void environments, but in practice we found that these Void environments almost always became struct environments with dependencies, and that the work to make this happen was less cumbersome if we started with empty struct environments to begin with:

• Fewer places to rename Void to XyEnvironment (a type alias can help here, but that's even more work you have to undo)
• Fewer things to change in pullback transformations and similar

This is why all of the examples in the repo define struct environments, even if they don't have any dependencies.

Of course, these are just the trade-offs we've currently landed at, and depending on how someone builds an application and how much they modularize, I can see some applications having a lot of small reducers with no dependencies at all benefitting from using Void for their environments.

One more helper is a reducer initializer that doesn't need to return Effect.none:

• Reducer.init(_: (inout State, Action) -> Void) where Environment == Void

from swift-composable-architecture.

@stephencelis. I see your point.

I was not really thinking about a reducer that does not have to return Effect.none. I have a few reducers that don't have an environment, but still return an Effect. Mostly just the fireAndForget kind.

Secondly, I feel that we can still have an Environment , but have a reducer that does not return an Effect. I'm thinking of something like Environment.currentDate that just returns the current time.

I know this is a little off topic, but your last comment intrigued me. My thoughts on Environment == Void was to not have to write environment: { _ in () } in pullbacks and scopes.

from swift-composable-architecture.

I have a few reducers that don't have an environment, but still return an Effect. Mostly just the fireAndForget kind.

Worth noting that you'll still want to introduce an environment to supply this work if you want to write tests for those actions. We have a few examples of these kinds of tests in the demo apps. Voice Memos, for one, has some fire-and-forget effects in its audio recorder and audio player dependencies.

My thoughts on Environment == Void was to not have to write environment: { _ in () } in pullbacks and scopes.

Yup! I think those versions of pullback are definitely handy for reducers with Void environments.

from swift-composable-architecture.

@natemann We just got a Swift forum for discussions like this so that we can tighten the GitHub issues focus on bugs. Would you like to move the discussion there?

from swift-composable-architecture.

Sure thing.

from swift-composable-architecture.