I would argue that writing a React component with a hook is a mistake. There is usually an easier/clearer way to solve the problems that hooks are intended to solve with the existing React primitives.
Can you explain what you mean by that? I'm honestly a little lost on what you're saying but I am curious.
Common mistakes writing React components with hooks
41–50 of 98 posts
Re: Common mistakes writing React components with hooks
#42Earlier quoted context omitted.
Whether or not they are different libraries doesn't matter. Once you've done any real development with them good luck trying to take out your small, simple library and replace it with another. Why are so many React devs so against the word framework, it's like they treat it how many treat monolith "It's a bad word we can't be compared against, even when you can't tell us apart"
Well I sometimes use react to replace a component, such as develop a button which needs to be clicked twice to submit just by simple state management. Though I don't know if it still can be considered as framework or not.
Re: Common mistakes writing React components with hooks
#43Earlier quoted context omitted.
Can you explain what you mean by that? I'm honestly a little lost on what you're saying but I am curious.
I read it as "I don't like hooks."
At least for me hooks dramatically clean up the code.
Outside of error boundaries (I think those still have to be classes) any new component for me is a function component and if it needs state, has hooks.
Granted I still maintain a lot of class components back from before the days of hooks.
Re: Common mistakes writing React components with hooks
#44I would argue that writing a React component with a hook is a mistake. There is usually an easier/clearer way to solve the problems that hooks are intended to solve with the existing React primitives.
I get what you're saying but disagree. Hooks are essential and make life much easier for the react developer, especially when using something like `react-redux` or `react-router`. Prop-drilling or HoC might seem like a better design until you actually have to work in a system that leverages them and realize it's an indirection nightmare.
Re: Common mistakes writing React components with hooks
#45Nitpick, but React is not a framework, it's a library. People miss this point often eg when they compare React to Angular
I think this is an important nitpick though in your defence. I have just started learning React having become pretty competent with Angular (day job plus some hybrid apps) and I have to say that I'm struggling to understand its popularity compared to Angular. Angular feels fully fleshed out, adheres to MVC mostly and has nice separation of html, css and the UI TS code. I come from a native coding background so this f…
Most interesting thing in React for me is the ability to pass an element as an argument to another component - it's impossible in Angular. I’m not sure there is a lot of real-life cases for this feature, but still, I’m impressed by this level of flexibility.
React isn't just V of MVC, it's VC at least, letting you write your models wherever you want (pure js functions? classes - go ahead).
Some advantages of React are the weak points simultaneously - ngModel, ngIf, ngFor - they are removing a lot of boilerplate you have to write in React.
Re: Common mistakes writing React components with hooks
#46Earlier quoted context omitted.
I think this is an important nitpick though in your defence. I have just started learning React having become pretty competent with Angular (day job plus some hybrid apps) and I have to say that I'm struggling to understand its popularity compared to Angular. Angular feels fully fleshed out, adheres to MVC mostly and has nice separation of html, css and the UI TS code. I come from a native coding background so this f…
I don't see why the CSS is mixed with the rest. It clearly isn't. Mixing JS and HTML doesn't seem problematic to me.
Re: Common mistakes writing React components with hooks
#47I would argue that writing a React component with a hook is a mistake. There is usually an easier/clearer way to solve the problems that hooks are intended to solve with the existing React primitives.
In the end, they are just another tool -- knowing how to use the tool appropriately is the critical part.
Re: Common mistakes writing React components with hooks
#48Nitpick, but React is not a framework, it's a library. People miss this point often eg when they compare React to Angular
What is difference between a front-end library and a front-end framework?
A framework calls your code.
Really great explanation here: https://stackoverflow.com/posts/15600924/revisions
Edit: another really nice exposé here: The Difference Between a Framework and a Library — https://www.freecodecamp.org/news/the-difference-between-a-f...
Re: Common mistakes writing React components with hooks
#49Earlier quoted context omitted.
I think this is an important nitpick though in your defence. I have just started learning React having become pretty competent with Angular (day job plus some hybrid apps) and I have to say that I'm struggling to understand its popularity compared to Angular. Angular feels fully fleshed out, adheres to MVC mostly and has nice separation of html, css and the UI TS code. I come from a native coding background so this f…
To me, the killer feature of React is how easy it is to mix with standard "vanilla" JS libraries. The "React" version of a library is usually a fairly trivial wrapper around the "normal" version. In contrast, integrating with Angular is a lot more involved and is in effect its own ecosystem. The other thing I can't stand about Angular is that it puts its proprietary templating language "in control" of components. Whi…
Re: Common mistakes writing React components with hooks
#50The first one just feels like a premature optimization. Yes calling setCount forces a rerender of that component, but unless there's lots of subcomponents inside that component, I wouldn't bother. Chances are later you'll need that state in the view, and if you have "unexpected side effects" from rerendering then that is the problem. The other tips are fine; effects should have a single responsibility and links and b…
EDIT: "This is dangerous" is also the wrong label for the 2nd example. Should be "This is not the cleanest way"
EDIT2: "This is dangerous" is also the wrong label for the 3rd example. Should be "This is not the most readable". I'd also note that I'm surprised the author has seen this mistake a lot; the "solution" looks like the happy path most people would follow in the first place.
EDIT3: "This is dangerous" in the 4th example should be replaced with "This could be simplified"
EDIT4: "This is dangerous" in the 5th example should be "This makes redundant API calls". I'd also note that I'm surprised this example is even included. How could anyone miss that fetchData() is being called every time updateBreadcrumbs() is called?