Why is the defaultAppStorage dependency not always used in tests/previews?

[fruitcoder]

Hi and thanks for the great work on this library. I'm 99% on board with the design choices you made but while adding some convenience extensions for my usage I noticed that the defaultAppStorage is only used as a default when store isn't provided.

While that makes sense (I mean it's in the name) one of the main benefits of the library (encoding key, value type, store (standard/appGroup) and default value in a single type) contradicts with isolated testing/preview scopes. In my application I use a mix of app target only and shared app group user defaults so I always specify the store. This causes the propertyWrapper to always write in the corresponding persistent user defaults.

This simple setup demonstrates my problem

public enum Scope {
  public static var isFlagEnabled: AppStorageKey<Bool>.Default {
    // explicit store
    _SharedKeyDefault[.appStorage("isFlagEnabled", store: .standard), default: false]
    // implicit store (`defaultAppStorage` dependency)
    //	_SharedKeyDefault[.appStorage("isFlagEnabled", store: .standard), default: false]
    }
}

@Suite
struct SharedUserDefaultKeysTests {
  @Test("1. Set flag to true")
  func setFlagToTrue() {
    @Shared(Scope.isFlagEnabled) var isFlagEnabled

    #expect(isFlagEnabled == false, "Default value is `false`")

    $isFlagEnabled.withLock { $0 = true }

    #expect(isFlagEnabled == true, "Value was changed to `true`")
  }

  @Test("2. Expect default value to be `false`")
  func defaultValueIsFalse() {
    @Shared(Scope.isFlagEnabled) var isFlagEnabled

    #expect(isFlagEnabled == false, "Default value is `false`")
  }
} 

Running the tests in order fails the second test when using the explicit standard user defaults but succeeds when not specifying a store. I wanted to know the rationale for this (I've seen tests explicitly testing this to be the expected behavior). In my code I basically have wrapper functions that ensure the behavior I have for my tests and previews:

public enum UserDefaultsStore {
  case standard
  case appGroup(UserDefaults)

  var persistentStore: UserDefaults {
    @Dependency(\.context) var context
    @Dependency(\.defaultAppStorage) var defaultAppStorage

    switch context {
      case .live:
      switch self {
        case .standard:
          return .standard
        case let .appGroup(sharedDefaults):
          return sharedDefaults
        }
      default:
	return defaultAppStorage
      }
    }
}

public extension _SharedKeyDefault {
  static func appStorage(
    _ key: String,
    store: UserDefaultsStore,
    default value: @autoclosure @escaping @Sendable () -> Bool
  ) -> Self where Base == AppStorageKey<Bool> {
    .init(.appStorage(key, store: store.persistentStore), default: value())
  }

  init(_ key: Base, default value: @autoclosure @escaping @Sendable () -> Base.Value) {
    self = Self[key, default: value()]
  }
}

[stephencelis]

@fruitcoder If defaultAppStorage were used for every store in tests, then data could bleed over between stores that are otherwise unrelated in production.

If your application uses more than one store it should ideally control those additional stores with custom dependency keys. Take a look at how AppStorageKey uses @Dependency under the hood here:

swift-sharing/Sources/Sharing/SharedKeys/AppStorageKey.swift

Lines 256 to 259 in 8141fd7

	@Dependency(\.defaultAppStorage) var defaultStore
	self.lookup = lookup
	self.key = key
	let store = store ?? defaultStore

You could for example introduce a @Dependency(\.appGroupAppStorage) key to control this secondary store and then each store would remain independent in your tests.

[fruitcoder]

I just pasted the code in swift-sharing as well and while the test passes the first run it won't for subsequent runs because UserDefault.standard has been overwritten from that point on.

[stephencelis]

@fruitcoder If you command click or follow the debugger into this line:

public static var isFlagEnabled: AppStorageKey<Bool>.Default {
  _SharedKeyDefault[.appStorage("isFlagEnabled", store: .standard), default: false]
}

You'll see that it is bypassing your appStorage helper and going straight to UserDefaults.standard.

There appear to be 2 subtleties with this line.

1. Your custom appStorage helper requires a default parameter, but that parameter is being passed to _SharedKeyDefault:

    public static var isFlagEnabled: AppStorageKey<Bool>.Default {
   -  _SharedKeyDefault[.appStorage("isFlagEnabled", store: .standard), default: false]
   +  _SharedKeyDefault[.appStorage("isFlagEnabled", store: .standard, default: false)]
    }

2. Your custom appStorage helper is returning a default key directly, so you should call it directly from isFlagEnabled:

    public static var isFlagEnabled: AppStorageKey<Bool>.Default {
   -  _SharedKeyDefault[.appStorage("isFlagEnabled", store: .standard, default: false)]
   +  .appStorage("isFlagEnabled", store: .standard, default: false)
    }

After these changes the tests do use defaultAppStorage, though as mentioned earlier it should really use its own bucket like defaultAppGroupStorage.

And then you don't have to write a helper like this that can accidentally be bypassed, and instead use our machinery:

extension PersistenceKey where Self == AppStorageKey<Bool>.Default {
  public static var isFlagEnabled: Self {
    @Dependency(\.defaultAppGroupStorage) var store
    return Self[.appStorage("isFlagEnabled", store: store), default: false]
  }
}

[stephencelis]

Just as a follow up, I do think that your helpers trying to mimic our APIs obfuscated the problem, and a good way to troubleshoot new APIs is to give them unique names. I think these issues would have been more apparent then.

[fruitcoder]

Thanks for looking into this again. With my latest screenshot I wanted to show the "problem" I see without any of my custom extensions (which are to force a default value in a single place). I wouldn't want to change the way the library works but maybe some documentation might help folks who run into the same misunderstanding.

As soon as library users introduce a single shared user default value they might be confused as to why this isn't testable/working the same way of the box.

// a view, an observable model, etc.
@Shared(.appStorage("someFlag") var someFlag = false
@Shared(.appStorage("someFlag2") var someFlag2 = false
// ...
+  @Shared(.appStorage("someSharedFlag", store: .appGroup)) var someSharedFlag = false

They might have a bunch of tests in place that assert on the correct default values, user actions change the shared state to the expected value etc. Adding this shared flag seems to be as easy as providing a store instead of relying on the default one. So one would add tests in the same way as for the existing keys just to realize they will fail from the 2nd run onwards.

[stephencelis]

@fruitcoder Thanks for the feedback! The store parameter is an advanced feature of the library that was added later on, and users are expected to manage this injected dependency themselves.

If you have ideas for better APIs we are all ears, or if you have time to take your experience to help craft some better documentation or diagnostics, we'd really appreciate it!