Make Shared state default value initialization lazy via @autoclosure.

[bscothern]

Right at the end of the beta I started using the Shared features to do some development and had the idea of modifying @Shared's default value to be captured via @autoclosure so it can lazily be created if there is no shared instance found rather than eagerly being made every time and then discarded when @Shared finds the existing instance of the value.

I have already put together a branch that does this with some tests to ensure it is lazy over in my own fork and it seems to work well from my bit of testing.

Here is my original comment about it in the beta discussion.

[stephencelis]

Hi @bscothern! Thanks for starting the discussion. I actually had this as an autoclosure earlier in the beta, but decided to scrap the complexity later on. While laziness could theoretically be helpful here, it does seem to go against the norm in Apple's APIs, for example @State and @AppStorage evaluate their defaults eagerly (@StateObject is an outlier, but it also takes a heavier class type that is more likely to do work on initialization).

That said we're open to discussing the change, we'd just like to figure out if it can be motivated in a more real world fashion. What kinds of things does the @autoclosure help fix, where can it go wrong, etc.?

[seanmrich]

I'll weigh in with my experience on this. I have a couple shared values that are persisted using FileStorageKey. As an example, one is a folder hierarchy that contains an array of subfolders and app-specific values. On first launch, a default set of folders are created.

extension PersistenceKey where Self == PersistenceKeyDefault<FileStorageKey<Folder>> {
  public static var rootFolder: Self {
    PersistenceKeyDefault(
      .fileStorage(.documentsDirectory.appendingPathComponent("rootFolder", conformingTo: .json)), 
      .install
    )
  }
}

Generating Folder.install each time a feature state is created that declares the @Shared(.rootFolder) isn't a huge deal, but it isn't nothing either. This is especially true since I believe declaring @Shared(.rootFolder) as a local function variable would also regenerate that default value. The bigger issue for me is in testing. Let's say I want to test using an empty initial rootFolder:

func testAddFolder() async {
  await withDependencies {
    $0.uuid = .incrementing
  } operation: {
    @Shared(.rootFolder) var root = Folder()
    let store = TestStore(
      initialState: Feature.State(),
      reducer: { Feature() }
    )
    await store.send(.addFolderButtonTapped) {
      $0.root.subfolders = [
        Folder(id: UUID(???))
      ]
    }
  }
}

Because Folder.install creates a set of initial Folders, the next uuid for the addFolderButtonTapped is unknown. I could run the test, see what uuid is created, and update the test with that value. But that makes the test pretty fragile based on the number of folders created by Folder.install.

Using @autoclosure would give me more control during testing and prevent a bunch of unnecessary work.

[stephencelis]

@seanmrich This all seems reasonable to us, thanks for writing it up! Would you be interested in submitting a PR with those changes?

[seanmrich]

I created the pull request for PersistenceKeyDefault to lazily evaluate defaultValue.

If this seems like a reasonable approach to you guys, the idea could be extended to the initialValue as well. Since that value also isn't used unless load fails, it could be lazily evaluated. This is a much more extensive change, though, since references to the initialValue are much more ubiquitous.

[seanmrich]

Because Shared initial values are eagerly evaluated, solving the default value problem didn't fully solve my issue with testing. There are still side effects when the Shared initializer calls load. Luckily, extending the lazy evaluation to initial values wasn't so hard as I thought. I created a new PR #3060 that resolves the issue.