Reusability hint to improve reuse performance when composite components are present.

[andersio]

The purpose of this change is pretty much summed up in the documentation for Renderable.makeReusabilityHint(using:).

The design is inspired by how Hashable handles nested hashing.

Do also note that implementing makeReusabilityHint(using:) does not imply that a composite component no longer needs to handle type mismatch in view hierarchy.

[sergdort]

Does it scan it through the hierarchy? e.g C(children: [C(children: [A()], B()]) vs C(children: [C(children: [B()], A()])?

[andersio]

It doesn’t do so automatically. When you say combiner.combine(child), A’s part of the call it would eventually invoke makeReusabilityHint(using:) on the child. So as long as you combine every child using the combiner, and that all descendants implement this, the whole hierarchy would be walked over.

This can be made less crumblesome if we have a protocol for composite component e.g. CompositeRenderable which is also useful for auto propagation of messages like *LifecycleAware. But this can be done after this PR which lays the cornerstone.

[sergdort]

This should not usually happen, should it?

[andersio]

All visible items hit this path when the state changes.

[sergdort]

I mean oldComponent.reusabilityHintCombiner.isCompatible(with: component.reusabilityHintCombiner) to be false. As it'f false it means that we are recreating the view, right?

[andersio]

yeh

[andersio]

I actually realise when answering Sergey’s questions about walking the hierarchy, that we need to generate the reuse identifier with not only , but brackets that indicate containment. Otherwise, A([A([B(), C()])]) would resolve to the same symbol as A([A(), B(), C()]) which has a rather different view hierarchy.

That’s also reiterate the value of closing off custom reuseIdentifier, because who knows what surprises you could have when you have components from different authors. 👻

[andersio]

Need to think about how this should integrate with #162.