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.

I’ve been building UI components with React for a while now, and I’ve read a lot about server-side rendering (SSR). From what I’ve read, I didn’t expect SSR to affect how React components are built.

Lately, I’ve been working on a component library, and one of the consumer teams I worked with uses SSR. After building many components, I received feedback that several of them weren’t working correctly when SSR was used. This got me thinking about why this was happening and how SSR might affect building React components.

I'll cover typical smelling Antipatterns of React that I've encountered refactoring code in many projects and offer easy-to-use patterns that you can start using today.