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)
@SwiftHeroes10 ай бұрын
Interesting observation, we asked Krzysztof to reply to you 😉
@rodriferretty300110 ай бұрын
Really interested about this point!
@ImTheShrey11 ай бұрын
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.
@rohitsainier6 ай бұрын
Hi @ImTheShrey do you have sample repo to learn your approch here
@ihorzhukov5 ай бұрын
+1 on a sample if you, please.
@trendz4422 Жыл бұрын
Please provide links to the sample project and swiftlint config file.
@danielt63 Жыл бұрын
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!
@ImTheShrey11 ай бұрын
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.
@danielt6311 ай бұрын
@@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.