React was once a fantastic library. Quick to learn, easy to customize and made it easy for you to write clean code. At least it used to be, at the ...
For further actions, you may consider blocking this person and/or reporting abuse
I really cannot find myself in the premise that the library doesn't take enough work out of its consumers hands, and that the best or even only viable solution is to use some third-part library that does.
The library leaving these things up to us makes it far more reliable and versatile than it would otherwise have been (in fact, I believe it still does too much obscure stuff behind the scenes). React's documentation is also very extensive and explains all these things quite thoroughly.
The problem I see is that many people didn't RTFM (Read The Fucking Manual), and the real solution wouldn't be to immediately direct everyone to a library, but rather to help them understand what's going on like you do in this post.
More people should definitely read the docs. Too often teammates asks "how can you know that" when the answer is "it's in the docs".
I would say it's really important for developer teams to actually get some time for learning the framework they are using.
Lots of developers starts a job without knowing the framework very well. And unfortunately, it takes lot of time to learn it because they only learn from their mistakes and not from the docs :)
Your comment is absolutely correct. There are two different worlds when you learn the framework putting your hands on that and when you learn reading the documentation. I always learned a new technology putting my hands on the work and this attitude has its value, but the point is that the way is very important and you need to care about how the things work. I'm reading carefully the react documentation and I'm very impressed with the new vision that is being created on me about the framework.
Thanks for your article.
Thank you.
I almost never use useEffect with dependencies.
I doesn't matter if it's optimized or not, it leaves room for unnecessary rendering.
It reminds me the catastrophic beahvior on angular1 $watch.
Use a callback anywhere you can.
If you're not putting variables in the dependency array, your useeffect is kind of useless. It probably won't even run the code inside it properly, since when react mounts, any fetched data hasn't loaded yet. So all your fetches will return empty or null. Good luck listening to this completely incorrect article though!
I am using useEffect to wait for the dom to finish loading (once) to do some logic and not as a variable watcher.
I am not sure what you are referring to here.
And Shalom :)
Quote:
"since React unfortunately leaves a lot of the optimization of the code to the developer ..."
For me that's the fundamental problem with React (even though, yes, I'm using React right now on a project, because it was the only viable choice).
Why should frontend devs be concerned with low level optimizations, which the framework can take care of? We should be able to focus on business logic, and UI/UX.
The root cause of the problems is React's programming model of "render always and figure out if something's changed" ... perfect in theory, not so much in the real world.
I'm convinced that frameworks based on Signals will have the edge, it's only React's huge market share that will delay this shift. Funny that "Signals" is now all the rage and a fancy buzzword, while a framework like Vue has had this for ages :)
You are right on yor points. There are frameworks very similar to React as well, such a s Solid.js, which already are a lot faster than React.
However. Faster and better is not enough. React have all these libraries and framework which are based on it, plus all of the developers already knowing it and have it labelel in their resume.
Those things are difficult to beat. It's not easy moving over to another new library where you have to develop a lof ot the things you are used to have from scratch.
Yes, spot on - critical mass, market share, ecosystem, community - all of those make React the 800 pound gorilla (I had to look that up, lol, wasn't sure how many pounds that gorilla was), and "the safe and default choice" in many cases - a bit like, "nobody ever got fired for choosing IBM (or Microsoft)".
P.S. my "use case" was that I was planning to create a mobile frontend, and we had settled on Ionic (which in itself was already a compromise), and I refused to learn Angular (the "default choice" for Ionic) from scratch - so I decided to go with Ionic's React integration ... which brought a host of other "surprises", as Ionic's routing model and "life cycle" turned out to be rather "different" from React's default :)
I don't fully agree with your conclusion, but the explanation and tips are sound 👍
React is great, it has no problems if you know and actually understand how to use it correctly. If you don't like it just use another framework.
Yes, articles like this do not help anyone. Svelte is so far behind if you only knew the details you would learn useEffect.
Exactly.