Add support for Codable types to AppStorageKey

[abdulilah99]

I understand you’ve previously noted that Codable support is debatable, but adding it could significantly broaden the library’s range of use cases, I hope that makes it an appealing prospect for you.

[stephencelis]

@abdulilah99 Thanks for the nudge! We've let this sit long enough that we think support is probably worth the trade-offs. I'm going to merge as-is but will add some follow up documentation about the caveats.

[pyrtsa]

I'm a bit concerned about this change. There are so many .appStorage("foo") overloads now, that from the call site, it may not be clear whether the value is persisted as JSON-serialised Data or one of the native types. 🤔

I think it would be less magical, for example, if key was a labelled parameter such as .appStorage(json: "foo") or .appStorage(codable: "foo") (just spitballing here).

[stephencelis]

@pyrtsa We considered that but don't think it's a problem in practice, and we have plenty of tests showing that it does the right thing with more primitive types. We also couldn't come up with an example of things going wrong. @AppStorage is almost always going to be used in a concrete way where the appropriate overload will be resolved.

The one place where this might not be the case is if someone writes a wrapper around @AppStorage that only implements Codable support and then tries to access a value as a primitive using @AppStorage. Such an edge case seems more like a programmer error than anything else.

[pyrtsa]

@stephencelis But primitive types are only part of the picture. With #107, it's not just primitive types but [String] too which, going via stringArray(forKey:), is just a special case of array(forKey:). Why does [String] go that way but [Int] turns into a JSON-serialised Data instead?

Also, there's no way to customise the JSONEncoder and JSONDecoder that get used. One might want to store Dates in a special way, for instance, but there's no way to change the dateEncodingStrategy. Nor is there a way to use another serialisation than JSON.

My worry is partly about the library painting itself into a corner here. Something that's completely avoidable with just a little bit more qualification to keep structured types isolated from the primitive types supported by AppStorage.

[stephencelis]

But primitive types are only part of the picture. With #107, it's not just primitive types but [String] too which, going via stringArray(forKey:), is just a special case of array(forKey:). Why does [String] go that way but [Int] turns into a JSON-serialised Data instead?

Because UserDefaults special-cases the same API, and it'll be slightly more performant than going through Codable machinery.

Also, there's no way to customise the JSONEncoder and JSONDecoder that get used. One might want to store Dates in a special way, for instance, but there's no way to change the dateEncodingStrategy. Nor is there a way to use another serialisation than JSON.

I think both of these issues could be addressed the same way they are addressed in fileStorage. It'll just require some time to PR for folks that need it.

My worry is partly about the library painting itself into a corner here. Something that's completely avoidable with just a little bit more qualification to keep structured types isolated from the primitive types supported by AppStorage.

Can you qualify this worry a bit more with examples? I think the issues you brought up above are all addressable.