DEV Community

Cover image for Don’t do it on Frontend or... Frontend good practices for devs
Lucas Menezes
Lucas Menezes

Posted on • Updated on

Don’t do it on Frontend or... Frontend good practices for devs

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)

Collapse
 
artxe2 profile image
Yeom suyun

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.

Collapse
 
lucasm profile image
Lucas Menezes

Thanks for this contribution Yeom, you are right! Sometimes the Linters go on crazy mode haha

Collapse
 
raibtoffoletto profile image
Raí B. Toffoletto

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.

Collapse
 
htho profile image
Hauke T.

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.

Collapse
 
rajaerobinson profile image
Rajae Robinson

Great post. I would also add to your point about minimising the use of the any type by suggesting the use of the unknown type when more flexibility is needed without sacrificing type-safety. I wrote a great blog post explaining the difference between unknown and any in TS.

Collapse
 
lucasm profile image
Lucas Menezes

Thanks for sharing your article Rajae!

Learning about the unknown of TypeScript is really important

Collapse
 
iamtahazzot profile image
Tahazzot

Now it's well known :)

Collapse
 
rajaerobinson profile image
Rajae Robinson

😄

Collapse
 
emmaccen profile image
Lucius Emmanuel Emmaccen

Just read 3 of your blogs. You’re a good writer. Well done with the amazing job.

Collapse
 
rajaerobinson profile image
Rajae Robinson

Thank you!

Collapse
 
lexiebkm profile image
Alexander B.K.

"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 :

  1. It can leverage the processing power of the client computer.
  2. It may reduce the burden of the server, especially when a large amount of users are accessing the web features that need computation concurrently.
  3. Using javascript for certain computation is more convenient than the language I use in the backend.

That being said, I realize this practice cannot be allowed, as some sensitive business rules can be seen by users in the browser.

Collapse
 
lucasm profile image
Lucas Menezes

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.

Collapse
 
dsaga profile image
Dusan Petkovic

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 ...

Collapse
 
dsaga profile image
Dusan Petkovic

Great article, I would just add some color to it :D maybe some icons to every point to make it stand out 😀

Collapse
 
raibtoffoletto profile image
Raí B. Toffoletto

Yeahp! Pretty much this! ♥️

Collapse
 
master_aless profile image
Jhon Alessandro

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.

Collapse
 
bpinazmul18 profile image
Md Nazmul Haque

Cool, Exactly I need this type of help at this moment. Big thanks man

Collapse
 
ikuol profile image
Orphée SOGBOHOSSOU

great article

Collapse
 
kralion profile image
Brayan Paucar

Helpful article 👍

Collapse
 
as profile image
Amir Salehi

I love articles like this. Clear and straightforward. Thanks

Collapse
 
ehrbhein profile image
Irvin Gil

Great article, thanks for sharing. 👍️

Collapse
 
matkwa profile image
Mat Kwa

Great article. Do you have a strategy to isolate the useEffect re-renders in a React app to see if they are healthy?

Collapse
 
ghulam46 profile image
Ghulam Ammar Yanuar

enjoy your posting!🔥

Collapse
 
codeguage profile image
Codeguage

Very well written. 👍

Collapse
 
femi_akinyemi profile image
Femi Akinyemi

Nice Article! Thanks for sharing