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
Latest comments (46)
Great post! Should be the beginning of “The Frontend Manifesto” if you ask me!
"Super Components and Functions"
I call them God components/functions, usually, they handle (do) many things:
Great post, although would love to know till how deep should we follow Single responsibility principle meaning if my component is doing lets say 10 things , is it really needed to break it into 10 components?
If your component has 10 different behaviors is super okay. Now if your component performs 10 completely unrelated functions, it may be confusing for other developers to understand this, even on the future. Think about it.
Currently I am learning React with JavaScript but I noticed that big projects are based on typescript. What you say about it? So I may switch?
Your response will be appreciated. I'm begginer want to get in development 🤝
Hey Fezan, welcome!
Good luck in your studies!
You are right. To better understand why large teams use TS, I strongly recommend that you read my post "TypeScript Documentary".
Link: dev.to/lucasm/review-of-typescript...
*** Watch the documentary video, the React team and the creator of TS appear there.
Good Post. I would like this post. silverbet777 ID
Great post.
Cool, Exactly I need this type of help at this moment. Big thanks man
great article
Great article, I would just add some color to it :D maybe some icons to every point to make it stand out 😀
I don't agree with your take on business rules. There are many legitimate cases where business rules on frontend are perfectly fine and actually preferable to server-only model, given one still validates on backend as well where needed. Take apps that have to work offline like Notion. How would they work offline if all the logic was placed on backend?
I think whats meant here is the core business logic needs to be on the backend, as you don't want these kinds of things to be left to the user, like some crucial calculations that you want to be precise about (things you don't want the user's machine to handle because the results may not be consistent or reliable)
I think that was the author's intent as well, but it's still important to stress out the "it depends" message, because dogmas are rarely a good guide.
That's right Daniel. It depends on your needs.
I tried to make this clear in the post. Generally, beginner Devs tend not to realize the difference between placing excessive processing on the Frontend and doing this as a mature product decision.