Mutable properties in an Environment

[mluisbrown]

In the project I'm working on we have a number of places where we have what is technically mutable state, in an Environment property 😱

For example: we have an APIClient class that can make generic requests to an API Resource (endpoint path, HTTP method, parameters etc). This is initialised in our AppEnvironment. However, once a user has logged in, all requests need to have an extra "account-id" header (questionable API design, but not within our control).

So, APIClient has a var accountId: AccountId? property which, if set, will be added to any request headers. In one of the reducers that handles with a user becoming logged in we have env.apiClient.accountId = user.accountId.

This means we're basically using this environment property as global mutable state, which has always struck me as code smell, but I haven't really thought of a good alternative.

I guess the "correct" way to do this would be to keep this property in the AppState, and whenever it changes, let any child-states that need it know via an Action, and then when any part of the app needs to make a network request, it would need to pass this ID along with the API remaining request parameters so that the ID can be set in the header. But this seems like a lot of boilerplate for such an apparently simple thing.

btw, this account ID cannot be encoded in the Auth Token, since a single user can have multiple accounts and can switch between them whilst using the app.

[rhysm94]

Can you store them in the Keychain or a database, and just write to it via the environment?
While mutating the environment itself is not possible, you can use it to write to something external.

[jasdev]

If I’m reading the snippet right, isowords takes this approach (by writing out to defaults).

[mbrandonw]

We don't think mutable state in an environment dependency is a bad thing! In fact, that's what the environment is for!

For example, if you wrote a nice wrapper around UserDefaults and put that in your environment then you've immediately got global shared state. Same if you have a dependency wrapper around file access. Or if you have a database dependency.

And so the API client having a little shared mutable data to represent the current session, such as an access token, current user, or in your case account id, is totally fine.

And as @jasdev pointed out, this is exactly what we do in isowords. The "live" API client holds a mutable currentPlayer (it's also backed by user defaults, but that's besides the point):

https://github.com/pointfreeco/isowords/blob/6973af4924730b945a92206010bb3cb0a226315e/Sources/ApiClientLive/Live.swift#L35

One important thing to note is that it's locally scoped to just the construction of the live instant, and so it will never leak out unintentionally. The only way to get access to this shared mutable state is through the dependency's endpoints.

For example, when you "authenticate" the player we update that shared mutable value:

https://github.com/pointfreeco/isowords/blob/6973af4924730b945a92206010bb3cb0a226315e/Sources/ApiClientLive/Live.swift#L70

And when you log out we nil out that shared mutable value:

https://github.com/pointfreeco/isowords/blob/6973af4924730b945a92206010bb3cb0a226315e/Sources/ApiClientLive/Live.swift#L76

And when we refresh the current player we update that mutable value:

https://github.com/pointfreeco/isowords/blob/6973af4924730b945a92206010bb3cb0a226315e/Sources/ApiClientLive/Live.swift#L87

In our opinion it's no different than thinking of "current player" as something in a database, or stored in shared user defaults, or stored on disk, etc. The key is to control how it's accessed through the dependency because that makes it easier to understand how the outside world accesses and mutates it, and makes it testable.

[lordzsolt]

Doesn't this straight up invalidate the biggest benefit of TCA? That being the fact the the Views are always in sync with the State, with no extra code from your side?

Changes to the State trigger a redraw. Changes to this "shared state" do not trigger a redraw.

[acosmicflamingo]

In case anyone is interested in providing feedback, I created a PR for Isowords attempting to implement my interpretation of how persistence should be ideally handled: pointfreeco/isowords#169. It's a work-in-progress but hopefully I can get it to a production-ready state and then we can all benefit from learning how persistence can be handled in a real-world app :)