Sometimes you see questions online like “is React scalable??” and of course people say yes. After-all it is used on a massive scale by Facebook themselves so we already have some pretty good evidence to back that up.
I think the better question now is “how can I make sure React is scalable for my problem?”. As software developers we always have a problem to solve and in many cases React can really help us solve that problem, but only if we use it right.
One of the keys to scalability is implementing consistent patterns and paradigms for the developers to follow. These approaches should be well considered and follow good principles, but they don’t need to be perfect, they don’t even need to be amongst the best of the best, but as long as they are well considered, efficient and logical when applied to solving the business problems presented.
What makes a good design pattern? Well in my opinion it should be well established in the industry and ideally have as low a complexity as possible. The second part is particularly important because in many situations, especially larger companies, we need to consider structures of a growing business, one result being entry level/ junior developers joining the team, and they should not be expected to understand the code equivalent of quantum mechanics.
Let me give an example of a React / Redux code base I worked in some years ago, basic structure was as follows:
- components
- selectors
- reducers
- actions (thunks, later evolved to sagas)
Nothing mind blowing here, many people follow this same kind of structure, but the point is we have here some proven and established patterns that we can follow to ensure consistency and separation of concerns which will both massively assist with scalability.
If you are not adding a third party lib like Redux you might just want to consider abstracting away your business logic via hooks/ context, but again the point is – make sure you consider, establish and document consistent patterns to be implemented when using React to solve your business problem.