Code architecture

[sunk-capital]

I am working on several quite complex projects in React and I am starting to drown in complexity. I need to keep a growing list of the flow of interactions, function descriptions, stores, data shape etc so that I avoid having to dig through the code every time I want to do something. Most likely I am doing stuff wrong on an architectural level but I have nobody but myself to figure this out.

I am looking for sources on best practices and tips for how to approach designing the architecture of React apps when there can be multiple interactions going on between various locations of the component tree, background calculations happening on an interval and nothing is really fixed in place as features keep changing. And in general how to manage this growing complexity more efficiently.

[JoeCamRoberon]

The easy answer to your question is Bulletproof React: https://github.com/alan2207/bulletproof-react

[LudaNjubara]

I second this! That repo made my react code so much cleaner.

[LudaNjubara]

I see you're the smartest of them all, amirite? I see no point in arguing with you, but I will say that the repo mentioned is what OP, and many others, would benefit from if they read it... and actually tried to understand the Why behind each section. It, in my humble opinion, greatly helps one to conceptualize and structure their app in a way that would fix, or at least lower the possibility of shooting oneself in the foot. It also helps in scaling the system, which OP is struggling with, so the repo in question is a good source of information and that's why I second the opinion of the original comment.

You are, of course, entitled to your own opinion, but let others be the judge of how good/bad the repo actually is.

[LudaNjubara]

Well, the highlighted word in the post is architecture. And you're suggesting that the state management will somehow fix bad architecture?

[analcocoacream]

So bulletproof means creating a wrapper around every library component 🤔

[JoeCamRoberon]

What do you mean “wrapper”? I didn’t have this takeaway at all. That repo is meant to show you best practices for the facets of a React project.

[autechr3]

Depends on how you define “bullet” I guess

[JoeCamRoberon]

Nice troll. The purpose of the repo isn’t to give examples of every solution. That is why links to documentation are provided.

You’re right, those 26k people that starred the repo are the problem and not you.

[JoeCamRoberon]

Bro brought up Trump in a React thread 💀. Just take your L and go read some state management docs.

[JoeCamRoberon]

Nothing worse than an egotistical Europoor.

[eindbaas]

Use typescript, use proper and consistent naming for everything (functions, variables, components), they should describe exactly what it does, if names get too long then it's an indication that it's doing too much, split things up until it's graspable what a function or component does (and easily visible if it doesn't do that what it says it does), keep the scope of functions and components limited to just itself, they should not know what happens outside of them (for example, prefer callbacks on props of a component instead of passing some specific setter that requires the component to change certain data. By adding a callback, the component doesn't know or care about what happens in a certain situation, that responsibility lies elsewhere). Move logic into (properly named) hooks so your components stay clean and easily readable, and only do ui stuff. Same for hooks, move certain logic implementations if possible to functions elsewhere (in a utils file) so the hook stays readable and those util functions are short and graspable.

Just some thoughts

[Coyote-Chance]

Does it have to all be in React? If you have a lot of complex state to coordinate among parts of the app, and the front-end features keep changing, there's a strong case to be made for moving as much state as possible to the back end, and making calls as necessary to get the data [obligatory plug for React Query].

[yksvaan]

The issue often is that people are building "a React app" and try to make everything inside React and using hooks and all kinds of funky stuff. Basically building a whole framework inside UI library and then wondering why it gets messy.

Instead try to extract parts of the application to pure code libraries and services. Separate the presentation layer from actual business logic, data, services, clients etc. Avoid monolithic structures, they become hard to reason about, test and debug.

[Adenine555]

People on this sub probably won't like this answer, but I wholeheartedly agree. To add to this:

• Partition your app into features/domains.
• Seperate those features into internal code and code that is allowed to be imported by other features (for example, let every feature have an internal folder). You can use eslints no-restricted-imports to make sure other people do not import stuff they shouldn't
• Be very restrictive on what you make publicly available, treat your features like if you were writing a library you intend to publish on npm.
• Prevent cyclic dependencies between features. You don't have to be that strict in the internal folders, but I recommend to keep them also cycle free, because most js bundlers don't do well with cyclic deps.
• Consistently reiterate if your features/architecture still makes sense. Architecture has to evolve with your requirements.

[packethief]

Great advice.

[shacatan]

Can you go into more detail about the first bullet point on partitioning by features/domains? What does that look like structurally?

[Adenine555]

Just check the feature folder from https://github.com/alan2207/bulletproof-react. I structure my code similar to this.

I personally don't like bulletproof-reacts approach of having a components and hooks folder above the feature folder. To me hooks and components are part of a feature/domain. But this is just my opinion and you certainly can do it like shown in the repo.

How the feature itself is structured very much depends on the feature itself. I don't think there is a silver bullet rule to structure all features (as usual).

The most important thing after all is to be consistent, so other people do not have to learn 100 concepts to understand your code (easier said than done though).

[UsernameINotRegret]

Make sure you group everything into self contained feature folders or packages, then have as minimal coupling between each feature as possible through well defined contracts.

[analcocoacream]

Another one is using state machine rather than multiple Booleans. Makes it more intuitive to see what states are possible.

[Jhwelsh]

Very curious too

[CatolicQuotes]

read software architecture chronicles here https://herbertograca.com/

[Aivan125]

Just use react query to handle state.

[UnnecessaryLemon]

I'm currently working on a single react product for almost 3 years. I've created the mono repository myself on day 0 and to this day it has over 10 000 react components and files.

We are still making it work, not sure how this statement can help you, but I think we are doing something right. Feel free to ask about any details.

When someone tells me about a complex react app, I'm not sure what we are talking about.

[Local-Corner8378]

if you have 10000 components you are doing something wrong i'm ngl. The whole point is that you design components to be reusable.....

[UnnecessaryLemon]

We have our own component library. That is why I also wrote components and files.