Are consumers expected to cache sizing strategies?

[JosephDuffy]

CollectionFlowLayoutHandler.sizeForItem(at:suggested:metrics:environment:)'s default implementation calls sizingStrategy(at:metrics:environment:), which returns a CollectionFlowLayoutSizingStrategy.

Within CollectionFlowLayoutSizingStrategy the sizes are cached, but when a new instance is returned the cache is discarded.

Looking at the demo app and the documentation on the API it's easy to assume that the implementer need only return a value and Composed will do the rest, but it looks like the implementer should be caching this value. Caching this would require some hacks if adding CollectionFlowLayoutHandler conformance outside of the module, and is even a bit janky when done in a different file in the same module.

Is the intention for implementers to cache this, or should this be something Composed handles? @shaps80

---

Yes, they are

This could be made clearer in the API by changing the name (e.g. to cachedSizingStrategy(at:metrics:environment:)) and updating the demo app to cache the object.

In the future it may be possible for Composed to cache this value when diffing is supported.

[shaps80]

Yeah consumers should although I never found a nice way to infer this from a design POV. Maybe needs a lot better name?

The issue is that it would be very difficult (perhaps impossible) to invalidate correctly from a framework POV.

Any thoughts on improvements welcome.

[JosephDuffy]

Adding this to the demo might help a little since it's the main place to see a full implementation.

It's not great but even adding cached to the name (e.g. cachedSizingStrategy(at:metrics:environment:)) could help make it clearer.

If diffing support were adding it might also add identification, which could be used for caching at a minimum the sizes.

[shaps80]

That's a good point. Ok let's take this issue as an open task. Would you mind just updating the description to include those high level steps. That way anyone can take on the ticket.