![Cover image for Best Practices for Writing Clean React Code](https://media.dev.to/cdn-cgi/image/width=1000,height=420,fit=cover,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fo805276a5lqxn6wa9dci.png)
Why is organizing and writing clean React Code important?
Clean code organization is important in React for practical reasons, as well as for its ...
For further actions, you may consider blocking this person and/or reporting abuse
Hey 👋 Hate to be that person. But I don't think this post actually can make people write better React code. People need an explanation of why and how doing the above will make our React code more clean.
Somebody mentioned the examples as well. Although not necessarily, even pseudo code can help.
Another thing, we should really challenge ourselves how much of the recommendations we share is truly a reflection of a real case scenario where such implementation can lead to better software and better user experience and how much of it is just a personal preference.
Rule of thumb, if you can't quantify or measure your clean code principles they are most likely your personal preference. Which is also valuable but it's prone to long and exhausting and never-ending discussions about what the clean code actually is.
In any way, I do agree with most, but I also do recognize that our personal preferences match.
Keep up with the good work 👏
Some explanation has been given. And I think with or without extensive explanation/etc, developers can still share their experiences and thoughts with each other, and it is very useful. It promotes thought and discussion. Me thinks :)
Right.
When writing about best practices, it would be more clear to have code examples 😉
Ctrl + A, then Del. Then rename files to .svelte. 😄
Just joking around. Good tips.
I agree with others. It would be good to get some context of:
As a whole the article doesn't teach or offer any real value. A lot of the "advice" are blanket statements without any real help , teachings or guidance.
I'd perhaps take the feedback on board and add in additional content mentioned above.
Great tips! I also recommend much of the same in this article.
That's nice....
Are comments actually useful though or do they end up doing more harm in the long run? Creating functions, variables, etc. with descriptive names should do enough and require less maintenance. If you have comments and need to change things, now you need to change the names and the comments. I know this isn't a new take, and just goes back to the Clean Code book, but I thought I'd raise the point.
Really good guide.
Thanks.
Nice content, just one small advice will be nice to include some small code snippets :-)
Thanks!:) 👍
I'm just learning programming, but this post is great
This article is largely inspired by ChatGPT reponse (more than 90%). I just tried by tiping the title as prompt, I got almost the same response... What is the point to create a post about it ?
You can say that for a lot of things, and perhaps for the most articles on dev.to. Then what are you doing on dev.to? Just go to ChatGPT instead :o)
I disagree. I think dev.to is a great community and I don't think most of the articles can't be generated only with ChatGPT or equivalent because people usually shared real life experience and opiniated recommandations. That's why people, including myself, are coming here. Also, there is nothing wrong using ChatGPT to create a post and I think it is actually tolerated if you at least be transparent about it... just sayin :o)
Sometimes you need to write beautiful code. Sometimes it's more profitable to write dirty code.
They complement each other. It should be possible to combine both methods.
Blindly following beautiful practices leads to a dead end
I hear others scream at "dirty code": "Technical debt!" Or "Stop! It's refactoring time!" And see the devs dance happy and the project manager is crying because the dirty code was a bad decission for the long run. ^^
By saving time on unimportant details, you can pay more attention to the important ones.
With this method you will save time or be able to solve more complex problems.
My experience shows that if you don’t go to extremes and don’t hold yourself back with barriers, the work will be easier, the speed will be higher, the quality will be higher, and there will always be time for refactoring.
can u please explain me why is that so?
Sometimes you are just fed up with the project manager and just want to f him up in some way or the other.
Jokes apart, sometimes somethings don't work, and you have to go through some kind of work around to make it work, turning your code dirty (written not using best practices).
Unless the OP is a troll, I would guess that's what he's trying to say.
Avoid Complex Component Hierarchies:
-- Fully agreed, as flat as possible. Hierarchies we invent today often do not make sense tomorrow.
Destructuring and Prop Spreading:
-- I'd like to add: minimise the scope of a variable, and minimise the number of variables within a scope.
State Management:
-- I'd like to add: Think "component based programming". Keep everything local (meaning inside the component) and avoid global anything as much as possible, including: data storage, and styling.
Reusable components:
-- I'd like to add: try to make components completely independent of each other. They should not have co-dependencies. Changing one should not break the other. Except for the props of course: that's the contract and the signature of a component.
Hey, let's say I have 2 components and I want to make a third component using those 2 components, is It also comes under Complex Component Hierarchies.
Great article, thanks for it.
Also I could add one more important point -> good naming convention.
Truth is react is messed up structurally. Go to angular you will agree that it's better for frameworks to enforce good practices at framework level. 🤣
Keeping components flat and managing the state of a stateful component with hooks and in functional components is not really that good.