Lazy dependencies and Environments

[bielikb]

Hi,

Ive got (probably) amateur question as I'm exploring the Composable Architecture.
In the following graph, you can see the flow/view hierarchy of the Scrumdinger app that I tried to migrate to Composable Architecture.

Most of the views in this graph have their own environments with their own env dependencies specified, yet not all of the environments should be wandering around throughout the whole life-cycle of the app.

Currently that's the case in the project Im working on. All environments that are used within the app are initialized at the top level.

Is there a way how to actually defer the initialization time of specific environment down in the view hierarchy?

Let's take an exact example:
I've defined following environment for MeetingView along with meetingReducer.

struct MeetingEnvironment {
    let scrumTimer: ScrumTimer
    ....
}

In the parent reducer for DetailView I'm using pullback API to bind the state and action to the parent reducer.

let detailViewReducer = Reducer<DetailViewState, DetailViewAction, DetailViewEnvironment>.combine(
    meetingViewReducer.pullback(state: \DetailViewState.meetingState,
                                action: /DetailViewAction.meetingAction,
                                environment: { $0.meetingViewEnvironment }),
    ...
)

My issue here is that If I wouldn't keep the reference to the instance of MeetingEnvironment that initialises the ScrumTimer, the ScrumTimer would be deinitialised as soon as the pullback closure would be called

Maybe Im doing something wrong, so feel free to correct me. Thanks in advance!

Best,
Boris

Source code:
detailViewReducer
MeetingViewEnvironment

[stephencelis]

My issue here is that If I wouldn't keep the reference to the instance of MeetingEnvironment that initialises the ScrumTimer, the ScrumTimer would be deinitialised as soon as the pullback closure would be called

Do you have an example of this? Reducer.pullback captures a transformation of a global environment into a more local one, but that global environment should be as long living as your app's store, so the scrumTimer shouldn't ever be deinitialized.

[bielikb]

Actually, that's the case in the current stage of my implementation. All the environments are initialised as soon as the appEnvironment is instantiated.
The "env dependency hierarchy" copies that of the view hierarchy.

I suppose my question here is, whether there's a way to instantiate & deinitialise the environments just as they're needed, and to avoid keeping them around throughout the whole app life-cycle.

I could mark the ScrumTimer property as lazy, yet I wondered if there's any other strategy in TCA that would allow me to "pullback & keep" the newly created instance of environment just for the time it's needed.
One of the possible ways of doing so would be to introduce optionality, but that would overcomplicate the whole API.

I guess, currently Im just probably overthinking the initialisation strategy for sub-environments held by the AppEnvironment.

[bielikb]

The env dependency tree looks like this:

appEnvironment
👇
scrumsViewEnvironment
👇
detailViewEnvironment
👇
meetingViewEnvironment

where
meetingViewEnvironment instantiates the ScrumTimer. ScrumTimer is though needed only in the case the user ever gets to the MeetingView and shouldn't be initialised every time the app starts.

[stephencelis]

Take a look at how ComposableCoreLocation and ComposableCoreMotion manage their life cycles. They have .create and .destroy lifecycle effects that you can fire off when someone enters and leaves a feature. Your app will still always have one of these clients in its environment, but the manager under the hood that listens for location/motion updates isn't always active.

[bielikb]

Thanks for your help. That basically answers my question.