What is the best ergonomics for an Optional @Shared state?

[cabeca]

Hello,

While considering the use of this library, I always get lost in a particular use case.

Let's say that I have an API client for dealing with a certain product the user might have. There are endpoints for listing the Products the client has, as well as endpoints to get a single product via ProductId and subscriptions for receiving updates to that single product. Let's say that I'm using the @Dependency library to have a complete ProductClient struct with all these endpoints.

Now, the user can choose a product from a list on screen, and if he does, a sheet is presented with a detail view of the product. This view might be super complex and be composed of many other views, but it is crucial that all views are kept up to date with the latest Product state. Sub views can also call api endpoints to change the state of the product. Pretty standard stuff.

My question here is: what would be the best use of @Shared here for the optional currently selected product? Would it be:

• @Shared(.inMemory("currentProduct")) var currentProduct: Product? = nil
• @Shared(.product(productId)) var product: Product = ????

If using an optional currentProduct, you have to handle optionals everywhere, in a way that is avoided in traditional approaches, if you require non optionals to initialize your models.

If you define your own .product "persistence strategy" to use the api endpoints to get product by Id and use subscriptions to keep it up to date, how do you pass the productId into the @Shared declaration? Does it mean the init dance to assign to _product everywhere? And what do we put as the default value in this case?

Any pointers in the right direction would be much appreciated.

[seanmrich]

I've wrestled with the same question when using the library for database observation. Fetching collections of items is ok because an easy default is an empty collection. Fetching a single item is tougher, though, since you don't have an identifier to use as the default. I've been using nil as the default for those cases and providing ContentUnavailable views if the property isn't populated. I've tried to look at it as a positive because it forces me to deal with the idea that an identifier might become invalid (e.g. deleted from the database or removed from a server-provided list of products in your case). I also throw some kind of "record not found" error when the provided identifier is invalid and show an error indication to the user since this is probably unexpected.

If you're using that shared value in a bunch of places, maybe you could extract a non-optional Shared value in a parent feature and pass it to child features? It means injecting the value into the children which isn't convenient, but it would save you the effort of unwrapping if that's something you have to do a lot.

[mbrandonw]

Hi @cabeca, to summarize your use case, you have a list of products, the user taps one to bring up a sheet, and from that point forward you want to have some kind of Shared<Product> (though most likely SharedReader<Product>) that loads the freshest product data from the API and subscribes to changes so that the API can push the newest data to the client. Is that about right?

In that case it seems quite easy to avoid an optional. You would first design a SharedReaderKey that is capable of loading a product from an ID and subscribing to changes from the API. Then your "product detail" feature would hold onto @SharedReader like so:

@Observable class ProductDetailModel { // Could also be a View
  @SharedReader var product: Product
  // ...
}

Notice that we are not using the key directly with @SharedReader here. We can't do that because its value is dynamic, depending on the product ID. So, it has no choice but to be initialized in the init of the model. It's worth noting this is what one has to do with dynamic @Querys in Swift Data too.

So, you can add an initializer to ProductDetailModel, and you can have this initializer take a full Product because you have access to such a value in your list:

init(product: Product) {
  _product = SharedReader(wrappedValue: product, .product(id: product.id))
  // ...
}

Now the product value will use the Product that was displayed in the list as the default, but it will also immediately fetch the newest value from the API and subscribe to future changes.

And then in the list feature you can construct this model by passing along the product:

func tapped(product: Product) {
  let model = ProductDetailModel(product: product)
  // ...
}

That's the basics.

[cabeca]

Thank you both for your responses. I now have a better understanding of how to use these tools.