u/DependerSethi

Kept seeing the same advice everywhere: wrap things in useMemo, useCallback everything, React.memo all the things.

Then i profiled an app I'd "optimized" this way, the memoization overhead was costing more than the renders it was preventing

with the react compiler now auto-memoizing at build time, most manual useMemo/useCallback is becoming dead weight.

wrote up what actually fixes react performance in practice:

1. state colocation: move state closer to where it's used. this one change beats every useMemo in your codebase. seriously.
2. the children pattern: pass children from above so they don't re-render when parent state changes. zero memoization needed.
3. useTransition: mark non-urgent updates as transitions. input stays responsive, heavy renders happen in background.
4. useDeferredValue: same idea but for values from props you don't control. smarter than debouncing.
5. code splitting: lazy() + Suspense for routes and heavy components. don't lazy-load a button though.
6. profile before optimizing: react devtools profiler, chrome performance tab, core web vitals. if you haven't measured it, don't optimize it.

also covered 5 performance bugs i keep finding in production codebases:

1. components defined inside other components (full remount every render, not re-render)
2. useEffect chains causing cascade re-renders
3. context providers sitting too high in the tree
4. unstable keys (Math.random() as key is surprisingly common)
5. object/array literals in JSX props breaking React.memo

the useEffect chain one is probably the most common. three effects that depend on each other = three render cycles for one user action.

https://www.sethi.io/blog/react-performance-from-sluggish-to-lightning

what's the worst react perf bug you've had to track down?

Kept running into the same problem at work: build a Button component, someone needs it as a link, now you're either duplicating styles or writing invalid html by nesting <button> inside <a>

Wrote up how polymorphic components solve this. covers:

- the as prop pattern (how chakra and mantine do it)

- making it type-safe with ComponentPropsWithoutRef<C> so typescript knows which props are valid per element

- the forwardRef gotcha where typescript loses the generic (and the fix)

- asChild pattern (how radix/shadcn does it) and why it exists

- a reusable PolymorphicProps utility type you can drop into any project

also when NOT to use any of this. not every component needs to be polymorphic.

https://www.sethi.io/blog/polymorphic-components-one-component-many-forms

Curious how others handle this in their design systems. do you go with as or asChild?

I've been writing React for about 8 years and one thing that always bugged me is how patterns like compound components, render props, and HOCs are taught. Most resources just throw code at you without giving you a mental model for when to actually reach for each one.

So I tried a different approach. I mapped each pattern to a LEGO connection type:

- Compound components = hinge pieces (two parts sharing one mechanism)

- Render props = Technic pins (one connection point, anything can plug in)

- HOCs = baseplates (invisible foundation, every structure benefits)

- Custom hooks = instruction manuals (same bricks, different build)

- Container/presentational = display stands (model and base built separately)

Each one has code examples, when to use it, and more importantly when NOT to use it. Also covered how they layer together in a real codebase.

Would love feedback from this sub. Especially curious if the analogy approach makes things clearer or if it just adds noise.

https://www.sethi.io/blog/react-component-design-patterns-the-building-blocks-lego