Migrating from Services based architecture to TCA

[captadoh]

Hello,

First off thanks for making TCA 🤙 - I'm existed to start rewriting my app in it.

Currently my app consists of many Services (ie UserService, NetworkOfflineService, NetworkingService ... etc) that talk to each other by me doing dependency injection either in the constructor or via each service's "injectDependencies" function.

Each service has some ephemeral state that clears when the app closes and some persisted state via UserDefaults.

Things were getting messy, confusing and complex... which led me to research a better way... enter TCA.

I have read a lot of your docs, watched a lot of your videos and believe I have a rough handle on how things work. I especially love the idea of sharing state backed by UserDefaults.

Questions:

1. Is it ok to name things XYZServices when using TCA?
2. I noticed the majority of your examples use Feature in the file / module name - is that an encouraged practice to create certain metal models?

In my UserService I have the following functionality:

• sign in
• sign out
• if the device has internet (need to ask the NetworkOfflineService) then i start a timer to check if the user has a specific label on their account every 30 seconds
• if the device has no internet than i either stop the timer or dont start it in the first place
• once the user is authenticated i save their info to UserDefaults so the user can use my app in offline mode

In my NetworkOfflineService I have the following functionality:

• check if the user has exceeded their offline time limit - if yes then cause a sheet to show and it wont go away until they go back online
• if the user goes offline save the current time and then start a timer to check if the user has exceeded their offline time amount ever 30 seconds

In my NetworkingService I have the following functionality:

• use NWConnection, NWBrowser, NWListener and all that to create peer to peer connections between N devices
• I have no persisted state when networking is being used
• I do save connections and connection groups but they clear when the app closes
• I do persist settings, via UserDefaults, that configures how the NetworkingService can behave (ie is Networking on or off)

Generally - each Service has some persisted state and some ephemeral state and needs to talk to N number of other services.

Trying to translate that mental model / design over the TCA I see that I can achieve that by:

• using the shared state backed by UserDefaults
• nesting reducers so each "Service" can talk to each other by sending effects?

Question:

• can a Feature A have Feature B's reducer in its reducer and can Feature B have Feature A's reducer in its reducer..... can I have circular dependencies in TCA?
• is my design flawed or not broken down enough? My UserService needs to know if the device is offline by asking the NetworkOfflineService and the NetworkOfflineService needs the UserService so it can start the user timer once the device goes back online.

Regards,
Captadoh

[stephencelis]

@captadoh The TCA analogue to your "services" is its dependency layer, which is powered by swift-dependencies. You should be able to model each of your services as a dependency that TCA features can access using the @Dependency property wrapper.

TCA features (reducers) are typically broken down per screen, so if you can share a more concrete example of how you are picturing using reducers we can maybe give more guidance.

can a Feature A have Feature B's reducer in its reducer and can Feature B have Feature A's reducer in its reducer..... can I have circular dependencies in TCA?

Because reducers are typically broken down by screen, recursion is typically handled via stack navigation, which TCA ships tools for: https://pointfreeco.github.io/swift-composable-architecture/main/documentation/composablearchitecture/stackbasednavigation

is my design flawed or not broken down enough? My UserService needs to know if the device is offline by asking the NetworkOfflineService and the NetworkOfflineService needs the UserService so it can start the user timer once the device goes back online.

A dependency can access another dependency, so this should work just fine, but let us know if you run in to concrete problems and we can help out.

And if you haven't already, I'd check out the various demo apps in the repo to see how reducers can be designed, how they use dependencies, etc.

[captadoh]

Hi Stephen - thanks for the prompt response!

Before I dive into the rewrite one more quick question: has anyone used TCA for the backend and for some front end? Let me explain.

TCA features (reducers) are typically broken down per screen

A user button tap would send a user action to the store... could I have TCA Feature A (not from a user tap / interaction) send an action to TCA Feature B's store?

Maybe that is what you were talking about when you mentioned using dependencies?

Im asking this because I have functionality / logic that happens behinds the scenes and isn't directly connected to a screen. For example the user can navigate to my settings screen, toggle ON voice control (which starts up speech recognition) and then they can leave to a different screen. The speech recognition is listening for keywords to then automatically take action.

So my VoiceControlFeature/Service would recognize a keyword and then send an action to the NetworkingFeature/Service to do XYZ. In this case there is no user interaction (user tapping that is) but I need to send an action.

I really like how you guys break things up into State, Action, Reducer and Store. Id love to use that structure for both screen related features and also for features / services that don't necessarily have a screen.

[stephencelis]

A user button tap would send a user action to the store... could I have TCA Feature A (not from a user tap / interaction) send an action to TCA Feature B's store?

Maybe that is what you were talking about when you mentioned using dependencies?

Yep, for example, sending a buttonTap action in FeatureA may use an Effect that posts a notification for FeatureB to listen to, and FeatureB may have an onAppear action that uses an Effect to listen for that notification.

[captadoh]

@stephencelis I've done more research on what I'm looking for and I believe it boils down to the following (let's assume I'm using MVVM for this):

Terminology

• a view is a view
• a view model uses @Observable so the view using it is reactive to changes
• a service is not a view and not a view model so it just deals with business logic

Questions

• how can a service communicate to N number of other services
• how can a service communicate to N number of view models

An example is as follows:

Setup

• user has three physical devices
• user has my app open and running on all of the devices
• all the devices are near each other and or on the same network

Scenario

• user is on "settings" screen on all the devices
• user toggles on "device discovery" on all the devices
• this turns on the peer to peer networking on all the devices
• user then navigates away from the "settings" screen to the main screen (this is done on all the devices)
• now behind the scenes the networking service is discovering other devices, connecting to them and also sending messages back and forth
• there will be many things going on behind the scenes that doesn't effect the current screen but needs to be communicated to many services

In my mind having an event bus would be my silver bullet. I know this may be naive but it helps all the pieces fit together in my head.

This event bus can be used by view models and services.

If something happens in a service that is important to other services and or other view models then that service would just publish the event and everyone who cares would have subscribed to that event.

To continue on this - I've been thinking of using https://github.com/pointfreeco/swift-sharing as a down and dirty event bus...

I would have a StateService that has many @Shared variables. It would act as the centralized state manager. Everyone else uses @SharedReader. If anyone (service or view model) wants to change state they have to go through the StateService. I can inject the StateService into other services via their constructor. Everyone who has the @SharedReader can use the value and they can also setup $x.count.publisher.sink to take actions when the value changes.

I'd appreciate your insight on using swift-sharing as a type of event bus as well how TCA can meet my needs. Thank you.