Architecture constraints and improvement proposals

[Fiser12]

Hello to all of you

I'm trying to have an architecture as close as possible to how things are done in Redux and the Environments doesn't convince me. I am thinking in how to implement DDD and CQRS too.

I believe that the reducer should not be responsible for dispatching new Effects, to keep it as simple as possible. And that Environments should be able to be coupled to the execution of all reducers afterwards and be able to identify what Action has arrived and what changes have occurred.

I mean environments and reducers would be decoupled. At the moment I want to implement this idea by adding a Reducer at the end of the cycle that listens to the complete State and all Actions and returns new Effects. Since I can't figure out how to have direct access to the Dispatch from a reducer.

Following DDD design, and thinking about Redux and TCA. In redux, the reducers are listeners to actions, that in DDD are Domain Events, that only change the Domain of your application, and they don't have more responsibility. (I know that is not the same, but follow me).
However, in TCA as you are launching an Effect after the execution of the changes we cannot talk about a simple domain event. It's a domain event that after that launch an application event, that could be out of the scope of the domain, depending on the responsibility of the environment that are you using. Under DDD architecture you should call first of all to an Application Event, using CQRS as a pattern for example and after all change the state/domain, that this should be the scope of Redux/TCA, the single source of truth.

There are 2 pieces of stuff here:

• If TCA wants to be closer to Redux, I think that Reducers and the dispatch of new Actions or Environments should be decoupled, and Environments/Middlewares should listen to the new actions after the changes in the state.
• If we think of DDD and CQRS, I think that the approach should be different. We should launch Application Events or Commands that interact with the Infrastructure layer (API REST, Core Data, System Libraries...) and after all the interactions necessary, that should launch a change in the Domain. Under this approach. The Environment could launch Domain Events/Actions for changing the State, but the reducers should not launch any more than state changes, should be always the last step of the cycle.

The main problem that I see is that the single responsibility it's not defined. I continue thinking about how to implement my ideas. I hope that I explained correctly, I would like to know your opinion on this architecture approach.

[mbrandonw]

Hi @Fiser12, thanks for the discussion!

You bring up a lot of good points, and many of those things were considered in the creation of the library. The separation of state mutation and effects is something we spent a lot of time with. There are other libraries that do this (some of which are listed in the Readme), but we ultimately decided against it.

The separation sounds enticing at first, but it was not clear to us what benefits it had over the current solution. There don't seem to be any problems it solves that the current reducer signature can't do, and vice versa. The biggest difference, in our opinion, was with ergonomics. Do we want to have to deal with two concepts, reducer and effect handlers, or a single concept that marries them together.

One thing to keep in mind is that this library does not have a stated goal to be closer to Redux. We like modeling application logic with reducers and delegating the runtime of the application to stores, but that's where the similarities end.

We have a strong focus on composition of reducers (via pullback, combine, forEach and more) and stores (via scope, ForEachStore, SwitchStore and more). These operators allow us to modularize code bases so that features can be understood in isolation. By having more concepts in the library we are increasing the number of things that need a corresponding composition operator. So not only would we need a way to pullback reducers, but we would also have to think about what pullback means for effect handlers. And same for all the other operators.

Further, the top goal of this library is testing. We want testing to be as simple as possible and as exhaustive as possible. If splitting state mutation from effect handlers made testing even more powerful, we'd be all over it. But all it appears to let us do is test state mutation separately from effect execution, which not only is technically possible with the current reducer type, but it's also not what we would recommend. The think it's better to test the whole package at once with a TestStore so that you get a full end-to-end test suite that shows how state mutations and effect executions intermingle. It can fail the test suite when you receive an action you didn't expect from an effect, or when the test case ends and an effect was still inflight.

Having said all that, there's certainly something we could have missed in our explorations. If you could share some code of where you feel like your approach shines we'd be happy to take a look and give our thoughts. The repo also contains lots of case studies and demo applications, and so perhaps you could describe some things you see wrong with them and how your approach might fix those problems.

[Fiser12]

Hello, thank you for your detailed explanation

Above all, I have found complications in the pullback. I try to create a reducer per aggregate, injecting its environments. Which in this case are Core Data repositories that work with Effects or calls to APIs exclusive to that aggregate.

But at some point it happens that I want to launch an action related to another state, For example, if I save the authentication id but the secret data is optioned through another aggregate in another state. Another environment pulls the stuff from Keychain but the aggregate knows which one to take because it has its unique identifier. In these cases of interrelating states, I have solved it by passing all actions to all reducers and adding a guard at the beginning of each one.
I had thought of adding a reducer at the end that listens to all the actions and has access to all the states to do these operations but I'm not too convinced. Another solution would be to make 2 separate queries in SwiftUI or a function with its responsibility.

[Fiser12]

I attach here a gist with one environment that I created to bind one key pressed event to your environment allowing you to map an action to send it. It requires the KeyboardShortcuts library. In that case, I also need to send an action to another State. Maybe I should reorganize the code structure. I have the idea of creating one library with it
https://gist.github.com/Fiser12/b14c0a5006b26d33036298e389585c6d