[Experiment] "Lazy" forEach pullbacks and stores

[tgrapperon]

Hello,

Here is another experiment, this time, around lazy pullbacks/derivations for collections of features.

This aims to solve a performance issue when deriving states from collections.
Using computed properties to pass a common value to an IdentifiedArray of features is indeed limited by the size of the array, as a complete array is requested by forEach pullbacks, even if it's only to update a single element. We can make sure that the IdentifiedArray is a stored property in good shape at any time, but it requires some careful supervision by a third party reducer to propagate and bake the changes (that could come from very far upstream in the hierarchy), and there are probably models where this is not achievable anyway.

In this experiment, I propose a protocol called LazyCollectionConversion, and two witnesses: LazyIdentifiedArrayConversion and LazyDictionaryConversion where you define how an identified element/value is modified when extracted from the parent. You only need to specify the modifications, as extraction/update of elements of the array/dictionary is automatic.

I've updated the case studies with an example that shows the performance difference between a lazy and an eager approach.

If Item is a child state with the form:

struct Item: Identifiable {
  var id: String
  var value: Int
  var parentColor: Color
}

and Parent the parent feature with the form:

struct Parent {
  var color: Color
  var items: IdentifiedArrayOf<Item>
}

We can define a lazy Parent/Item conversion like:

extension Parent {
  static let lazyItem = LazyIdentifiedArrayConversion(\Self.items) {
    `self`, id, item in 
      item.parentColor = self.color
    }
  )
}

In the parent's reducer, you then use:

itemReducer.forEachLazy(ParentState.lazyItem, action:/ParentAction.item,…)

And in the ParentView:

ForEachLazyStore(
  store,
  conversion: ParentState.lazyItem,
  action: ParentAction.item,
  content: ItemView.init(store:)
)

That's it!
There are some sharp edges of course. Because this is lazy, you don't have a guarantee over the current values at any time in the collection and you should probably avoid touching them without precautions. I'm working on a larger project that unifies all state derivation into a common pattern, and prevents this kind of issue, but it still needs some work.

The whole feature is gathered into one file and doesn't use internal API's, so you can transplant it easily into your projects it you want to give it a spin.

I'm wondering if this feature alone could be implemented/named in a neater way, or deeper into the library. I'm using "conversion" because of swift-parsing, but we could probably use "extraction" or "derivation" for example (albeit I have other works where this term has another meaning).

What do you think about it?

[tgrapperon]

For some reason, the lazy case is not working well with Previews, so I'm maybe doing something wrong somewhere. It runs fine on a device/simulator, or if I lower the number of Items.

[tgrapperon]

I've slightly updated the API into something closer to the existing forEach: the conversion is now ideally defined as a value property instead of static one, and one uses a KeyPath (or a function from the Parent type) to refer to it:

// In the state:
extension Parent {
  let lazyItem = LazyIdentifiedArrayConversion(\Self.items) {
    `self`, id, item in 
      item.parentColor = self.color
    }
  )
}

// In the reducer:
itemReducer.forEachLazy(state: \.lazyItem, action: /ParentAction.item, …)

// In the view:
ForEachLazyStore(
  store,
  state: \.lazyItem,
  action: ParentAction.item,
  content: ItemView.init(store:)
)

This is slightly less efficient than the previous approach where we directly passed the conversion value, but switching from a standard API to a lazy one is now simpler. The conversion then breaks automatic equatability of the State, but I think this is probably a good thing, as you would likely use a ViewState for features like this. As an alternative, you can define it as a static variable or as a computed property.

[JackYoustra]

Yeah, this seems like the only efficient way to go about computed collections.
You mentioned a larger project to unify all of these together - would you like any help with that?