Console logs
Delete.
It's important to remove console.log in production code to prevent sensitive information leaks and enhance perform...
For further actions, you may consider blocking this person and/or reporting abuse
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
Great article, thanks for sharing. 👍️
Great article. Do you have a strategy to isolate the useEffect re-renders in a React app to see if they are healthy?
enjoy your posting!🔥
Very well written. 👍
Nice Article! Thanks for sharing
Lucas, would you like to join WebCrumbs? I think you’d be a great addition. (Ps: I’m not a bot, I’m really impressed about the tips you posted here). Cheers!
Thank you for sharing..@
As a fresher it's really great to understand these things.
It will provide broader view
What a well-written content with great tips, thank you.
My questions is, still worth using:
Those are very personal or project specific decisions to take. Their are preferences not good practice. I xan only say that for myself as lately I will go TS + React or Solid and I will always go functional first when writing JavaScript. There are very few exceptions for me to write a Class in FE.
Thanks Raí!
I think you are talking about the reference to the SOLID principle of Single Responsibility.
I updated the post to make it clear: whether you are writing functional or class code.
For good code maintainability, functions cannot be super functions full of logic. It is better to divide them and each one responsible for one thing.
For example, when we make components in React, which are essentially functions, it is also not good practice to create giant components, as the Atomic Design methodology proposes very well.
Lucas, I think you misunderstood my answer to Peter's question as a comment to your post 😉... he'd asked if people prefer to go HTMLX or a JS Framework. I just gave my current preferences of now : React And SolidJS (NOT to be confused with SOLID principles 🙃) .
Also as a preference, I prefer to use Functional first vs OOP when writing JavaScript. This has nothing to do with code quality. BOTH paradigms allow people to write bad code... and BOTH will allow you to write good/maintainable/SOLID code😉.
That will only depend on the entity located between the keyboard and chair. We were not talking about components.
PS: Se olhar pro meu comentário sobre o post vai ver que assino em baixo de tudo que escreveu. Mas espero que você não tenha essa noção que oop é melhor que funcional... idealmente em código funcional as tuas funções são puras, sem mutações e efeitos colaterais. Ou seja muito mais fácil de se atingir o princípio de responsabilidade única 🙂
I feel like those are all questions that need to be debated with the project team. None of them are wrong, they are just different paths that you and your coworkers can take based on the project needs.
Technical decisions Peter! Decisions to do depending on the project, business needs and the team
This is the beautiful of Programming!
If you need type safety you would still need to use typescript, even with jsDoc, but the decision would depend on your project needs prob..
From what I've heard and seen HTMX is good if you want to avoid having a dedicated front-end stack, and just inject a bit of reactivity into your server side app.
Such a great article. Thank you
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?
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.
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.
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.
"Super Components and Functions"
I call them God components/functions, usually, they handle (do) many things:
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.
Great post.
Great post! Should be the beginning of “The Frontend Manifesto” if you ask me!
Good Post. I would like this post. silverbet777 ID