I worked on an Android application with a 4,000 line service file that handled all IO to a proprietary websocket-like server. There was obviously 0% test coverage because how the hell do you test that?
The project was inherited from an outsourced firm.
Boom, right before I leave the company, the client wants to go for 80% test coverage.
**DISAPPEARING PEACE SIGN GIF**
Lol the only time I've approached 5000 lines of code in an anything was when I first started and convinced my company to let me put my old job aside for a few months to try and script something for them and ended up with a 2500 line python function ... It turns out PyCharm refuses to even check your code for errors after a function is more than 2000 lines which tipped me off that I might need a second set of eyes...
Yes, that’s stupid. It should be broken down. More than a couple of hundred lines in a file I start really itching to break it into more files, or even before that.
I think that really depends on what you are doing. 200 lines of business logic and that might be concerning, 200 lines of markup perhaps less so. 5k lines that crazy!
Even then, I like styled components. That code is actually separate components that I put below the main component code, and could be moved to another file if you want or it needs to be reused in multiple other files. Easier to just leave it at the bottom of that file if it’s only being used there imo, and the main component stays just as slim.
Well, 5k lines is easy if you avoid all loops. Just write what you want to happen in the order you want it to happen in. If time doesn’t loop: why should computers.
Not really- there is such thing as over componentizing and introducing unnecessary complexity to the codebase as a result, making it more difficult for the reader to understand the overall code and how all the pieces fit together
Also harder to maintain and make changes to the code when a single change needs to be propagated across multiple files and functions
For me usually I think of the level of abstraction and hierarchy, the coupling of these things, and my general rule is to keep things as flat and un componentized as possible until there’s significant complexity that would benefit from pulling stuff out into separate components
I don’t like having styled components and css declarations in a separate file if they’re only being used by one component and are inherently tightly coupled to it- unless the css is super long which hopefully isn’t the case due to using a design system
When looking at a code I'm not familiar with, I'd much rather have one huge file than 30 files of 20-200 lines each. 5000 lines is definitely too much but for something smaller it is totally ok to leave it in one file. Creating arbitrary files for "better otganisation" just makes it so much harder to work with since you need to keep switching between multiple files to get anything done.
I really suggest to split it to aux components, maybe custom hooks and try to extract functions (code) that isn’t related to render or hooks to regular functions
Always baby steps!! Do not face this problem at once.
That's... too much. A whole heap of too much.
But now it's probably reached the point where it's become an absolute nightmare to even think about separating this out and refactoring it.
Have you got comprehensive unit tests covering this file? Without them, refactoring would be dangerous.
Unit testing is one of the last good practices to be adopted by companies; if they keep having 5000 lines in a single component, I think they should first implement more basic good practices...
Lmfao. My last job I was hired on as a react dev, but they knew I was proficient with other tech. They put me on a project at one point to refactor a page with some reports. It was a 62k line PHP file.
Im not even joking or being hyperbolic. The fucking thing was laughably long.
Yes. For nothing more than developer experience reasons. If a component is seriously 5000 lines long, I would question why it got to that point before being refactored.
I don't have any hard and fast rules for when to split components like others, but I do know that the moment a component begins doing more than 1 thing (other than container components), then it needs to be split up. This goes for the markup, the js, the styling. Any of it.
Why? Because it makes things easier to isolate and test. I can only imagine the test file that's using that component. We routinely write 2-300 line test files for components that sit ~50loc, so the test file for that component must break your IDE.
That's easy.
In a corporate environment refactoring means retesting, and it would be immediately brought into question why you changed a piece that has nothing to do with your current requirements. So a lot of people take the "safe" way and don't refactor or rewrite, because that would involve convincing a lot of people for the need for the refactor and instead just expand the existing code
All code is a function of time and chaos; the more time the more chaos and the more need to rewrite. Very few people would have either the courage or the desire or the environment to make themselves a target and a "troublemaker" to rewrite existing code for the sake of code quality. It's also a thankless job because this kind of risk taking is very rarely rewarded and at worst actively discouraged. Only on a new project or new initiative would such actions be favored. Corporate solution to these problems is microfrontends to make the user interface fresh every single time but that takes a huge investment to make work and doesn't have any standards for now.
Also the distinction between rewrite and refactor isn't as solid as people think. A lot of the times code just has to be rewritten, even code written by yourself when you lacked knowledge months or years ago.
How many of the people you hear complaining about someone else "rewriting their code" actually deserve it? A lot I bet.
You’re right on the money. I was a proud “troublemaker” at my last job, refactoring code and converting JS to TS for the sake of quality and maintainability, but such changes were discouraged so I left to join a startup.
When you say a component has 5k lines of code. Does it have a couple of very big functions or a lot of small (<100LoC) functions?
5k lines in file is a code smell but depending on situations, it can go there. Main thing is if the logic itself is well divided in functions or not
It's a symptom of bad architecture. Spaghetti code is common with developers who just type away and don't think twice about abstractions, testability, developer friendliness...
The problem is that it's hard as fuck to refactor for what bad developers think would be little to no benefit.
It's not even tech debt. It's tech bankruptcy. Hard times are ahead, it's called "refactoring."
No, it isn’t stupid. What is stupid is doing things arbitrarily. If there is a reason it needs to be that big, then that’s that. I can’t really think of a reason why it would need to be, but we can’t just say “no, that’s bad because it has x too many lines”.
I appreciate this might be extremely unpopular here, but as a team lead with 10 years of experience in the field who's contributed to some of the highest traffic websites on the internet, this is my opinion:
- Is it stupid to have 5000 lines of code in a single component? No.
- Is it stupid to question the validity of this approach? Also no.
It is highly likely that the 5000 line component OP mentions should be refactored, however based off of purely number of lines, it's impossible to say.
Splitting components eagerly doesn't make you a great developer. Splitting components at logical or performance boundaries (the two usually go hand in hand anyway) does. If it's 5000 lines of paragraphs of text, there's absolutely no reason why you'd need to introduce a layer of abstraction. It makes searchability ever so slightly worse and has no real benefit, other than if you're on an extremely low memory device, trying to edit the file.
So the answer to your question is: based on your question, it is impossible to determine whether it's the wrong approach or not. You're right to question the validity of the approach, but without more information, please take other comments that say "yes it's stupid", "my limit is 20 lines per component", etc with a grain of salt.
Speaking of limiting the lines of code in a component, I think that is, in fact, quite a misguided way to add some unnecessary technical debt in your codebase.
I respectfully disagree.
There is absolutely no reason for a component to have 5000 lines.
If it's thousands of lines of text, the text should be stored separately.
I have not in fact seen one in the wild, but if I do, I'll probably have more important aspects to assess before I can think about the amount of lines it takes up.
Well, experience should have taught you that an incredible line count like 5000 is guaranteed to have several issues, including DRY-related, readability, testability etc..
Like I said, there is no conceivable situation where 5000 lines is justified, or even a good idea.
You're missing the point. He's not advocating components that have 5000 lines of code for an element. The number of lines of code is just the wrong way to think about it. It's about finding the most optimal way of composing your UI from a logical and/or performance perspective.
No, I get his point, and I'm saying that there is absolutely no reason for a component to have 5000 lines. If you disagree, give me one example when it would be justified or make sense at all.
His argument could make sense when talking about 20 vs 200 lines. Not 5000.
It's the wrong conversation to have. I will never discuss with a junior developer how many lines of code are permitted in a react component in our application. You can have a component with 50 lines that violate SRP or SOC. The number of lines of code is a red herring.
You don't understand. Let me reiterate.
It doesn't matter if a component has 10, 100 or 500 lines. I'm not arguing that the number of lines of code is an important metric.
However, 5000 (FIVE THOUSAND) lines of code, an enormous number, is a clear sign of something being terribly wrong.
I'm challenging you to give me a theoretical example of a component with 5000 lines which makes sense.
I agree 5000 lines of code is an enormous number of lines of code. However, acknowledging that brings us (you and me) no closer to a better understanding of good coding practices. It's not a productive conversation. It's a conversation I refuse to have with my developers.
The question is straightforward and asks specifically about a component with 5000 lines of code.
It is not asking about good coding practices, whether the number of lines of codes is a meaningful metric etc.
Therefore, the answer to OP's question should be "yes, a component with 5000 lines is stupid" because of how certain it is there is something very wrong with the implementation.
I agree that components need to be modularised with design and logic in mind but a 5000 line single component is going to be total spaghetti code and a huge pain in the ass for anybody else to quickly and efficiently step in and manage / update and could cause massive operational problems in the future.
If it's a layer of text - that layer of text can (and should) be introduced as a constant away from the component code and imported. If it's a conditional text, it can be outsourced into a helper function with conditions that returns the correct output based on the inputs.
"Splitting components eagerly doesn't make you a great developer."
Maybe, but not splitting them sure does make you a bad developer. And I'll gladly die on this hill.
This is the thing. What's the advantage of adding a constant here? When you're browsing the codebase you're just one step further away from finding what you're looking for. There's no performance benefit (technically a const would occupy slightly more memory, because if you keep it inline it will be GCd after the function runs).
But how? If you have proper formatting set up, it should already be very readable. Your constant string example on the other hand would be a pain to read in a diff viewer for example, unless you split it into multiple lines, which adds additional syntax (`"..." +`) so in fact I'd argue it's the less readable of the two.
You also might want to add HTML elements inside that text, e.g.: `` or `` so then this variable becomes a JSX Element and at that point you may as well just put it where it belongs.
With template literals you're either adding line breaks to your text or have to escape the carriage return character with `\`, which not every junior dev on your team might remember or understand.
Magic strings are the devil. They always have been and always will be.
What happens if that text that u/so_lost_im_faded mentioned needs to be translated for i18n purposes? What's going to be easier to deal with, a constant that could be generated at build time, or copying and pasting that component to add the translations?
And even in cases with HTML in the strings, there are ways to deal with that too. It isn't perfect, but it works.
For someone with 10 years of experience, and someone who has worked on `some of the highest traffic websites on the internet`, you honestly should know better.
I've made no mention of translations. Not every website is, or will ever be translated. How does storing text in a const instead of directly in a component even prompt a discussion about magic strings? I think people responding to this, such as yourself are missing the point I made. All I'm saying is, rather than applying semantics to disregard a solution, one should consider the context before jumping to conclusions.
I've worked on a website where we started with future i18n in mind and the app never got translated and we carried that debt with every PR that changed any part of the copy.
It's not all black and white.
This person has been working on corporation-level code, and has seen some stuff.When you have legacy code that spans 10+ years, multiple roles and simultaneously active A/B tests, server rendering + browser rendering and whatnot, some simple components become insanely complicated, and still need to be in same file, because the code for various variants and roles changes together.
That said, 5000 lines sounds a lot, unless it's like the whole business logic of a page/app.But you do get those when there is something like wrapper for 3D visualization & animation library that uses imperative or object-oriented paradigm, and it has been implemented with class components, that were difficult to split and refactor. (Just checked, my legacy 3D visualization & animation routing component ir 530 lines of code :D)
I tend to agree. If I was looking at this component I’d be looking at how much state, complexity and logic branches it has. Most importantly I’d be asking how difficult it is to test.
I’ve seen plenty of 90 LOC components that fail the unit test sniff test and 500 LOC ones that are fine. Dogmatism and arbitrary rules don’t survive contact with pragmatism.
That said .. 5kLOC is extreme or exaggerated and can’t possibly be reasonable architecture.
I'm questioning the quality of those 10 years to be honest.
This is a valid point if it was 500 lines, but 5k is obscene and definitely a point at which you should split whatever it is into smaller logical parts.
If you were to decide to split it up, would you use the lines in each component to help you decide? So instead, of 5000 lines of code in a single element, let's create 100 elements to 50 lines a piece. That's what you would do? That would be lunacy. The number of lines a component has is irrelevant. It's single responsibility and separation of concerns that matter.
Love that you're questioning things, that's always important. On the other hand, you're using the exact same point I've made here in another comment almost verbatim. My point is "you should not use metrics, such as LOC to argue validity, instead separate concerns where it makes sense to do so". Yes, 99% of the time it will make sense to do so well before you reach 5k LOC, however one simply can't judge a function based on how many lines of code it has alone.
Yup this is a hot take but I think a lot of experienced devs would probably agree.
YES, it most likely is an insane component that is just very poorly made. But honestly, sometimes it's also okay.
"Learn the rules like a pro, so you can break them like an artist."
The distinction, is hard to fully realize so it's better to err on the side of caution. But in the end, the mental model of the architecture is really more important than arbitrary metrics on source code.
Another key point I forgot to mention is, even if the component is badly structured, it's important to think about whether there's any short or long term plans to touch that component, and if not, it's still probably more beneficial to leave it as it is. Refactoring always carries a certain amount of risk and if there's no potential benefit to doing it, it's not trivial to justify.
When I was building my portfolio of projects to get ready applying for jobs, I felt bad because one component had 214 lines, so I broke it down.
5,000 is insane.
On my first ever work as a web programmer the main component of the app was close to 9000 lines. And then, its children were monsters as well. 1000, 3000 stuff like that
I had to say that I learnt a lot in that project though. Fun times. But that set of components are untouchable, they work as they work and that's it. They have their own life.
My colleagues do this as well. Some of our codebases have React component files so big I can't even run prettier without VScode freezing. They refuse to learn state management libraries/patterns so to share state between components they end up defining components inside the function body of the main component. And they never useCallback or memo. Just hundreds of useStates and useEffects doing God knows what and hundreds of functions and components getting redefined on every render. They also refuse to use typescript which just makes maintaining all this pasta even worse. I think about quitting every single day but I love my coworkers too much.
# wow single file monolithic program at its best!!
5000 lines of code in a single component is *Anti-React Pattern*. Literally one state change means your are reloading the whole .... & states are not preserved as well ...
Tell ur colleagues to learn ReactJs first
I have a rule - cannot be over 100 lines. Especially with functional components and the ability to create and reuse hooks now, there's no way that a component *needs* to be that big. If you follow the single purpose rule, you cannot possibly end up with an abomination like that.
Depends on the component, 5k lines is indeed a bit too much, but you shouldn't take people in the comments with max 100 lines components too seriously either.
1k+ lines components are fairly common if you check meta repos.
That’s what I’m saying, I seriously doubt anyone claiming 100 line max has ever dug through any large enterprise codebases. I can’t imagine what the file tree would look like in that case to support the functionality of serious web software
How long is a piece of string? There's just not enough information in the OP to answer the question. People throwing out concrete numbers without knowing anything about the system are cargo-culting at best. If this component is stable and working it would be the apex of stupidity to refactor it solely because it has too many lines. The number of lines in a file is a metric that can be safely ignored. Refactor it if it's hard to do something you need to do.
I have one with 400 lines of code rn..I have a strict deadline to meet and no time to start refactoring I feel bad about it..am only shifting components when I need a reusable one otherwise I leave it as it is...
Once project is done am obviously refactoring it.
Yes. As soon as they start to be like 50-60 lines with JSX included you should probably break it up. But even shorter are preferred. Extract common logic to hooks or other components for re-use.
Ridiculous. It's not a hard and fast rule, but if your component is more than 300 lines long you need to start looking at ways to reuse and reduce code
I think it’s extremely unlikely that a 5000 line component couldn’t be broken apart into sub components. That said, technical debt happens with older code; curious what’s keeping folks from breaking it up?
If they are saying that this code is best all in this one file because it's only applicable to X, then maybe you guys need to rip it out and either setup your project as some sort of monorepo or make it into an api?
I always say, goal one: it works. But are there things that could be shared? Split up and tested? 5000 is a lot to read, when it can probably be broken down for your own or other developers sanity.
Unless it's a component that uses canvas for a graphics-intensive app (like drawing or an embedded game). You are for sure doing something wrong. Even in those cases you can abstract and divide code using functions
Yes. That’s unmaintainable and should be broken down into much smaller pieces.
There is absolutely no reason to do this. Small, reusable, composable units of code is what I aim for, not only in React, but wherever I write code.
It’s much easier to reason about 50-100 lines of code and come back to it a year later than it is 5000. It’s also much easier to test and to extend if necessary.
The main reason that I would frown on a component that large is that you have a lot of complexity all at the same scope with fewer clear boundaries. An effect generated on line 100 could affect the state on line 5000 or any line in between plus it can cascade, if it was written poorly (the fact that it is 5000 lines would suggest to me that it probably was). I have to understand all 5000 lines to effectively make a change and not do something undesirable. It's like having a lego car that is one lego piece instead of breaking those responsibilities up into modular pieces such as wheels, spoiler, frame, etc.
I've just started refactoring a file I inherited that is about 600 lines with essentially no tests and it's going to take days to get up to standard. 5k lines is mental.
I thought I read 5000 instead of 500 but I didn't believed my eyes. I had to go to the washroom to wash my eyes for a whole 5 minutes and read again so I'd snap from my half asleep state. Only to realise I wasn't dreaming and it does say 5000
It's not about how many lines of code but the function of the component. Why is it that big, what is the specific purpose of this component? Like engine parts, you can always break components into smaller parts as long as it still maintains a functional purpose.
So don't think of it in terms of lines of code, but functionality. If it is functional as is, and you cannot split it into more functional little pieces, then that's perfectly fine. Chances are, you'll rarely or never need to do that, and you don't want to, because it's a nightmare to maintain and debug.
In a single file? Disgusting
My App component is probably 50k plus lines of code counting the component hierarchy imported into it. But the actual file is like 30-40 lines of code.
The only reason not to break up a component over a few hundred lines of code is self-loathing.
We have some contractors who are developing new features and now the regular employees are currently in discussions about how to break up their single 3000 line "components" into multiple components. It's a complicated situation politically, but it's making my job miserable when it should be fun.
lol. yes, very stupid.
How many things does this code display?
It can and should be broken into parts.
Every time something changes and the component has to render, 5000 lines are being processed.
WHY?
Worst components that we used to have before I said ‘fuck it’ were approx 1500 lines. Currently there isn’t a single one with more than 100 lines.
Yes, 5k is stupid. Too many issues to list but for sure it’s buggy, not performing very well and hard to work with. Kill it with fire
No matter what language or framework you use, modularity is absolutely important. If you can't break it down to manageable chunks, probably you should spend some time planning out the architecture before jumping into codes.
It makes changes increasingly difficult *or very easy.* Components frequently grow to massive sizes because all of the relevant information is right there and properly breaking it out into smaller components is quite difficult.
Imo, if something is 5k lines, then that's ample opportunity to break a lot of it out into easily unit testable pure functions, but I'd also question the performance of commingling so much code in a component that might run a significant portion of that code with each re-render.
If there's that much code in a component, then I have to question the design of the component and where that code should actually live. Remember, React is just a View layer that re-renders according to app state changes. If a component has become 5k in size, then there's likely an opportunity to extract a good portion of that state away from the component and to be more selective about what state is actually present in the component or passed in as props and causes it to re-render.
I worked on an ember app at work with a couple of thousand lines in each file and it was so anxiety-inducing. I don't even wanna know what 5k lines of code in a file looks like!
It should be broken down and modularized. You don't want to have the problem of detecting bugs and errors on a component with 5000 lines of code.
OP, your limited knowledge of react might just be the refresher your colleagues need
What’s worse, a component with 5000 lines of code, or 50 components 100 lines each?
Our company has an enormous react application that’s owned by someone who likes to write abstractions for their abstractions for their abstractions. It almost seems malicious how over-engineered it is. I left that team because the development experience was so bad.
I’ll take a monolith over an over-engineered clusterfuck of code any day.
A monolithic component is never a good thing. But usually it’s there at times when there’s too many cooks in the kitchen or no standards have been set on architectural decisions from the beginning.
I think it is a bad idea. It would only potentially work if you had orderly components with a very well defined structure that is used in all components. Then you always know what is what inside the component and what to expect.
Otherwise, separate logical units into their own component. I'm not an expert, but for me the key is to think carefully about the shape of your data BEFORE you build the component:
\- What needs to be global state
\- What is the local state to the component that only affects that one component
\- What is computed state
\- What is server state
Structure your component based on that and compartmentalize well the different types of data so that they're easy to identify and are not an entangled mess
And then: do not obsess with component reusability. It is easier to change a component if you know that you don't have to handle other use cases in some other part of the app.
Also, use typescript. It is WAY easier to work in the code if you can hover over variables and functions and you can get an idea of their type without having to dig in the code for where that is declared or assigned, or having to look for it in the dev tools (I guess you can tell I just started working in a codebase that does not use types)
I’ve worked on a very large codebase where the average component size was around 4000 lines. Yes, it would be nice to have smaller components but it was a very robust and at-scale app, so it did make sense in many situations.
Imo ideally you should split a component up when you can, but don’t make it worse on yourself and over complexify things just in the name of componentization.
300 is the hard limit to be honest. ReactJS incentivizes modular structure, break big and complex UI sections into smaller and reusable components/hooks.
The larger question that needs to be asked here is, how was the code allowed to be checked in?
That’s not a component, that’s a resignation letter
That's not a component, that's an app.
That’s not a component, that’s a framework
That’s no moon, that’s a space station.
That's no space station, that's your mama!
Those aren’t mountains, they’re waves
I think you meant a resignation essay.
[удалено]
I have a large project with probably 100 components. one is like 700 lines and I feel really shitty about it. 5000 is unhinged.
Defeats the whole purpose of components lol.
Sounds like the whole-ass web app is the component.
SCA (Single component application)
Monocomponent apps are the new architectural hotness.
One junior associate or intern wrote something like this: ``` const xyz = (someProp) =>
What’s wrong with this
Xyz is just a wrapper for por and does not provide any value so it is unnecessary, wherever xyz is invoked it can simply use pqr
I worked on an Android application with a 4,000 line service file that handled all IO to a proprietary websocket-like server. There was obviously 0% test coverage because how the hell do you test that? The project was inherited from an outsourced firm. Boom, right before I leave the company, the client wants to go for 80% test coverage. **DISAPPEARING PEACE SIGN GIF**
Definitely dodged that bullet.
Test with hella fault injection?
Lol the only time I've approached 5000 lines of code in an anything was when I first started and convinced my company to let me put my old job aside for a few months to try and script something for them and ended up with a 2500 line python function ... It turns out PyCharm refuses to even check your code for errors after a function is more than 2000 lines which tipped me off that I might need a second set of eyes...
I tried to imagine the tests, but ran out of memory.
Unhinged is the only word for it lmao. There's no possible explanation for that. 5k lines of code! OP, your "colleagues" need to be institutionalized.
i already feel shitty at 300. at 5000, i'd quit my job and take a mental health break
No shit! I feel this way at a thousand lines. Although it is super satisfying to take a component like this and break it up into smaller components.
100 components is hello world app level, isn’t it?
Yes, that’s stupid. It should be broken down. More than a couple of hundred lines in a file I start really itching to break it into more files, or even before that.
Any component more then 200 lines is a bit of a red flag imo
I think that really depends on what you are doing. 200 lines of business logic and that might be concerning, 200 lines of markup perhaps less so. 5k lines that crazy!
200 lines of non-repeating, non-componentizable markup? What is this? Css-in-js?
Even then, I like styled components. That code is actually separate components that I put below the main component code, and could be moved to another file if you want or it needs to be reused in multiple other files. Easier to just leave it at the bottom of that file if it’s only being used there imo, and the main component stays just as slim.
I'd still raise my eyebrows at that much markup, would then look at making some children components even if just to clean up the html.
Well, 5k lines is easy if you avoid all loops. Just write what you want to happen in the order you want it to happen in. If time doesn’t loop: why should computers.
Not really- there is such thing as over componentizing and introducing unnecessary complexity to the codebase as a result, making it more difficult for the reader to understand the overall code and how all the pieces fit together Also harder to maintain and make changes to the code when a single change needs to be propagated across multiple files and functions For me usually I think of the level of abstraction and hierarchy, the coupling of these things, and my general rule is to keep things as flat and un componentized as possible until there’s significant complexity that would benefit from pulling stuff out into separate components I don’t like having styled components and css declarations in a separate file if they’re only being used by one component and are inherently tightly coupled to it- unless the css is super long which hopefully isn’t the case due to using a design system
200 is a bit much for a red flag, maybe yellow? :)
When looking at a code I'm not familiar with, I'd much rather have one huge file than 30 files of 20-200 lines each. 5000 lines is definitely too much but for something smaller it is totally ok to leave it in one file. Creating arbitrary files for "better otganisation" just makes it so much harder to work with since you need to keep switching between multiple files to get anything done.
Like a blaring one. I start suggesting pulling things out at the 100 mark.
This isn’t your normal every day stupid, this is advanced stupid
It’s fucking batshit crazy, not just stupid.
I really suggest to split it to aux components, maybe custom hooks and try to extract functions (code) that isn’t related to render or hooks to regular functions Always baby steps!! Do not face this problem at once.
Yes, it is stupid, but I’m curious about what this component does tbh
Causes depression, burnout and suicide thoughts
Sounds like any non-legacy codebase
Isn't that every other component anyways regardless or line count? Oo
It'd better make coffee and cook lunch as well as clean the office.
Perhaps the developers mistook an SPA for an SPC.
Wouldn't it be SCA?
SCArred for life?
Main.tsx
It better ensures job security for OP because no one else in the company dares to touch it.
It does everything.
That's... too much. A whole heap of too much. But now it's probably reached the point where it's become an absolute nightmare to even think about separating this out and refactoring it. Have you got comprehensive unit tests covering this file? Without them, refactoring would be dangerous.
Unit testing is one of the last good practices to be adopted by companies; if they keep having 5000 lines in a single component, I think they should first implement more basic good practices...
lol I think you’re right on the money
Lmfao. My last job I was hired on as a react dev, but they knew I was proficient with other tech. They put me on a project at one point to refactor a page with some reports. It was a 62k line PHP file. Im not even joking or being hyperbolic. The fucking thing was laughably long.
sounds like someone was refusing to admit not lnowing how imports work
Why import when you can save lines of code just doing everything in one confident 62,000 line app?
We need more details. If there were a Museum of Coding, that should be I archived in it.
I'd lose my mind with 500, 5000 is gonna give me an heart attack
When I hit 100 lines I start to twitch. So yes, this is juuuuuuuuuust a tad to much.
Feels like having only one table in a relational database and adding columns which are all optional 😅
Your component is an entirely different app bro. Sort your life out
Yes. For nothing more than developer experience reasons. If a component is seriously 5000 lines long, I would question why it got to that point before being refactored. I don't have any hard and fast rules for when to split components like others, but I do know that the moment a component begins doing more than 1 thing (other than container components), then it needs to be split up. This goes for the markup, the js, the styling. Any of it. Why? Because it makes things easier to isolate and test. I can only imagine the test file that's using that component. We routinely write 2-300 line test files for components that sit ~50loc, so the test file for that component must break your IDE.
That's easy. In a corporate environment refactoring means retesting, and it would be immediately brought into question why you changed a piece that has nothing to do with your current requirements. So a lot of people take the "safe" way and don't refactor or rewrite, because that would involve convincing a lot of people for the need for the refactor and instead just expand the existing code All code is a function of time and chaos; the more time the more chaos and the more need to rewrite. Very few people would have either the courage or the desire or the environment to make themselves a target and a "troublemaker" to rewrite existing code for the sake of code quality. It's also a thankless job because this kind of risk taking is very rarely rewarded and at worst actively discouraged. Only on a new project or new initiative would such actions be favored. Corporate solution to these problems is microfrontends to make the user interface fresh every single time but that takes a huge investment to make work and doesn't have any standards for now. Also the distinction between rewrite and refactor isn't as solid as people think. A lot of the times code just has to be rewritten, even code written by yourself when you lacked knowledge months or years ago. How many of the people you hear complaining about someone else "rewriting their code" actually deserve it? A lot I bet.
You’re right on the money. I was a proud “troublemaker” at my last job, refactoring code and converting JS to TS for the sake of quality and maintainability, but such changes were discouraged so I left to join a startup.
>We routinely write 2-300 line test files for components that sit ~50loc lol
Thats far away from being called a component. Okay out of curiosity. How many props and state variables are there?
I am hesitant to call anything stupid without inspecting it first, but at first glance yes, it seems sketchy to say the least.
Even ChatGPT will refuse to fix that monstrosity!
It probably wrote half the lines.
When you say a component has 5k lines of code. Does it have a couple of very big functions or a lot of small (<100LoC) functions? 5k lines in file is a code smell but depending on situations, it can go there. Main thing is if the logic itself is well divided in functions or not
It's a symptom of bad architecture. Spaghetti code is common with developers who just type away and don't think twice about abstractions, testability, developer friendliness... The problem is that it's hard as fuck to refactor for what bad developers think would be little to no benefit. It's not even tech debt. It's tech bankruptcy. Hard times are ahead, it's called "refactoring."
No, it isn’t stupid. What is stupid is doing things arbitrarily. If there is a reason it needs to be that big, then that’s that. I can’t really think of a reason why it would need to be, but we can’t just say “no, that’s bad because it has x too many lines”.
5000 lines is deranged
I appreciate this might be extremely unpopular here, but as a team lead with 10 years of experience in the field who's contributed to some of the highest traffic websites on the internet, this is my opinion: - Is it stupid to have 5000 lines of code in a single component? No. - Is it stupid to question the validity of this approach? Also no. It is highly likely that the 5000 line component OP mentions should be refactored, however based off of purely number of lines, it's impossible to say. Splitting components eagerly doesn't make you a great developer. Splitting components at logical or performance boundaries (the two usually go hand in hand anyway) does. If it's 5000 lines of paragraphs of text, there's absolutely no reason why you'd need to introduce a layer of abstraction. It makes searchability ever so slightly worse and has no real benefit, other than if you're on an extremely low memory device, trying to edit the file. So the answer to your question is: based on your question, it is impossible to determine whether it's the wrong approach or not. You're right to question the validity of the approach, but without more information, please take other comments that say "yes it's stupid", "my limit is 20 lines per component", etc with a grain of salt. Speaking of limiting the lines of code in a component, I think that is, in fact, quite a misguided way to add some unnecessary technical debt in your codebase.
I respectfully disagree. There is absolutely no reason for a component to have 5000 lines. If it's thousands of lines of text, the text should be stored separately.
I'm in no way advocating for 5000 line components. I'm advocating against jumping to conclusions where there's a glaring lack of context provided.
What I'm saying is, I cannot think of a single example where 5000 lines would be justified. Can you?
I have not in fact seen one in the wild, but if I do, I'll probably have more important aspects to assess before I can think about the amount of lines it takes up.
Well, experience should have taught you that an incredible line count like 5000 is guaranteed to have several issues, including DRY-related, readability, testability etc.. Like I said, there is no conceivable situation where 5000 lines is justified, or even a good idea.
You're missing the point. He's not advocating components that have 5000 lines of code for an element. The number of lines of code is just the wrong way to think about it. It's about finding the most optimal way of composing your UI from a logical and/or performance perspective.
No, I get his point, and I'm saying that there is absolutely no reason for a component to have 5000 lines. If you disagree, give me one example when it would be justified or make sense at all. His argument could make sense when talking about 20 vs 200 lines. Not 5000.
It's the wrong conversation to have. I will never discuss with a junior developer how many lines of code are permitted in a react component in our application. You can have a component with 50 lines that violate SRP or SOC. The number of lines of code is a red herring.
You don't understand. Let me reiterate. It doesn't matter if a component has 10, 100 or 500 lines. I'm not arguing that the number of lines of code is an important metric. However, 5000 (FIVE THOUSAND) lines of code, an enormous number, is a clear sign of something being terribly wrong. I'm challenging you to give me a theoretical example of a component with 5000 lines which makes sense.
I agree 5000 lines of code is an enormous number of lines of code. However, acknowledging that brings us (you and me) no closer to a better understanding of good coding practices. It's not a productive conversation. It's a conversation I refuse to have with my developers.
The question is straightforward and asks specifically about a component with 5000 lines of code. It is not asking about good coding practices, whether the number of lines of codes is a meaningful metric etc. Therefore, the answer to OP's question should be "yes, a component with 5000 lines is stupid" because of how certain it is there is something very wrong with the implementation.
Lol, Outside of the context of good coding practices, there's nothing wrong with a component that has 5000 lines of code.
What are you talking about? It's less testable, has almost definitely DRY-related issues, is less readable, less reusable... I could go on.
I agree that components need to be modularised with design and logic in mind but a 5000 line single component is going to be total spaghetti code and a huge pain in the ass for anybody else to quickly and efficiently step in and manage / update and could cause massive operational problems in the future.
If it's a layer of text - that layer of text can (and should) be introduced as a constant away from the component code and imported. If it's a conditional text, it can be outsourced into a helper function with conditions that returns the correct output based on the inputs. "Splitting components eagerly doesn't make you a great developer." Maybe, but not splitting them sure does make you a bad developer. And I'll gladly die on this hill.
This is the thing. What's the advantage of adding a constant here? When you're browsing the codebase you're just one step further away from finding what you're looking for. There's no performance benefit (technically a const would occupy slightly more memory, because if you keep it inline it will be GCd after the function runs).
It's simple. It's making the JSX and the tree structure much more readable. One could say - developer experience.
But how? If you have proper formatting set up, it should already be very readable. Your constant string example on the other hand would be a pain to read in a diff viewer for example, unless you split it into multiple lines, which adds additional syntax (`"..." +`) so in fact I'd argue it's the less readable of the two. You also might want to add HTML elements inside that text, e.g.: `` or `` so then this variable becomes a JSX Element and at that point you may as well just put it where it belongs.
>unless you split it into multiple lines, which adds additional syntax ("..." +) You have 10 years of experience and never heard of [template literals](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals)? >You also might want to add HTML elements inside that text, e.g.: or so then this variable becomes a JSX Element and at that point you may as well just put it where it belongs. "Where it belongs"? I don't see how it becoming a JSX Element makes it "belong" inside a parent component.
With template literals you're either adding line breaks to your text or have to escape the carriage return character with `\`, which not every junior dev on your team might remember or understand.
Line breaks cause no issues if it's long form text. If you're worried about additional bytes, gzip will take care of that.
Magic strings are the devil. They always have been and always will be. What happens if that text that u/so_lost_im_faded mentioned needs to be translated for i18n purposes? What's going to be easier to deal with, a constant that could be generated at build time, or copying and pasting that component to add the translations? And even in cases with HTML in the strings, there are ways to deal with that too. It isn't perfect, but it works. For someone with 10 years of experience, and someone who has worked on `some of the highest traffic websites on the internet`, you honestly should know better.
I've made no mention of translations. Not every website is, or will ever be translated. How does storing text in a const instead of directly in a component even prompt a discussion about magic strings? I think people responding to this, such as yourself are missing the point I made. All I'm saying is, rather than applying semantics to disregard a solution, one should consider the context before jumping to conclusions. I've worked on a website where we started with future i18n in mind and the app never got translated and we carried that debt with every PR that changed any part of the copy. It's not all black and white.
This person has been working on corporation-level code, and has seen some stuff.When you have legacy code that spans 10+ years, multiple roles and simultaneously active A/B tests, server rendering + browser rendering and whatnot, some simple components become insanely complicated, and still need to be in same file, because the code for various variants and roles changes together. That said, 5000 lines sounds a lot, unless it's like the whole business logic of a page/app.But you do get those when there is something like wrapper for 3D visualization & animation library that uses imperative or object-oriented paradigm, and it has been implemented with class components, that were difficult to split and refactor. (Just checked, my legacy 3D visualization & animation routing component ir 530 lines of code :D)
I tend to agree. If I was looking at this component I’d be looking at how much state, complexity and logic branches it has. Most importantly I’d be asking how difficult it is to test. I’ve seen plenty of 90 LOC components that fail the unit test sniff test and 500 LOC ones that are fine. Dogmatism and arbitrary rules don’t survive contact with pragmatism. That said .. 5kLOC is extreme or exaggerated and can’t possibly be reasonable architecture.
I'm questioning the quality of those 10 years to be honest. This is a valid point if it was 500 lines, but 5k is obscene and definitely a point at which you should split whatever it is into smaller logical parts.
If you were to decide to split it up, would you use the lines in each component to help you decide? So instead, of 5000 lines of code in a single element, let's create 100 elements to 50 lines a piece. That's what you would do? That would be lunacy. The number of lines a component has is irrelevant. It's single responsibility and separation of concerns that matter.
Love that you're questioning things, that's always important. On the other hand, you're using the exact same point I've made here in another comment almost verbatim. My point is "you should not use metrics, such as LOC to argue validity, instead separate concerns where it makes sense to do so". Yes, 99% of the time it will make sense to do so well before you reach 5k LOC, however one simply can't judge a function based on how many lines of code it has alone.
The mentioned text should be in in its own file
Strongly disagree, there are tools that help with searching through multiple files like grep
Yup this is a hot take but I think a lot of experienced devs would probably agree. YES, it most likely is an insane component that is just very poorly made. But honestly, sometimes it's also okay. "Learn the rules like a pro, so you can break them like an artist." The distinction, is hard to fully realize so it's better to err on the side of caution. But in the end, the mental model of the architecture is really more important than arbitrary metrics on source code.
Another key point I forgot to mention is, even if the component is badly structured, it's important to think about whether there's any short or long term plans to touch that component, and if not, it's still probably more beneficial to leave it as it is. Refactoring always carries a certain amount of risk and if there's no potential benefit to doing it, it's not trivial to justify.
Aint no way in baby jesus name you would need 5000 lines of code for a single component. What in the mighty fuck is going here ?
Anything above 150-200 lines is pushing it for me.
When I was building my portfolio of projects to get ready applying for jobs, I felt bad because one component had 214 lines, so I broke it down. 5,000 is insane.
On my first ever work as a web programmer the main component of the app was close to 9000 lines. And then, its children were monsters as well. 1000, 3000 stuff like that I had to say that I learnt a lot in that project though. Fun times. But that set of components are untouchable, they work as they work and that's it. They have their own life.
[удалено]
My colleagues do this as well. Some of our codebases have React component files so big I can't even run prettier without VScode freezing. They refuse to learn state management libraries/patterns so to share state between components they end up defining components inside the function body of the main component. And they never useCallback or memo. Just hundreds of useStates and useEffects doing God knows what and hundreds of functions and components getting redefined on every render. They also refuse to use typescript which just makes maintaining all this pasta even worse. I think about quitting every single day but I love my coworkers too much.
# wow single file monolithic program at its best!! 5000 lines of code in a single component is *Anti-React Pattern*. Literally one state change means your are reloading the whole .... & states are not preserved as well ... Tell ur colleagues to learn ReactJs first
I have a rule - cannot be over 100 lines. Especially with functional components and the ability to create and reuse hooks now, there's no way that a component *needs* to be that big. If you follow the single purpose rule, you cannot possibly end up with an abomination like that.
Depends on the component, 5k lines is indeed a bit too much, but you shouldn't take people in the comments with max 100 lines components too seriously either. 1k+ lines components are fairly common if you check meta repos.
That’s what I’m saying, I seriously doubt anyone claiming 100 line max has ever dug through any large enterprise codebases. I can’t imagine what the file tree would look like in that case to support the functionality of serious web software
Yes.
Yes
I think SOLID principles are really important in react. if a component is doing too much it will grow and it's just hard to read and change.
How long is a piece of string? There's just not enough information in the OP to answer the question. People throwing out concrete numbers without knowing anything about the system are cargo-culting at best. If this component is stable and working it would be the apex of stupidity to refactor it solely because it has too many lines. The number of lines in a file is a metric that can be safely ignored. Refactor it if it's hard to do something you need to do.
My max is 100 lines
there’s no reason for a component to be that large. the logic, presentation, and styling can always be broken down and modularized.
Is it a product of a factory function perhaps? Like, a compiled component?
I have one with 400 lines of code rn..I have a strict deadline to meet and no time to start refactoring I feel bad about it..am only shifting components when I need a reusable one otherwise I leave it as it is... Once project is done am obviously refactoring it.
My answer was yes as soon as I read the title lol
Yikes. I wouldn't be able to function in life until that had been broken down into at least 15+ components.
What is the component? Is it a richtext editor or something? Is it just your run of the mill website code?
Divide et impera
Is he defining multiple components in one file or is just one? Sounds stupid either way.
They don't know software fundamentals
This is a bait 🪤
Dude that's too many tokens! how is ChatGPT or Copilot supposed to work with this?! ;)
Yes. As soon as they start to be like 50-60 lines with JSX included you should probably break it up. But even shorter are preferred. Extract common logic to hooks or other components for re-use.
Ridiculous. It's not a hard and fast rule, but if your component is more than 300 lines long you need to start looking at ways to reuse and reduce code
I think it’s extremely unlikely that a 5000 line component couldn’t be broken apart into sub components. That said, technical debt happens with older code; curious what’s keeping folks from breaking it up?
I’m glad we can all agree that it’s wayyyy too much.
I currently have a component with 800 lines and it hurts me...
Yes
If they are saying that this code is best all in this one file because it's only applicable to X, then maybe you guys need to rip it out and either setup your project as some sort of monorepo or make it into an api?
Yes. I would say 5000 lines is too much for anything. Break those down into smaller files.
I always say, goal one: it works. But are there things that could be shared? Split up and tested? 5000 is a lot to read, when it can probably be broken down for your own or other developers sanity.
Unless it's a component that uses canvas for a graphics-intensive app (like drawing or an embedded game). You are for sure doing something wrong. Even in those cases you can abstract and divide code using functions
Yes. That’s unmaintainable and should be broken down into much smaller pieces. There is absolutely no reason to do this. Small, reusable, composable units of code is what I aim for, not only in React, but wherever I write code. It’s much easier to reason about 50-100 lines of code and come back to it a year later than it is 5000. It’s also much easier to test and to extend if necessary.
what in the fuck does this component do? i'm genuinely so curious
Yes
That's rediculous... Way too much
Yes
Why not break it down further with inner components?
The main reason that I would frown on a component that large is that you have a lot of complexity all at the same scope with fewer clear boundaries. An effect generated on line 100 could affect the state on line 5000 or any line in between plus it can cascade, if it was written poorly (the fact that it is 5000 lines would suggest to me that it probably was). I have to understand all 5000 lines to effectively make a change and not do something undesirable. It's like having a lego car that is one lego piece instead of breaking those responsibilities up into modular pieces such as wheels, spoiler, frame, etc.
yes
I've just started refactoring a file I inherited that is about 600 lines with essentially no tests and it's going to take days to get up to standard. 5k lines is mental.
Probably, but the number of lines of code is the wrong way to think about it. Focus more on single responsibility principle.
I thought I read 5000 instead of 500 but I didn't believed my eyes. I had to go to the washroom to wash my eyes for a whole 5 minutes and read again so I'd snap from my half asleep state. Only to realise I wasn't dreaming and it does say 5000
The poor QA engineer
Anyone have a good resource relating to splitting a big component into smaller ones. I wanna see a good example where this is done
It's not about how many lines of code but the function of the component. Why is it that big, what is the specific purpose of this component? Like engine parts, you can always break components into smaller parts as long as it still maintains a functional purpose. So don't think of it in terms of lines of code, but functionality. If it is functional as is, and you cannot split it into more functional little pieces, then that's perfectly fine. Chances are, you'll rarely or never need to do that, and you don't want to, because it's a nightmare to maintain and debug.
In a single file? Disgusting My App component is probably 50k plus lines of code counting the component hierarchy imported into it. But the actual file is like 30-40 lines of code. The only reason not to break up a component over a few hundred lines of code is self-loathing.
Yes.
Yes.
5000 means you should not be allowed in public
We have some contractors who are developing new features and now the regular employees are currently in discussions about how to break up their single 3000 line "components" into multiple components. It's a complicated situation politically, but it's making my job miserable when it should be fun.
This is crazy 🤪
That's not a component that's a thesis on how to not write react.
lol. yes, very stupid. How many things does this code display? It can and should be broken into parts. Every time something changes and the component has to render, 5000 lines are being processed. WHY?
Hmmm ... You can wait till it gets to 10000 ... 5000 is absolutely fine, afterall babel compiles it all to single js file nevermind 🙃
Yes. It’s objectively stupid. This isn’t even a “well it depends” scenario.
Worst components that we used to have before I said ‘fuck it’ were approx 1500 lines. Currently there isn’t a single one with more than 100 lines. Yes, 5k is stupid. Too many issues to list but for sure it’s buggy, not performing very well and hard to work with. Kill it with fire
Yes.
SCA (Single Component Application) is the new SPA.
No matter what language or framework you use, modularity is absolutely important. If you can't break it down to manageable chunks, probably you should spend some time planning out the architecture before jumping into codes.
Yes
wondering how big is the test file for that component
It's a huge codesmell
If they make you write tests for that component just walk out
It makes changes increasingly difficult *or very easy.* Components frequently grow to massive sizes because all of the relevant information is right there and properly breaking it out into smaller components is quite difficult. Imo, if something is 5k lines, then that's ample opportunity to break a lot of it out into easily unit testable pure functions, but I'd also question the performance of commingling so much code in a component that might run a significant portion of that code with each re-render. If there's that much code in a component, then I have to question the design of the component and where that code should actually live. Remember, React is just a View layer that re-renders according to app state changes. If a component has become 5k in size, then there's likely an opportunity to extract a good portion of that state away from the component and to be more selective about what state is actually present in the component or passed in as props and causes it to re-render.
150 lines of import for a fresh start into the file
I hate it personally
I worked on an ember app at work with a couple of thousand lines in each file and it was so anxiety-inducing. I don't even wanna know what 5k lines of code in a file looks like!
It should be broken down and modularized. You don't want to have the problem of detecting bugs and errors on a component with 5000 lines of code. OP, your limited knowledge of react might just be the refresher your colleagues need
What’s worse, a component with 5000 lines of code, or 50 components 100 lines each? Our company has an enormous react application that’s owned by someone who likes to write abstractions for their abstractions for their abstractions. It almost seems malicious how over-engineered it is. I left that team because the development experience was so bad. I’ll take a monolith over an over-engineered clusterfuck of code any day.
Well why not re-render the entire app every time one state change happens?
Looks good to me maybe add some more lines 😉
Your colleagues are stupid
A monolithic component is never a good thing. But usually it’s there at times when there’s too many cooks in the kitchen or no standards have been set on architectural decisions from the beginning.
As Limp Bizkit would say about that component, "Keep scrollin', scrollin', scrollin', scrollin' (c'mon)"
I think it is a bad idea. It would only potentially work if you had orderly components with a very well defined structure that is used in all components. Then you always know what is what inside the component and what to expect. Otherwise, separate logical units into their own component. I'm not an expert, but for me the key is to think carefully about the shape of your data BEFORE you build the component: \- What needs to be global state \- What is the local state to the component that only affects that one component \- What is computed state \- What is server state Structure your component based on that and compartmentalize well the different types of data so that they're easy to identify and are not an entangled mess And then: do not obsess with component reusability. It is easier to change a component if you know that you don't have to handle other use cases in some other part of the app. Also, use typescript. It is WAY easier to work in the code if you can hover over variables and functions and you can get an idea of their type without having to dig in the code for where that is declared or assigned, or having to look for it in the dev tools (I guess you can tell I just started working in a codebase that does not use types)
I’ve worked on a very large codebase where the average component size was around 4000 lines. Yes, it would be nice to have smaller components but it was a very robust and at-scale app, so it did make sense in many situations. Imo ideally you should split a component up when you can, but don’t make it worse on yourself and over complexify things just in the name of componentization.
300 is the hard limit to be honest. ReactJS incentivizes modular structure, break big and complex UI sections into smaller and reusable components/hooks. The larger question that needs to be asked here is, how was the code allowed to be checked in?
Defeats the purpose of component
5000 lines of code are stupid in any file of any programing language and more in a single React component. It's a bad practice of manual.
Jesus Christ why
Bro what. Yes. Very stupid
I personally wouldn't do this; but at the same time, the creator of Elm, Evan Czaplicki, is quite in favor of long files.