You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
structSuperview:View{@Storevarobject:StoreTypevarbody:someView{Subview(object:self._object)}}structSubview:View{@Storevarobject:StoreTypeinit(object:Store<StoreType>){self._object = object
// then, property access must be done as either
self.object.someThing
// or
object.wrappedValue.someThing
}varbody:someView{
// ...
}}
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.
The text was updated successfully, but these errors were encountered:
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:
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.
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?
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.
Checklist
Request
When sharing an
@Store
object from a view to its subview, this is legal with an implicit initializer: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: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
.The text was updated successfully, but these errors were encountered: