Closed friendlymahi closed 1 year ago
@sharanyavinod , @niekraaijmakers , @CezCz - Hope you're doing well. Looking for your insights on this change. I am comfortable sending a PR if you believe the proposed fix makes sense.
:tada: This issue has been resolved in version 2.1.0 :tada:
The release is available on:
Your semantic-release bot :package::rocket:
Is your feature request related to a problem? Please describe. While refactoring our existing spa to support 2.0, we realized spa 2.0 made all earlier components functional components which invalidated existing inheritance model in our design. Now components like tabs or carousel or accordion which supports inclusion of child components (mappable) in specific parts of our markup, before 2.0 we were simply rendering child components where needed unlike the ootb container or responsive grid that renders flat. No with 2.0, when using functional components, we no longer have access to this.childComponents and hence we need a way obtain existing component mapping used by topmost container to find the match and render the child component.
Describe the solution you'd like Either pass the component mapping as a prop to all child components when it is not passed as a prop or make the component mapping exportable or expose it via state hook so we have a single source of truth. Sample snippet below for passing the prop down.
Before: https://github.com/adobe/aem-react-editable-components/blob/282e050e0d54d2892fdeafca351c8c61712cb5cb/src/components/Container.tsx#L60-L66
After:
Describe alternatives you've considered In the long shot, we may have to mimic creation of component mapping at application layer and pass as a prop and then use the same wherever we need it just like how it is done in this library. But again, if something so normal can be managed from a central place, why create copies across and duplicate foundational components like Container or page forcing them to pass the mapping