Replies: 1 comment 1 reply
-
|
Sharing comes with tools for explicitly deriving non-optional shared values from optional ones: if let sharedUser = SharedReader($currentUser) {
// 'sharedUser' is 'SharedReader<User>'
}Does this help with your use case? |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Let me first give a little bit of context of what we are trying to achieve. We have an application where a user can authenticate themselves. Once authenticated, the user is shared across the App using a
FileStorageKey. The type isOptional<User>, wherenilrepresents the unauthenticated state.All features in the app except for the login screen require a user to be present. One solution leveraging existing tools from
swift-sharingis to use theShared(_:)initialiser that unwraps an optional shareable and pass the unwrappedSharedto the child features requiring a user.This means though, that we need to inject the user from the top-most view down to each feature.
Ultimatively, what we'd like to have is a
SharedReaderKey<User>that allows a child feature at any level to read the current user.Our first approach was to write a new shared key that reads from the same underlying storage. In general, this works fine until the user logs out. I assume that before our root view removes the child features from the view hierarchy, the child features
@Shared(.user)is notified of the underlying persistence layer change and tries to decode the nownilvalue.As expected, it raises a
.valueNotFounderror.FileStorageKey.Default
Then, we tried to create a custom persistence key.
UnwrappedSharingKey
Now, while this works when running on device or in the simulator, it does not work correctly in Xcode Previews. Setting an initial value for the underlying shared key does not get forwarded to the
UnwrappedSharingKeysomehow. I need to explicitly update the state usingwithLockin a#Previewmacro.My question is if there is something inherently wrong with our implementation of a
UnwrappedSharingKeyor if this is a bad idea overall and if you'd suggest to pass down theSharedReaderfrom the root feature.Or, if there is another option that we have overlooked which would give us the desired ergonomics working with optional shared state.
Any pointer is much apprechiated!
Thanks,
Maurício
Beta Was this translation helpful? Give feedback.
All reactions