We use Reactor Kit in our app with 200K daily active users. It's basically TCA philosophy with Per screen state store. And then on each view only updating if it's required slice within the state is mutated.

This architecture was relevant in the React community a while ago (Redux), but the trend seems to be moving towards simpler architectures like react-query, hooks, etc. I am not sure if the iOS engineering community will follow the same path, as the problem is universal across FE development (state management is complex)

@SwiftHeroes

3 ай бұрын

Interesting observation, we asked Krzysztof to reply to you 😉

@rodriferretty3001

3 ай бұрын

Really interested about this point!

Please provide links to the sample project and swiftlint config file.

At 7:53... Sure but the problem with these sorts of architectures is that any one action could change any piece of state. So not only do you have to assert the correct state changes, but you also have to assert that no other bits of state changed. That's n*m assertions (where n is the number of actions, and m the possible states.) In other words, your assertions grow exponentially with every action or piece of state you add. Not good!

@ImTheShrey

4 ай бұрын

We solved it by dividing app state into per screen state. And then you do diff of a state slices (properties) when your views want to use it, so they don't refresh when other non related field in state object changes. Then to top it off, you collect all mutations Done by one action in to a batch and only update state struct in one go.

@danielt63

4 ай бұрын

@@ImTheShrey Sure, but every reducer receives every action. Your per screen state receives actions from other screens and it is only by convention that it doesn't act on actions from other screens. Testing to ensure that convention is where the problem lies.