Replace current Redux-like flow with TCA

[Abizern]

• TCA is under active development, performant, and provides many ways to improve the test coverage in the app.
• TCA is well documented and used by many people so there is less of blockage for getting people to contribute to the codebase when it has a well used dependency
• The current State, and Actions are all in one big file and not close to the views or reducers in which they are used. In TCA, state, actions and reducers are mostly defined where they are used, in the same file as the View, and composed together further up in the app. It's a lot easier to see what is used and not used, and it's a lot easier to spot stale state or code.

[nickoneill]

Any high level docs I can read on TCA? I like the reasoning, state and actions being far away from where they're used is a pain, but I am hesitant to want to jump into another data flow refactoring without understanding it more.

[Abizern]

I completely understand.

A quick way to do it is to read through the tutorials at https://swiftpackageindex.com/pointfreeco/swift-composable-architecture/main/tutorials/meetcomposablearchitecture

It says 4:30 to do them, but if you don’t do it as a code-along and just read the notes and code as they come up it’s a lot faster. It covers the main parts of data flow, dependencies, testing and navigation.

[cselin]

TCA is great and quickly becoming a widely used standard for unidirectional flow. I use it at my current company. It is very similar to what we started building out with our redux-like flow although it does have a bit steeper learning curve IMO compared to our simple redux-like flow for people who aren't used to either. The folks at pointfree have great tutorials and documentation and actively (maybe a little too actively sometimes) work to improve ergonomics and stay current with Swift and Xcode, but churn can be avoided by not trying to always stay current.

[nickoneill]

OK, it feels enough like the future that we should give it a shot. There are a couple tricky bits that I'd be careful about handling: off the top of my head something like updating your location, which re-fetches contacts, which might update your district which then might re-fetch messages for the "inbox" feature.

The inbox feature isn't running right now, so it's not important to migrate that part of the functionality on an initial pass, but just as an FYI these kinds of interconnected requests triggering other effects should be possible.

[Abizern]

Thank you. That sort of functionality should be possible. I'll start working on it the refactor and look at integrating the Inbox feature afterwards.

I'll continue working on this.