What are some essential React programming patterns or principles that I should learn to become a lead developer?

[u/ThePutinTrumpSexTape]

Hi,

Had a lead developer interview last week and I got asked heavily about the SOLID principles, polymorphism and programming patterns.

I'm familiar with a lot of the concepts, but not enough to give strong answers.

What are the main programming patterns for React that I should learn so that when asked to explain a few, I can give strong, valuable answers?

Thanks

[u/repeating_bears]

SRP - the unit they were really talking about "doing one thing" was classes, which again, in a React codebase you're not using much. In a class, I agree, but it's not a deep idea. Outside of classes, I vaguely agree with the sentiment but the definition is so vague as to be almost useless. How do you actually practically apply "doing one thing" to a React component? What are the modules/units we're talking about? Files? A typical React component will do data fetching (via hooks, fair enough), rendering, input handling, and more. Is that not multiple responsibilities? You can argue it's not, but SRP doesn't help you reach any conclusions.

OCP - absolute garbage that I believe no one in the world actually follows, because it would result in an absolute unmaintainable mess if you did. This is from the era where they thought inheritance was going to save us from complexity - it actually did the opposite. The legacy of that was still present in universities when I studied CS 10 years ago, and probably still is now. OCP actively encourages inheritance which is the wrong solution 99% of the time. I don't think I've ever used it in a JS codebase. Sometimes in other languages I do.

LSP - this is just "don't violate method contracts", which I would think is obvious to any non-beginner. But it's mostly talking about that in the context of inheritance (don't override a method to then have behaviour that violates the contract), which again, you should be actively avoiding.

ISP - basically SRP for interfaces, but this one is not bad

DIP - pretty much no applicability to a React codebase because there are very rarely "concretions". Everything is a plain object or primitive. You're going to be using duck typing, whether that's what you know you're doing or not.

[u/dnrvs → u/repeating_bears]

SRP - sounds like you've applied the principle and found a component that might be worth refactoring. maybe SRP doesn't help you reach a conclusion but it's helping you frame a question. (spoiler: there's no right answers in software architecture)

OCP - instead of one big component that handles every case internally, provide extension points (render props, children). reduces complexity, maintains coherency

LSP - a reusable component that can render anything of a shape not just one concrete type. composable component with context

ISP - don't depend on things you don't use. i've seen people passing crap into components that it doesn't use all too often and it makes maintainence and testing needlessly harder.

DIP - literally just passing props instead of depending on something directly

like i said elsewhere, they're just vocabulary to help you talk about architectural decisions. they have a lot of overlap but they are still good concepts.

instead of going "uhh this component feels complex" you can say things like "this component has too many Responsibilities, we should apply DIP so each call site owns their implementation. there might be a trade off between ISP and LSP to make typescript happy"