Why is the UserDefaults clients "set" methods marked async?

[Sajjon]

Why is the UserDefaults live client's set methods async?

@tgrapperon 's swift-dependency-additions package ships a UserDefaults dependency which set method is not async

[stephencelis]

The decision is really up to you and your team, but @mbrandonw and I like to treat dependencies that read from the outside world different from dependencies that write to the outside world.

Dependencies that read (like the current date, a UUID, a random number, even getting a value from the user defaults) we feel are fine to access from a synchronous context and aren't going to do anything surprising, and we think it's not worth forcing them into async, since that would require another action to feed the data back into the system, and that would introduce a lot of indirection and boilerplate for something that should be simple. The exception for marking a read-only dependency async is when it's a heavyweight operation that should not block the main thread.

Dependencies that write (like saving a file or setting a value on user defaults) we like to quarantine to an async context even if the underlying operation is synchronous and fast. This prevents you from invoking the dependency from the middle of a reducer's state update and instead forces you to open up an effect to do your work. This means effects that do something are all handled in a consistent way.

[tgrapperon]

And a quick comment about UserDefaultsDependency from swift-dependency-additions: the dependency is sync because Apple's built-in UserDefaults offers a sync API only, but it writes to disk asynchronously using a private queue. In an ideal world, I would have preferred to have an async variant for this dependency but it wasn't just possible to provide any meaningful one, and I opted to offer the same API that Apple does.

[stephencelis]

We agree with @tgrapperon that keeping library APIs as close to the original as possible is a good goal to have and can help avoid bike shedding and decision making 😄

It's also always easier to explore patterns and tweak more general library code for your app domain, as we do in isowords.