Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document best practices for shared stores #61

Open
1 task done
bbrk24 opened this issue Nov 3, 2022 · 5 comments
Open
1 task done

Document best practices for shared stores #61

bbrk24 opened this issue Nov 3, 2022 · 5 comments
Labels
documentation Improvements or additions to documentation enhancement New feature or request
Milestone

Comments

@bbrk24
Copy link
Contributor

bbrk24 commented Nov 3, 2022

Checklist

Request

When sharing an @Store object from a view to its subview, this is legal with an implicit initializer:

struct Superview: View {
    @Store var object: StoreType

    var body: some View {
        Subview(object: self.object)
    }
}

struct Subview: View {
    @Store var object: StoreType

    var body: some View {
        // ...
    }
}

but it's not clear from the documentation whether this is good practice or not. Furthermore, this becomes more complicated with an explicit initializer, since Store.wrappedValue is get-only:

struct Superview: View {
    @Store var object: StoreType

    var body: some View {
        Subview(object: self._object)
    }
}

struct Subview: View {
    @Store var object: StoreType

    init(object: Store<StoreType>) {
        self._object = object

        // then, property access must be done as either
        self.object.someThing
        // or
        object.wrappedValue.someThing
    }

    var body: some View {
        // ...
    }
}

In some cases, it may not be necessary for them to both be @Store, but this prevents both views from accessing the projected value $object.

@bbrk24 bbrk24 added documentation Improvements or additions to documentation enhancement New feature or request labels Nov 3, 2022
@bbrk24
Copy link
Contributor Author

bbrk24 commented Nov 3, 2022

While it does work with both of them marked @Store, I don't think that's something we should encourage. Perhaps we should add a property wrapper like @SuperviewStore, which can be constructed from Store.projectedValue -- so as to mirror @State and @Binding:

struct Superview: View {
    @State var state: Int
    @Store var store: ObjectType

    var body: some View {
        Subview(state: $state, store: $store)
    }
}

struct Subview: View {
    @Binding var state: Int
    @SuperviewStore var store: ObjectType

    init(state: Binding<Int>, store: Store<ObjectType>.Wrapper) {
        self._state = state
        self._store = .init(store)
    }

    var body: some View {
        // ...
    }
}

@wboyd600 What do you think?

@bbrk24
Copy link
Contributor Author

bbrk24 commented Nov 4, 2022

Upon further thought, we may be able to make Store.Wrapper itself a property wrapper, and then either rename it or provide a typealias so that it can be spelled @SuperviewStore (though I'm open to suggestions) rather than @Store.Wrapper.

@wboyd600
Copy link
Contributor

Hey, sorry for the late reply -- I'm really not sure. I might be missing the bulk of the issue -- but it seems like @Binding and @State are different property wrappers because they actually do different things. Would @SuperviewStore actually behave differently, or just have a different initializer?

@bbrk24
Copy link
Contributor Author

bbrk24 commented Nov 16, 2022

Coming back to this later, I don't think there actually would need to be a difference. After all, Binding still conforms to DynamicProperty. Binding only needs to be different because the value type can only live in one place (the place marked @State). @Store wraps a reference type, so it can be used in multiple views at once.

TL;DR: There doesn't actually need to be @SuperviewStore or similar.

@wboyd600
Copy link
Contributor

Okay, so we're really just looking at adding another initializer to @Store.

@wboyd600 wboyd600 added this to the Backlog milestone Nov 28, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants