Console logs
Delete.
It's important to remove console.log in production code to prevent sensitive information leaks and enhance performance.
Console errors and warnings
Investigate and fix.
It's important to address console errors in production code to maintain a smooth and error-free user experiences.
Any in TypeScript
Do the correct typing.
Using any in TypeScript should be minimized in favor of explicit types to enhance code reliability and maintainability.
Comment unused code
Delete.
Commenting out unused code is bad practice as it clutters the code, hinders maintenance, and may lead to outdated comment information.
Super Components and Functions
If your component is large, the time has come to divide it into smaller components.
Think about the good old principle of SOLID called Single Responsibility.
Whether you are writing functional or class code.
Rewrite CSS multiple times
For the love of Ada Lovelace, Alan Turing and Tim Berners Lee...
Don't rewrite colors, fonts and sizes repeatedly, use design tokens to your advantage, create global CSS variables or use libs.
Talk to your team about the advantages of using design tokens.
Flags to ignore Linter
Example: use /* eslint-disable @typescript-eslint/no-unused-vars */
Fix your code.
Don't send Pull Requests with linter errors.
If you really need to ignore, think carefully about which linter warnings you can do so.
Re-renders and loops consuming to many resources or crashing
Example: JavaScript loop functions or useEffect in React poorly applied.
This may cause infinite repetition in API calls or values that can overflow memory and crash your application.
Fix your logic.
- Note: your application runs in the browser and consumes limited end-user memory resources.
Business rules on the Frontend
Do not place and do not allow.
It is commonly agreed that any Frontend application cannot have business rules, only rules inherent to the user interface, for interaction and the user's successful journey.
Frontend is the client, not the server.
Large companies and enterprise-level applications adopt the practice of not exposing their business rules and data processing on the Frontend, placing them on the Backend.
- Note: for simple, serverless web applications or those that consult third-party APIs, it may be necessary to place some business rules in the Frontend - being careful not to expose sensitive or very costly processing to the client.
Culture of not testing
Make tests happen on your codebase. No code is perfect.
Unit, Integration, Security, UX, Performance and Accessibility Tests. Use testing tools to generate error reports and improvements to correct your application.
Example: Cypress, Lighthouse, SAST in the deploy pipeline, etc.
Work in partnership with the UX, QA and Cybersecurity/Pentest teams if they exist on your company.
Fear of communication
You are a human.
Please, whenever you are stuck, call another Dev or Technical Lead to share the problem you are facing.
Problems are solved faster through pair programming and thinking together!
Remember: They were once in your position and will help!
I hope you enjoyed! 😃✌🏻
Do you have any more TIPS?
Support my work ☕️ Buy me a coffee
Top comments (48)
The article is very well-written.
However, I think there are some exceptions to the Flags to ignore Linter.
For example, there are issues where ESLint errors are generated even though some function type declarations are not function implementations.
Thanks for this contribution Yeom, you are right! Sometimes the Linters go on crazy mode haha
Yes. There are exceptions and for those we can easily disable the linter message. But as a general rule I have my linting preferences in the global eslint json so whenever I really need to disable something is for a very good reason.
If you do Code-Reviews then make it a rule to always discuss overrides/ignores with the reviewer. If the Reviewer also is fine with it, it is okay. If not, then the reviewer and you will find a better solution.
Great post. I would also add to your point about minimising the use of the
anytype by suggesting the use of theunknowntype when more flexibility is needed without sacrificing type-safety. I wrote a great blog post explaining the difference between unknown and any in TS.Thanks for sharing your article Rajae!
Learning about the
unknownof TypeScript is really importantNow it's well known :)
😄
Just read 3 of your blogs. You’re a good writer. Well done with the amazing job.
Thank you!
"Business rules on the Frontend"
I have known this. However, in anticipation of the burden of the server to process complex computation, I did compromise. The backend still did its function for processing data and did complex computation, but I handed the final computation to the frontend for the following reasons :
That being said, I realize this practice cannot be allowed, as some sensitive business rules can be seen by users in the browser.
Very well observed Alexander!
Placing business logic and data processing in the Frontend is a decision in your product's architectural strategy. We must do it carefully...
I updated the post with this observation. Thanks.
I believe the only thing that we can rely on the client to process is rendering the data, that's why we have all of the front-end frameworks today, and it sort of makes sense for the client to just get the instructions and produce the visuals, and the backend still has all of the core logic, ex: creating accounts, processing transactions ...
Great article, I would just add some color to it :D maybe some icons to every point to make it stand out 😀
Yeahp! Pretty much this! ♥️
I found interesting the no-use of comments in order to "delete" code, I'd say that there might be a way to "comment" the code without deleting it by using git. Saving the changes after makimg them, so if they don't work, we could get back.
Cool, Exactly I need this type of help at this moment. Big thanks man
great article
Helpful article 👍
I love articles like this. Clear and straightforward. Thanks