Shared state with persistence and default values

[lukeredpath]

After finally playing around with the shared state beta, one thing I found inconvenient was having to provide a default value everywhere when using a persistence strategy. It felt like it should be possible to define a default value once, when defining the persistence key.

I had a go at implementing this myself:
shared-state-beta...lukeredpath:swift-composable-architecture:lukeredpath/default-providing-key

This branch adds a new generic persistence key, DefaultValueProviding<Key> that effectively decorates any other Sendable and Hashable conforming persistence key but also holds onto a default value - one caveat is that the Value type itself must be Hashable and Sendable in order for the wrapper key to conform to these protocols.

As an example I've provided a single convenience method for creating an inMemory key with a default value - other conveniences could be added for other key types.

A single new overload on ValueReference provides a way to initialise a persisted shared state where it will fall back to the default value if nothing is currently persisted:

struct User: Hashable, Sendable {
  let id: UUID
  let name: String
}

extension User {
  static let placeholder = User(id: UUID(0), name: "")
}

extension PersistenceKey where Self == DefaultValueProviding<InMemoryKey<User>> {
    static var user: Self {
        inMemory("user", defaultValue: .placeholder)
    }
}

@Reducer
struct LoggedIn {
  struct State: Equatable {
    @Shared(.user) var user
  }
}

Would this be a useful addition? Because it requires the additional overload on ValueReference I'm not sure it could be implemented in your own codebase.

[lukeredpath]

I've uploaded an example app that demonstrates a basic login/logout system where initialising a new logged in state every time a user logs in resets the shared user state. It demonstrates the use of a default-providing key.

https://gist.github.com/lukeredpath/2bf827a04a7d25b8482ff475c24ea5ec

Thinking more about the logged in only shared state use case, I think one last useful feature would be to have some kind of way of defining a key where default value access triggers a purple warning, for use cases where its only there to satisfy the compiler where you want a non-optional value that should only be available in certain runtime situations, e.g. the user is logged in. Perhaps if the DefaultProvidingKey took a closure instead of a value, the user could provide a closure that uses XCTFail, but that would make it tricky to conform to Hashable and Sendable.

Another useful thing would be an API for clearing persisted shared state - e.g. when a user logs out, you clear the persisted value so any further access of the shared state before the user logs back in would access the default value and once again trigger the purple warning.

[lukeredpath]

The closure idea was a non-starter, but a single parameter can control some runtime warning behaviour:
3870645

But without a way to somehow reset the shared reference value, this will only help you if you access the default value before a real value has been initialised. I'm not sure how to approach resetting the reference and maybe its not really necessary.

[jgoodrick]

I enthusiastically second this. I tried to implement something like it as a static extension on the Shared type, but couldn't figure it out. Decorating the PersistenceKey makes a lot of sense to me.

[lukeredpath]

I'm happy to turn this into a proper PR with additional helpers and tests if others think this would be useful. @mbrandonw would you be happy to review a PR on this into the observable-state-beta branch?

[mbrandonw]

Hi @lukeredpath, both Stephen and I have been traveling this past week and so we have a growing agenda of things to look into once we are both settled again. We will look into this soon.

[lukeredpath]

Thanks, I'll wait then.