Add support for preferences, @StateObject, @EnvironmentObject, and custom DynamicProperty types

[carson-katri]

The following are now supported in the Fiber reconciler:

• Preferences
  • To support preferences keys, I made the ReconcilePass always start at the root of the view hierarchy (not just when dynamic layout is enabled), but it still only looks for changes once it reaches the first changed fiber.
• @StateObject/@ObservedObject
• @EnvironmentObject
• @AppStorage/@SceneStorage
• Custom DynamicProperty types

Currently, backgroundPreferenceValue does not correctly access the preference values. overlayPreferenceValue works because the overlay is evaluated after the underlying content. To fix backgroundPreferenceValue we could evaluate the background after the foreground and set the z-index to put it underneath.

A new internal API for testing the FiberReconciler using TestFiberRenderer was also added when creating tests for the new dynamic properties:

struct TestView: View {
  @State private var count = 0

  var body: some View {
    Button(action: { count += 1 }) {
      Text("\(count)")
        .identified(by: "count") // Use `identified(by:)` to mark views for later retrieval.
    }
    .identified(by: "increment")
  }
}

// Setup a reconciler for `TestView`.
let reconciler = TestFiberRenderer(.root, size: .zero).render(TestView())

// Get a proxy to a View with the id "count".
let count = reconciler.findView(id: "count", as: Text.self)
let increment = reconciler.findView(id: "increment", as: Button<Text>.self)

// Access `.view` to resolve the current content of the fiber.
XCTAssertEqual(count.view, Text("0"))

// Use dynamic member lookup to access properties.
increment.action?()

// Make sure the state changed. `view` is computed when accessed, so it can be used across reconcile passes (despite `current`/`alternate` swaps).
XCTAssertEqual(count.view, Text("1"))

[carson-katri]

carton test builds correctly on my local machine, so not sure why it isn't excluding the Dispatch stuff on CI...

[MaxDesiatov]

Can we guarantee that ObjectIdentifier(self).debugDescription.split(separator: "(") will always return at least two elements? Maybe we need to guard for that?

[carson-katri]

I just removed this from the description, since I was just using it to debug something. If you think I should keep the memory address though, using unsafeBitCast may be a better method?

[MaxDesiatov]

Not unless you found seeing memory addresses particularly useful during development 🙂

[MaxDesiatov]

Just had a super quick look, will review the rest of it by the end of this week.

[MaxDesiatov]

Overall seems legit, just some nits with requests for doc comments.

[MaxDesiatov]

Seems legit, thanks!