Sharing across modules

[lilidotshi]

Hi! I'm currently implementing sharing of state across our app. However i'm encountering a situation where each module seems to be instantiating its own version of the variable "inMemory."

Say for instance, I have FrameworkA, which handles these some state change like such:

struct FooClient {
    var updateString: @Sendable (_ value: String) -> Void
}

extension FooClient: TestDependencyKey {
    public static let testValue = Self(
        updateString: { newValue in 
            @Shared(.inMemory("testString")) var testString = "Hello"
            $testString.withLock { $0 = newValue }
        }
    }
}

And then in my main app I have a test that looks like this:

    @Test
    func testState() {
        @Shared(.inMemory("testString")) var testString = "Test Initial"
        @Dependency(\.fooClient) var fooClient
        print("Within the test it is \(testString)") // Prints "Test Initial"

        let cancellable = $testString.publisher.sink { newValue in
            print("The value changed to \(newValue)")
        }

        fooClient.updateString("New Value")
    }

In my case, I'm seeing that updateString isn't triggering a change in the test. More curiously, the client will print out "Hello" (its initial string) and the test will print out "Test Initial", it's initial string, which I am to understand is not supposed to happen because it should have been accessed.

NOTE: this is not a great example, because I actually tried the bare bones example and it works as expected, except if i try this pattern in my actual app, where I'm encountering the unexpected behavior. Any ideas on why it would seem like the client and the test are running on two different instances of memory?

[mbrandonw]

Hi @lilidotshi, you have most likely linked either Sharing or Dependencies to your test target, which creates duplicate symbols. You may even have some warnings in your logs about this. Make sure you do not link our libraries to your test target, and instead only link the target you are testing.

[lilidotshi]

Oh i see what you're saying, let me give that a try.

[lilidotshi]

Just a quick separate note unrelated to the issue I had above, I have this following dependency linking structure:

TCA -> FrameworkA -> TCASharingExampleApp -> TCASharingExampleTests

Yet i'm still seeing the warning about duplicate classes (DependencyCachedValues, DependenciesTestObserver). I don't think that's meant to happen? I've attached my example.

TCASharingExample.zip

[lilidotshi]

Also I did a quick check, my test target does not link either of those libraries. It is using transitive linking from the framework.

[mbrandonw]

Hi @lilidotshi, it looks like you are using tuist for this project? This may be a better question for them.

[lilidotshi]

Thanks Brandon, I'll ask them if they have any ideas or if the default build settings they have might be giving us issues.

Kind of along the same vein, I have a pretty modular architecture, in the sense that features are all divvied up into frameworks. In debug, they're dynamic libs (speeds up our incremental builds) and in prod they get recompiled as static frameworks. As such though, I tend to import Composable Architecture in a few frameworks for modularity. Based on our discussion, I'm a bit worried I may run into conflicting symbols, because FrameworkA and FrameworkB both need it as a dependency. Have you run into this issue with modular architecture?