Hello everyone. Welcome to #SundayTechMusings. I know, I haven’t written an article for a while and I’m truly sorry for this. In the previous article, I talked about React folder structure types. In…

Medium_JS is a curated collection of insights and tutorials on JavaScript development, designed to help developers stay informed and inspired in the ever-evolving world of web development. By featuring a selection of high-quality articles, tutorials, and expert opinions from the JavaScript community, Medium_JS offers  guidance on mastering JavaScript language features, exploring modern frameworks and libraries, and solving common development challenges. Whether you're a frontend developer, a full-stack engineer, or an aspiring JavaScript enthusiast, Medium_JS provides a  knowledge and resources to fuel your JavaScript journey.

Medium

This article provides tips and best practices for organizing folder and file structures in React projects. It suggests creating a 'shared' folder for common components, using an 'index.js' file for every component and page, importing files to one file and exporting from it, getting rid of relative path hell, and keeping components length short.

React Folder/File Structure Patterns and Tips: Part 2

What are the tips for folder and file structures in React?

There is this point about keeping components small:
<blockquote>
Keep components length short
Last but not least, I always try to keep my component in maximum &gt;line height. This is for me “200” lines for advanced components. I &gt;always separate big components into small parts.
</blockquote>
This may be good advice, but the problem is that there is no explanation for why you should follow it. So here is my explanation.
First, and probably most important, instead of thinking about lines of code, you should think about component responsibilities. If your component has a single responsibility, then it’ll be 99% fine to keep things together, no matter how many lines of code it is. And in the case of multiple responsibilities, you’ll most likely want to split the component into smaller pieces that are responsible for a single thing.
Separating a single component with multiple responsibilities usually comes with performance benefits. Multiple responsibilities mean multiple reasons for a component to re-render, and sometimes it’s not optimal to re-render the whole component’s UI when a tiny piece of state changed. Having components with single responsibilities, you can expect that the UI is updated when it really needed to be updated
Obviously, it’s easier to work with a component (read/modify) that has a single responsibility. But at the same time, by refactoring such components into smaller pieces you increase cognitive load (it might be nice to read this top-level piece with a high level of abstractions where everything is moved into custom hooks and subcomponents, but it means more pieces to keep in your head when actually making changes and trying to drill down into all these layers of abstraction)
In conclusion, I would say that exceptions are possible in both cases. By separating a component into smaller pieces you increase tree nesting which might have its own performance downsides as well as a single large component can have higher time to instantiation, but I hope that now you have a small framework helping you to decide whether to refactor a component into smaller pieces or not

Thanks for sharing it!! Focusing on writing a component with a single responsibility will automatically reduce your component lines of code without setting a maximum line height.