Shared State Not Using Injected Dependencies When Created in SwiftUI View

[grantjbutler]

I think I've found a rough edge with the shard state functionality that I'm not totally sure how to work around. In essence, if I'm creating some shared state as part of a NavigationLink's initializer, any injected dependencies aren't provided to the shared state's persistence key because the creation of the shared state doesn't happen in a reducer, which has access to the injected dependencies.

I've attached a sample project that reproduces the issue. It's a simple document editor that keeps an index of the documents. It's set up so that the index exists as one file, and then each document is its own file named by the identifier of the document. When I create my root store, I override the default file system to be the in memory implementation, to showcase this issue. Then, when I display a list of documents, I create the editor state for that specific document, which sets up a shared state to read the specific document's file. Because this happens in the view and not in the reducer, this used the default live implementation of the file system, which actually writes out the file to disk, instead of using the in memory implementation.

Feel free to run this app, create a document, and then edit it. If you run xcrun simctl get_app_container booted com.grantjbutler.SharedState data to get to the app's data directory, and then look in the Documents folder, you'll see a file for the document, but you won't see a file for the index of documents (since that does use the in memory implementation and won't ever get written to disk).

Now, this all makes sense. The SwiftUI view is separate from the reducer, so they're not sharing dependencies. This is how swift-dependencies is supposed to work. I'm just not entirely sure how to get it to work how I want it to work, to get the shared state to use the injected dependency. I've thought of a couple of different ways to try to resolve this, but they all seem to have various problems.

1. In my actual application, I'm wrapping up SQLite and trying to build a custom persistence key to provide the results of a SQL query as shared state. Because I'm in full control of bridging the SQLite database into swift-dependencies, I could just update my liveValue implementation to point to the actual live implementation for the app, rather than require a database be injected, so the application has control over how the database is persisted. This would resolve the issue, as the correct implementation of the dependency would be available to the shared state, but it would mean that my bridging of SQLite into shared state is less portable, since I would have to change code in my abstraction for each application I'm working on that wants to use this abstraction.
2. I could try to transform the data returned by the shared state into child feature's state inside the parent's reducer (in the sample app, that would roughly be somehow transforming DocumentsList.State.documents into an identified array of DocumentEditor.State). Because the creation of the child feature's state would happen in the parent reducer, it would have the injected dependency of the in memory file system implementation, and would thus not persist the documents to disk. However, I'm not sure if there's a good way to pull this off with the current API surface of shared state. This may require creating a custom persistence key to do this transformation, but I'm not sure. I'm also a little unsure of the performance implications of loading all the documents at the time they're displayed (though I realize this is also a problem with this current implementation, since NavigationLink needs the state as part of the initializer, which will cause the shared state to be created and read).
3. I could see if there's some way to defer the creation of the child state, or defer the fetching of the shared state from persistence to be within the scope of the child feature's reducer. Since this is all part of the single entry point system of TCA, the injected dependency will be there for the child reducer and could be used by the persistence key. This also avoids any potential performance or memory urges issues with option 2, as the document would only be loaded form disk when the editor feature is navigated to. However, I don't think either the SwiftUI API surface or the shared state API surface allows for this to work.
4. I could see if there's some way to make withDependencies set of APIs propagate dependencies to the shared state when creating the child feature's state as part of the NavigationLink's initializer. However, from what I understand of how dependencies are propagated with reducers, I don't think things are set up in such a way that I can grab the dependencies from outside of the reducer to pass along in other areas (like the view layer).

So I'm not fully sure how to proceed here. I can definitely do option 1 to unblock myself for now, but it'd be nice if there was a potential solution here that didn't require me to do that, and I'm just "holding it wrong" and there is a way to get this to do what I want.

[mbrandonw]

Hi @grantjbutler, I believe I understand the problem you are describing, but I must apologize I did not read your entire post in depth. I believe I have a suggestion for you, but it may have been something you already considered.

My suggestion is to not use NavigationLink(state:). It's a great tool to have in a pinch, but also at the same time it's pretty problematic. Not only for the reasons you are seeing here, which is state created in the view can lose its dependencies, but also it strongly couples all the features in the stack together.

So I would suggest to just use a Button, send an action that the parent intercepts, and then construct the child state in the parent reducer. Then all dependencies will be handled properly.

Roughly, something like this:

case let .path(.element(id: _, action: .child(.rowTapped(id)))):
  guard let sharedDoc = state.documentsList.$documents[id: id]
  else { return .none }
  state.path.append(
    .anotherChild(
      AnotherChild.State(document: sharedDoc)
    )
  )

[grantjbutler]

That's a fair point and an approach I completely forgot about. It's unfortunate that there's no way that's built in to SwiftUI that gives me the standard appearance for a button in a list that NavigationLink gives me, but at least that's not horribly difficult to replicate. Thanks for reminding me that this approach is completely valid. I'll give this a shot when I'm working on my app again.

[kamcma]

I believe this does not work, but it would be cool, and helpful for this situation, if you could do something like:

withDependencies(from: self.store) {
  NavigationLink(state: /* ... */)
}

(I have no idea if this is feasible; just spitballin'.)

[mbrandonw]

Yes, that is something on our roadmap, and we also want to be possible. It's related to the next "big" thing coming to TCA, which is currently in the research phase. 🙂

[grantjbutler]

After a lot of trial and error, I've been able to successfully get this working, and done in a way that I don't have to potentially listen to deeply nested actions at a root level to perform my navigation. Thanks for the nudge in the right direction, @mbrandonw!