Live data from Hacker News

Common mistakes writing React components with hooks

lorenzweiss.de

41–50 of 98 posts

Re: Common mistakes writing React components with hooks

#41
post #9
post #8

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.

I read it as "I don't like hooks."

Re: Common mistakes writing React components with hooks

#42

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

Then it's a library, which I stated in my first comment "If you have a website with a couple of React components here and there, then you have React the library.". I'm mostly just trying to point out was seems to be an aversion to the word framework by the react community, when in most cases it is. It's not bad to be a framework, it has loads of benefits, but it's not a bad word that needs to be reviled at all times.

Re: Common mistakes writing React components with hooks

#43
post #9

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

I wondered the same but the text was also confusing so I thought maybe there was something else there.

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

#44
post #33
post #8

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.

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.

Pardon my ignorance, but is prop drilling a problem once you've bought into Redux or similar?

Re: Common mistakes writing React components with hooks

#45
post #4

Nitpick, 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…

There's nothing wrong with ternary operators in my opinion - maybe it's just a subjective thing.

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

#46
post #11

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

With React Native css is commonly mixed with the JS/TS, all in the component.

Re: Common mistakes writing React components with hooks

#47
post #8

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.

While I don't agree that writing a component with a hook is always a mistake, I have seen them used in situations where it wasn't warranted.

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

#48
post #4

Nitpick, 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?

Your code calls a library.

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

#49

Earlier 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…

Can you provide some examples? My experience is that almost any library you end up using is built specifically for React and not vanilla.

Re: Common mistakes writing React components with hooks

#50

The 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…

Yes. The author should replace "This is dangerous" with "This is a tiny bit sub-optimal" in the first example.

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?

Post reply on HN