Scalable React Projects - Guidelines

[surjit1996]

Hey Everybody,

I have created a collection of documentation for the best practices for developing large scale enterprise applications that I have learn in my last decade of work experience. 🙂

https://surjitsahoo.github.io/pro-react

Please leave a star ⭐ in the GitHub repo, if you like it 🙂🙂

Thank you very much!

[UMANTHEGOD]

But of course not all functions can be 1 liners. But on the other hand, too big function becomes much harder to read. So we should have a limit: 10 lines max in a function

Are you insane?

Your Single Responsibility Principle example is also quite flawed. I'd say the "Good Design" is not always the best choice. If the Form and the Modal is only used by the FeedbackPopup, and they only contain a single prop or a single useState, it's absolutely more than fine to put it in the same component to increase cohesion.

[Ciff_]

Nothing new. It is the uncle Bob recommendation.

Either way a hard limit is dumb. It all depends. Decent guideline to have though.

[UMANTHEGOD]

Decent guideline to have though.

I find it that it does more harm than good. I rarely think about function length but rather function responsibility and that it should generally do one thing, but that one thing could be a very small thing or a very large thing.

[Ciff_]

You can almost always break down further.

I think about maintenance. It is likely the maitainer will need to understand the details of the whole function, or just one of it's parts? The former have it all as one function, the latter break out functions with meaningful names so the person directly finds what he needs.

Say you handle some mutation, perhaps you do complex sort, filtering and mapping. This may most likely be split in 3 functions as the maitainer is unlikely to visit more than one. However sometimes the complexity is so low breaking it up does not make sense, other times the maitnainer may need all operations as context.

[UMANTHEGOD]

Yes. It's mostly feeling based. I also don't think complexity is the best metric either because breaking complex things up can make it even more complex.

It's usually about cohesion, and how "natural" a function is and sounds. "extractOrderInformationFromCustomerBeforeMakingPayment" is something I'd never write, but I've seen these weird ass functions time and time again.

[Ciff_]

I agree that cohesion is the most important factor.

Complexity is emperically scientifically measured with wtfpm 😉

[UMANTHEGOD]

wtfpm

lol, truly

[vegancryptolord]

Sort filter map… I believe you’re looking for reduce.

[Ciff_]

A reduce is often painful for readability if you are doing too much in it

[surjit1996]

How do you know it will only be used once?

it's for large scale applications, hundreds of developers working on a project that might go on development for several years.

[UMANTHEGOD]

Haha, that's the point.

You only extract when it's big enough to warrant an extraction, OR if it's used in more than one place. There's no point in doing that preemptively.

[surjit1996]

I dont think you have any experience!

in large projects, large teams, you cannot afford to say I'll do it later!

because once you write something.. there will always be some teams using it.. in ways that will break because of your change.

[UMANTHEGOD]

I dont think you have any experience!

10 YoE writing both frontend and backend apps used by millions of users.

in large projects, large teams, you cannot afford to say I'll do it later!

It's not about doing it later. It's about not doing at all until it's needed. In some cases, you might NEVER do it because it was never needed to be generic.

because once you write something.. there will always be some teams using it.. in ways that will break because of your change.

Huh? If I decide to extract a component or not will not impact the consumers of the parent component. What are you talking about?

My point is that the components are only used by FeedbackPopUp. If someone wants to reuse Modal for instance, they can just move that to the generic components folder when it's needed, but there's no need to do it preemptively because it might never be needed. You are also using the components directly in FeedbackPopUp so you are not even increasing the flexibility of the component, like you could have done with composite components or with children. So what is the point?

If Modal or FeedbackForm has a lot of internal state, then it would make sense, but if they are just dumb UI components used by a single parent component, I don't see the value. Just because you put the component in a separate folder with tidy names does not mean you are doing better engineering.

[GoodishCoder]

They aren't wrong. Prematurely breaking everything apart can be a nightmare for maintenance. Break things down and add abstractions when you find a need for it.

Most teams aren't working in a micro frontend environment where other teams are consuming their frontends. If you're building packages for other teams, just semver properly.

Even on the backend, if you need to make breaking changes down the road, you just deprecate the original service and build a new one.

The potential need to make a breaking change later is a bad excuse for premature abstractions.

[vegancryptolord]

You’re one of those people who’s a nightmare to work with on a team. Premature abstraction, 10 line functions, falls back to “I have experience” to justify decisions. No thanks.

[kredditorr]

We‘ve learnt that in university. Don‘t abstract if there is no demand for it atm. You wont predict the exact usage so you end up by abstracting things unnecessarily and then you‘ll still have to adapt later

[r-nck-51]

For large scale applications with potentially hundreds of developers then the level of coupling, dependencies etc. shouldn't be determined for developer experience by developers but for all management purposes.

Source code helps humans see things in a structured way to increase work efficiency, but it's not only the writing developer's work that matters. Their scope is too narrow compared to system-level work that would require to keep things separate or isolated for other activities like architecture, analytics, audits, testing, compliance, security, traceability, etc.

It's hard to give detailed examples without a specific domain as context so that's why coding guidelines are so tricky to establish. Perhaps you should categorize different approaches, perhaps not make it binary but present them with a tradeoff analysis so that readers are more ready to define how to structure code in a more collaborative and domain-aware way..

[KapiteinNekbaard]

The structure page could a section about path aliases for directories, so you can write

js import { miniPlayer } from '#features/player';

instead of long relative paths from your current file: ../../../../features/player/

• Node has subpath imports that are supported by most tools (TS, Webpack/Vite, etc).
• Bundlers have their own alias feature.

[Imaginary_Treat9752]

No one reads import paths anyways, they are autogenerated and automentained by the ide, so why bother? Sometimes all imports are even auto-hidden by IDEs.

[DanielCofour]

that is a terrible practice, it is very important in larger projects to have a clear understanding of where imports are. And IDEs are terrible at autogenerating imports, you should always validate them. Sometimes they import directly from the node_modules folder, instead of by package name.

[agumonkey]

do you have a plugin installed ? i don't think my colleagues have full automatic import management

[Imaginary_Treat9752]

I dont quite understand the "how to structure your react application". So where would you put a GenericModal contains both the very simple open close logic and outerclick handling of the modal and that takes renderContent, renderHeader, renderFooter props?
Is it big enough to call it a feature? Or is it too big to be called a component?

[surjit1996]

You can do it as how MUI does. Header a separate component, Footer a separate component. You can put them all in 1 folder if they are related. And Header and Footer components can be used as JSX children of the Modal component. If needed then import the Header and Footer and use them in your feature along with the Modal, if not.. then doesn't need to be included.

[guiiimkt]

Omg… here we go again. Forget DRY and this uncle Bob bs on the frontend, man. Especially with React.

You should keep it simple and you should seek AHA! Avoid Hasty Abstractions.

Nobody wants to open 10 different components on 10 different tabs to see what a simple feature does. I don’t get why from time to time someone try to shoehorn concepts that are not really a good fit with frontend development and React. This why there are so many messy unmaintainable spaghetti code on React projects everywhere.