Understanding the ApiClient & Session structure

[oliverfoggin]

I've been looking into this project to try and understand some of the structures used and why they're used and one that I can't quite understand is the ApiClient.live static func. This is the file I'm referencing... https://github.com/pointfreeco/isowords/blob/main/Sources/ApiClientLive/Live.swift

First quick side question...

As it's a static function this could be called multiple times in the project and each time it would give you a new ApiClient. (I know this isn't the case in this project but it's possible). Is this something that has been considered and is just not done due to using the Environment in TCA? Or is there something protecting against that being done?

Second...

The way this function works is really what I'm trying to get my head around. 😅

In the function you first create a router and baseURL and then define a new type scoped to the function of actor Session. The Session is the actual working type of the Api Client and so has the logic that eventually makes the API requests etc...

Then you create a session scoped to the function using the router and baseURL.

Then you finally create an ApiClient proxying all the functions through to the session.

NVM... I've finally understood it 😄

[stephencelis]

Hey @oliverfoggin!

As it's a static function this could be called multiple times in the project and each time it would give you a new ApiClient. (I know this isn't the case in this project but it's possible). Is this something that has been considered and is just not done due to using the Environment in TCA? Or is there something protecting against that being done?

The app entry point is what provides an environment to this store, and this environment value does not change over time. We even have a helper static let in the file responsible for creating the store here:

isowords/App/iOS/App.swift

Lines 118 to 122 in 699db8a

	extension ApiClient {
	static let live = Self.live(
	sha256: { Data(SHA256.hash(data: $0)) }
	)
	}

Even if this were a computed var, though, that returned a different value each time, that wouldn't matter because it is only invoked once, upon app launch.

Sounds like you figured out the second question, though? 😄

[oliverfoggin]

Thanks! Ah ok, that makes sense. We had spoken about doing something similar with storing a static property of the initialised value and returning that by default if it exists. 😄

Yeah, on the second question I was getting confused thinking that it was creating a memory leak but actually it's not. The closures of the APIClient are just capturing the session. But no reference cycles are created. 👍🏻

Thanks