Investigate multiple layers of nested components

[adamghill]

Test for how well more than 2 layers of nesting works for components. There might be some edge cases that need to be figured out to make it work correctly.

[joshiggins]

Some ideas related to sharing data between nested components and changing state of parent or sibling components, highlighted in #265

self.parent and self.children seems intuitive at first for getting access to a nested component tree from inside the component, but actually its quite problematic dipping into another component and directly changing its state.
This will lead to components which are difficult to test, maintain and re-use

• there are multiple ways to do the same thing and no obvious choice
• state mutating code could be scattered around many components and have different effects depending on which and what order nested components are composed
• no real definition of what bits of the state are component-private and what bits can be changed by others and when

---

I would propose Unicorn adopts an approach using the template tag kwargs to define the interfaces for parent-child component communication in both directions:

Parent to child already works with the existing template tag kwargs for the parent to share some properties/state which the child can read but not directly change. We could make it more convenient to access these (e.g. in templates) without having to set a property for each kwarg in the child component.

Child to parent communication is facilitated by passing a method from the parent to the child through a kwarg also.
The child can call this method on the parent to manipulate the parent's state and thats it.
All code which can change the parent's state is contained within the parent component itself. The child component kwargs and the parent method signature form a definition, plus opportunity for validation.

This is the same principle as how React does it (where props are pretty much like our kwargs) and it works really well.

This implementation could have something like a call_component as suggested in discussion #88. Delegating it through something like this could also provide the necessary extension point to flag the parent component for re-rendering.

[joshiggins]

@adamghill what you think about this proposal? I can put some code to it if it sounds like a reasonable direction. Cheers

[adamghill]

Yeah, it seems like a great direction! I think I'm having a hard time conceptualizing how this would work in practice, but a PR which provides an ideal way for the current nested component example to work seems like a good approach. We could start with an example of how things should look from an API perspective and then figure out how to get it all working?

[tanssinet]

This this proceed?