Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Common mistakes writing React components with hooks

lorenzweiss.de

Post reply on HN
Print view View original

91–98 of 98 posts

Re: Common mistakes writing React components with hooks

#91

Post by jgwil2 »

acemarke wrote: post #90
jgwil2 wrote: post #75

Earlier quoted context omitted.

React's documentation calls it a library but we don't have to. I think the reason people go back and forth on this is that there are a couple definitions of framework out there. A lot of people consider it to be a sort of continuum, where a library becomes framework-like as it adds more and more functionality. I understand that framework can sometimes connote bloat, which is probably why the React docs avoid the term…

React _is_ a framework, because: - You hand it your code and it calls your code when it wants to - Your code must conform to React's expectations. React is _not_ a framework, because: - It only focuses on one thing: defining a tree of UI components. It doesn't include anything for HTTP requests, module definitions, generating expected file structures, or any of the other stuff you'd see in Angular and Ember. - You ar…

They are true simultaneously only if we allow two definitions of "framework" to exist simultaneously. As someone who prefers precise language, I think there should only be one such definition, namely the inversion of control definition.

Re: Common mistakes writing React components with hooks

#92

Post by fendy3002 »

WesleyJohnson wrote: post #81
jordanwallwork wrote: post #37

Earlier quoted context omitted.

Yeah I wasn't sold on hooks at first, mainly because I was having to re-think stuff that I already knew, but man now I'm used to them I'm so much more productive and I absolutely love it

I echo this statement. I use Django a lot for my backends and I was very, very against moving to class-based views. I'm not sure why, I love OOP, but I was so used to function-based views. I finally made the switch (well, I use both when appropriate) and I love them. During this time, I started playing around with React and I thought, I learned my lesson, it's class-based components all the way. Yet again, the commun…

That's not without reason, javascript class is infamous for being weird with 'this' gotchas, and class is 2nd class citizen there (not as good / powerful as one in java). Meanwhile function based view is neat.

However without hooks, only class based component has side effects and lifecycle, so you like it, then made switch to hooks because it's neat.

Re: Common mistakes writing React components with hooks

#93

Post by woutr_be »

dimgl wrote: post #82

Maybe I'm being facetious, but these are remarkably simple (and obvious). Are these mistakes really that common?

I just inherited a React project that was full of these mistakes. The code was littered with "onClick" and "history.push". They used MobX because they wanted a store, even though they didn't need it. Components would often receive this store as a prop, instead of just the values it needed to render.

So yes, these mistakes are very common. There's just quite a few ways to do things, and if you don't do any research, they all have the same outcome.

Re: Common mistakes writing React components with hooks

#94

Post by LorenzA »

pg_bot wrote: post #65
LorenzA wrote: post #57

Earlier quoted context omitted.

not sure i understand you correctly, but keeping all state external just clutters up the store i feel. if the state is not used anywhere else and you also don't need to change it externally i would not move state out of the component. also if your state is always outside of your component they will only be reusable if you hook up the store in all your projects the same way

Nah you can get reusability by creating shared components that you just pass props into. For example, you can have a date picker that just accepts variables to display the current state and parent component that reads data from the store and passes it into the date picker component. This method is also great for debugging, since you can just replay the state transitions over again if there is an application error. If…

a date picker would be super annoying to use if you would have all the state in the store. that are probably 40 variables. assume you open the date picker can can move threw the tabs of the month and you are not interested in changing this from outside.

if you have no state in the component that would not be possible. you can also not wrap this with an other component that can hold this state because you don't want components with state. that means all behaviour that requires state would have the state in the store this will just be crazy

Re: Common mistakes writing React components with hooks

#96

Post by kls »

kristiandupont wrote: post #35
simonbarker87 wrote: post #7

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…

MVC is a popular pattern but it's not the only way to do UI. I don't personally care for it and I am happy that React doesn't force it on me. As for mixing HTML, JS and CSS, I consider that a feature. Why do you want those separated? The reason for me to group code in a file, a folder or at a higher level, in a repository, is that I create a little mental context for what I am going to work on and I want the structur…

> Why do you want those separated?

You don't, there was a time when separation of concerns got mistranslated into separation of technologies and it became an almost religious mantra. But if HTML, CSS, and JS all combined to create a single black box component, that is a single concern, separating the technologies for separations sake only serves to reduce the reasonably of the black box. There are still those that where taught in that time, that separation of technologies and separation of concerns where the same thing, but they are not and that is well evident in that react component are easy to reason about.

Re: Common mistakes writing React components with hooks

#97

Post by kls »

jrvidal wrote: post #44
qudat wrote: post #33

Earlier quoted context omitted.

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?

No it provides helper functions that inject props into your component.

Re: Common mistakes writing React components with hooks

#98

Post by pg_bot »

LorenzA wrote: post #94
pg_bot wrote: post #65

Earlier quoted context omitted.

Nah you can get reusability by creating shared components that you just pass props into. For example, you can have a date picker that just accepts variables to display the current state and parent component that reads data from the store and passes it into the date picker component. This method is also great for debugging, since you can just replay the state transitions over again if there is an application error. If…

a date picker would be super annoying to use if you would have all the state in the store. that are probably 40 variables. assume you open the date picker can can move threw the tabs of the month and you are not interested in changing this from outside. if you have no state in the component that would not be possible. you can also not wrap this with an other component that can hold this state because you don't want c…

You can do it in 3 stored variables
Post reply on HN