React long Components

I'm a front-end developer with almost 4 years of experience, working mostly with React. Today I wanted to practise and build a Select Component in React. I was looking for some inspiration and found this:

• react-select
• downshift

These components are +1000 lines of code long (and I know there are more examples out there, and not only involving Select Components).
I'm a pessimist so I think I'm just bad at this, but I have some hope that maybe they're doing something wrong. How could anyone (for contributing or debugging reasons) read all those lines and understand everything that's going on?
What do you think?

Comments

[Oleh Ziniak]

I believe in huge open-source projects lots of lines just cover some Github issues and edge cases that you would rarely need to cover in your app. But most definitely there are going to be some edge cases you would definitely need. And you'll find them in a hard way. So the thing is you will never know for sure what exactly you need in advance.

[Spyros Argalias]

Yeah, I think this is the right answer.

If you were making your own component, it would be a few lines long to do what you needed.

If you are making a component that the entire world uses:

• It must be general enough to be useful to a ton of use cases.
• It must cover every edge case it could possibly encounter.
• It must be performant, and sometimes making things performant makes code very complicated.
• It must not have security vulnerabilities (although front end has it easier here than back end).
• TypeScript
• Accessibility.
• And anything else you could think of.

It's normal to not understand anything that's going on at first when looking at projects like those :).

[Ryan Kahn (he/him)]

Lines can be a noisy way to look at the complexity of a module or component. I'd look at the complexity first in terms of:

• Dependencies: How many other modules does this module import. How many components does this component utilize?
• Then Branches and Blocks and Statements: How much of the logical weight does this component lift?

What you'll find is that the two work inversely to each other, and that by breaking up a component into smaller functions (hooks, components, utils, ect.) you increase the dependencies that code needs to work.

There is a way to handle both of these concerns simultaneously, and that is to write more generalized code. This allows you to break things up without introducing as many explicit dependencies between things. This introduces another measure of complexity though:

• Abstraction: I'll just put this as "Patterns which aren't explicitly in the code".

The way to handle this axis of complexity is to put more into the code, like using TypeScript over JavaScript, or writing unit tests. You can also document abstractions, but this can get out of date, and so being careful about introducing abstract ideas into the code is usually helpful.

That's just my thinking, and I'd have to look at an example to have a solid opinion whether 1000 lines of code is the right balance of all these ideas. Share a link and I'll skim it!

[Ryan Kahn (he/him)]

I didn't see the links in your post! So here's what I would say briefly. If you look at react select for example:

• Dependencies: This component has very few dependencies
• Logical Weight: This single component lifts a lot of logical weight, and I see methods and things that could be standalone functions or components.
• Abstraction: This is heavy on abstraction (it defines a component class, which is a huge abstraction), but the use of TypeScript puts more of that machinery in code.

Would I break this up into more modules? I think that would depend on the time available, but ideally I think it could have more dependencies at the benefit of being less individually complex in my opinion. Hope that helps!