Design systems are often seen as essential in growing organizations. However, where design team is under-resourced, maintaining and evolving a coherent system becomes a challenge. This talk presents a pragmatic, engineer-led approach to promoting, using concrete React patterns and architecture.

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.

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.

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.