Referring to parent state

[JackYoustra]

Suppose we have an app with a User struct with the following view / reducer hierarchy.

A -> B -> ... -> Z

A provides the user, B - Y doesn't need the user state, and Z needs the user state. To get the state from A to Z without losing synchronization, only a few options seem possible:

• Add a user field to each state in B-Y, and keep them synchronized in action callbacks. Boilerplate and suboptimal.
• Add a computed user field to each state in B-Y, and make it a synthesized variable substituting the user field on the state every get / set. This is very boilerplate-heavy, and requires all of the synthesized get/set made in A, bloating it with unrelated, repetitive logic. Worse, if views B - Y are designed to be used independently, which they probably should be (composable architecture and all that), they have to repeat the work for all child states should they create their own state, leading to quadratic growth in code size if something like sourcery is used (lol). This is the approach that the shared-state example shown in the TCA examples.
• Stuff it in environment statically. This leads to a vaguely acceptable solution (little boilerplate, injected into any child who requires it, any concerned reducer can listen for updates), but we lose the nice state update debug view on user property changes. There will also be other problems in the future: the user should philosophically be part of the state and only API calls to update it from the server should be part of the environment, making it part of the environment could lead to further issues down the road.
• Stuff it in the environment dynamically, from this discussion. The idea here is that only A has the state and adds the User state as a dynamic dependency for each reducer under it. Those reducers hydrate off of that User, which has an objectWillChange async sequence for Z to update its user off of. This seems like the most promising approach but I'd like some confirmation that dependencies (among other things) would work in such a configuration - I'm new to this architecture and there could just be something that I'm missing.

At its core, the problem is a composable child referring to the state of its parent, something hidden by the 'one giant state' redux solutions. I was kicking around the idea of a rust-style Cow construct that could be passed in, where an independent view could use an owned User state (for instance, SwiftUI previews) while a child view could use a borrowed User state, and this state could be passed through the view hierarchy implicitly somehow, but I could only find the above as actually practical solutions.

If anyone has any idea how to make globally visible state, let me know!

[fabstu]

I'm not that experienced, but would passing through a non-scoped store besides the scoped one solve the problem?

[JackYoustra]

Interesting idea! You'd probably lose some easy composability and there's no dynamic environment passthrough, but it is fairly robust and only a limited amount of boilerplate. I'll probably try it out. Do you have any experience using this pattern?

[fabstu]

Only very limited, no.

I used it once to start global actions from within a recursive view structure. It just came from my frustration of needing an action to pass through a 10-deep reducer chain, just to reach the root view, where I'd otherwise have to unpack the action. -> used .stateless before converting it to a view store.

But I hope you can share yours :)

[JackYoustra]

So I've got a few code examples this time

Here's a basic view of the user dependency I was talking about:

// Difference: https://gcc.godbolt.org/z/sb9TWMq5Y

public typealias User = Int

public struct A {
    var a: User
    var b: B
}

struct B {
    var c: C
}

struct C {
    // Injected
    var a: User
    var r: String
}

public func test(_ arg: A) -> User {
    var a = arg
    a.b.c.a = 1
    return a.b.c.a
}

public func test2(_ arg: A) -> User {
    var a = arg
    a.a = 1
    return a.b.c.a
}

Here, test and test2 don't return the same thing, as they should with a single copy of User state. There's two solutions I came up with:

a manual injection method, which is really verbose and would probably need codegen in order to scale

public typealias User = Int

public struct A {
    struct Origin {
        var a: User
        var b: B.Origin
    }

    struct Environment {}

    var origin: Origin
    var environment: Environment
    
    var b: B {
        get {
            B(origin: origin.b, environment: B.Environment(c: C.Environment(a: origin.a)))
        }
        set {
            origin.b = newValue.origin
            origin.a = newValue.environment.c.a
        }
    }
}

struct B {
    // Holds non-dependent data
    struct Origin {
        var originC: C.Origin        
    }

    struct Environment {
        var c: C.Environment
    }

    var origin: Origin
    var environment: Environment

    var c: C {
        get {
            C(origin: origin.originC, environment: environment.c)
        }
        set {
            environment.c = newValue.environment
            origin.originC = newValue.origin
        }
    }
}

struct C {
    struct Origin {
        var r: String
    }

    struct Environment {
        var a: User
    }

    var origin: Origin
    var environment: Environment

    var a: User {
        get {
            environment.a
        }
        set {
            environment.a = newValue
        }
    }
}


public func test(_ arg: A) -> User {
    var a = arg
    a.b.c.a = 1
    return a.b.c.a
}

And a reference method that breaks our nice copy semantics, but is vastly less code and is much easier to read without codegen.

public typealias User = Int

class Rc<T> {
    var value: T
    init(_ value: T) {
        self.value = value
    }
}

public struct A {
    private(set) var a: Rc<User>
    var b: B

    init(a: Rc<User>, b: B) {
        self.a = a
        self.b = b
        self.b.c.a = a
    }

    // Problem: lose top-level copyability - User will be duplicated
    // If we could run this code on a clone, the copy semantics would be upheld
    mutating func copyInternal() {
        self.a = Rc(self.a.value)
        self.b.c.a = self.a
    }
}

struct B {
    var c: C
}

struct C {
    // Injected
    var a: Rc<User>
    var r: String
}

public func test(_ arg: A) -> User {
    var a = arg
    a.b.c.a = 1
    return a.b.c.a
}

public func test2(_ arg: A) -> User {
    var a = arg
    a.a = 1
    return a.b.c.a
}

Checking on godbolt shows them to be similar generated code sizes with the compiler able to infer the result of the explicit struct implementation, albeit this is a toy problem so who knows about more complex problems.

Please let me know what you think!

[JackYoustra]

Thanks for the reply!
Yeah, I was worried about that, but my reasoning is going for codegen is too big for now, especially when the framework probably gets some easy first class way to solve this problem and I have to go back and replace the custom solution. Do you think it'd be workable enough to just do reference for a while and wait for your PR, or should I lean towards my extensive codegen solution?

[JackYoustra]

also, what problems exist with observation / reducer stuff?

[tgrapperon]

There is an implicit contract in TCA: the state should only be mutated during a reduce function. Mutating the state outside of these functions is impossible with value types, but it can happen with reference types, and nothing was made in the library to handle this case. It also prevent observer to spot the mutations occurring inside it.

So reference types are OK if all their stored properties are constant. In other words, they can only be set by the parent which is the most upstream. Updating nested child properties like you did is possible, but it doesn't scale well.

My advice is to use manual injection when two connected features are sharing and using the same value, and switch to the environment if there is a run of features that is not using it. It also usually means that you will need to model your value in the leaf feature as an Optional (you don't have a value until the reducer runs at least once), which can be cumbersome sometimes.

If you need to modify the value from a child that received it through a dependency, it gets more complicated, You can send an action that you catch upstream to perform the change at the level where you inject the value into the environment. Unfortunately, this doesn't scale well as you need to bookkeep this as you add new features mutating this value. Furthermore, because the mutation will occur upstream because you sent an action, there will be a small hop and your mutation will effectively be async from the leaf feature's point of view.

We unfortunately don't have a pure async/await version of CurrentValueSubject, but if you decide to rely on Combine, you can also send a subject in a dependency and use it as a bidirectional link between your features, with the condition that each feature accessing the published value need to do it by subscribing to the subject (as any Publisher dependency) to save a copy of the value in their respective state. It has the same limits as above, but it should scales more nicely.

[JackYoustra]

I was thinking about the subscription updating method, where the publisher is exposed via an injected dependency, but that seems like it'll saturate the event queue - imagine a list that needs access to shared state, and I wasn't sure how to get around that.

Also, what do you think about the computed property solution? Any problem you see with it besides lots of code?

[tgrapperon]

but that seems like it'll saturate the event queue

While it's possible, it would require a substantial traffic. I depends on the number of subscribers alive. It's really on a case by case basis.

what do you think about the computed property solution

This is what I'm using personally, as my features are usually quite intertwined. This approach provides the strongest coupling. It works well as long as you don't have to jump into a collection. This is what led me to the "lazy" experiment in #1227. I have other ideas to attack this problem, but I currently lack the time to explore them.