Motivated by the conventions suggested for AIO-s, but thinking we still have a couple of weaknesses in that approach. I looked into how to make a few improvements that we felt important for our work.
We wanted, in particular, an approach allowing:
- Nesting or “compos-ability” - being able to nest components within components, several levels down
- Address-ability - within callbacks, being able to access or refer to the properties of components within components, several levels down (in practice, most likely only the immediate or second level down will be necessary).
- Scalability - from the coding perspective at least, achieve a coding style allowing brevity and clarity. Best if execution performance is not severely degraded.
I came up with a variation on AIO-s. For the moment I’m calling them “Compound Components”, if only for the purpose of distinguishing them from AIO-s in any discussion.
The variation is minimal, mainly consisting of using concatenated strings for the component IDs.
The thing is that with that simple change I believe we achieve all the above additional advantages. Plus I believe we keep all the nice properties of AIO-s, like allowing the “packaging”, publication and sharing of components in the community, with a consistent interface.
You can check out a full, yet brief example here.
I am clear we get nesting and address-ability and believe scalability as well. I believe this approach should not reduce callback performance when compared to achieving the same layout without nested components. But I don’t know enough about performance related to callback string IDs. I will appreciate comments from the community in regards to this aspect.
At our team, we’re not planning to scale this up to many dozens of components or nesting them too deep, so it seems this should work for us fairly well. I hope others will also find this approach useful.