There have been many react component patterns used over the years to facilitate the composition of frontend software.

However, React has evolved over the years especially with the introduction of hooks and context. Newer ways to do things clash with the so-called "older ones". In my talk, I want to take a relook the patterns from the perspective of a developer's needs for implementation, be it extracting logic, combining props, handling hierarchy, or inverting control of state.

Once the need is established, it is helpful to compare the new and the old patterns, if they exist, for the same goal and understand the pros and cons of each.

Although a strict design system can provide assurance in how different components and props can be utilized. Moving over to a composition based design system allows your team to speed up their velocity and publish features quicker with higher confidence. Let's talk pros and cons.

Each component property in your design system serves as an entry point to your component library and its developer experience is largely influenced by their structure and implementation. In this talk, we'll explore multiple ideas to refine your thought process when working on components and make your libraries more user-friendly for other developers.

Writing one component is easy. Conditionally rendering two different ones is still not hard. But what if you face an "n" number of permutations. "n" number of different UI elements and scattered business logic? Switch statements all over the place. Might not sound scary when we write the code. What about your future self? Cognitive load fires off the roof. Maintaining your code? Onboarding new devs? Good luck. Sounds all too familiar? Let's see a possible solution how to tame complexity. How to tackle a large number (possibly infinite) of branches in a frontend codebase without losing our sanity.