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

Introducing Hooks

reactjs.org

Post reply on HN
Print view View original

91–100 of 310 posts

Re: Introducing Hooks

#91

Post by krapp »

beatgammit wrote: post #9
ggregoire wrote: post #4

While I agree that class components has always felt like a workaround to bypass the limitations of function components, and that it's obviously annoying to rewrite a function component to a class component just to add a state or a lifecycle method, the following explanation sounds a bit silly to me: > In our observation, classes are the biggest barrier to learning React. You have to understand how this works in JavaS…

To be fair, JavaScript has been a moving target and things like classes are quite new. Then again, it doesn't make sense to avoid features just because they're new. I think the point is that they want to provide two ways to do simple things: classes and functions. Functions have better performance, classes are more flexible.

>I think the point is that they want to provide two ways to do simple things: classes and functions.

At the risk of seeming like an old man complaining about new things, what problem would "classes" solve in javascript that the existing object syntax, which allows for inner functions and variables, doesn't?

Re: Introducing Hooks

#92

Post by ergothus »

pg_bot wrote: post #36

I know I may be in the minority here, but I can't say that I'm a fan of this feature. I can't envision a scenario where this would be my preferred solution to any of the problems that they detail. Templates should remain stateless, as they are far easier to reason about that way. My gut reaction is that this is a giant step backward.

Are you referring to hooks in general, or the specific useState hook they showed?

I love the idea of hooks - the more I can isolate my logic, the better. The useState example I'm pretty ambivalent about, for the exact reason you state.

Re: Introducing Hooks

#93

Post by Touche »

needz wrote: post #71
maaaats wrote: post #65

Earlier quoted context omitted.

Why couldn't one just pass in `this` to useState, a key, or something similar? Like, if I have two state variables, pass in a name for both, instead of relying on the order being the same.

It's meant for functional components, not classes.

This doesn't answer the question.

Re: Introducing Hooks

#94

Post by Fellshard »

hliyan wrote: post #15

"You might be curious how React knows which component useState corresponds to since we’re not passing anything like this back to React. We’ll answer this question and many others in the FAQ section." While I appreciate the functional usage of state, this type of magical behavior worries me a bit. Wasn't more straightforward semantics possible (even if the syntax wasn't similarly straightforward)?

This is where I'm falling on it. What started as initial excitement over a lens-like addition started to feel more like black magic once I realized that it relies _a lot_ on implicit ordering just to preserve a seemingly simple usage pattern.

While it may _look_ nice to be able to just call `useEffect` and have it infer the rest, it just ends up masking the flow of a hidden parameter into that component, and convolutes the user's understanding of what React is actually doing.

Re: Introducing Hooks

#95

Post by boubiyeah »

sdegutis wrote: post #88
sadturnip wrote: post #27

> In our observation, classes are the biggest barrier to learning React. As someone who struggled hard with some aspects of learning react, i felt this to be the absolute opposite. Watching people to combine and spread logic over dozens of functional components, and drag in other external libraries like recompose to do stuff like lifecycle hooks, and using HoC's, just to avoid classes makes my head hurt. > Only call…

React is intended to be a view-only library but in practice people shove all their business logic in there, mostly because React makes it incredibly hard to do anything else. Because of this, innovations in React are going in the wrong direction. This Hooks feature is meant to solve a portion of this, but it's going in the wrong direction. A better bigger-picture innovation would be to have a React-alike that is actu…

React was never a view-only library.

Pete Hunt always said he saw React components as mini MVC modules.

it's even less true nowadays with features like Context or suspense to supplement the component states. Redux was kind of a temporary hack.

Re: Introducing Hooks

#96

Post by brlewis »

nine_k wrote: post #78

Well, okay. Preact exists. Even mithril.js isn't completely dead. Sad, though. A framework can afford a lot of technical debt, but adding more conceptual debt, like React was doing recently, seems to me like a road to oblivion^W legacy status. Features that lack clarity and come bundled with footguns tax developer's brain resources, and increase the rate of errors. These are some of the most expensive resources in IT…

> Even mithril.js isn't completely dead.

That's a rather un-generous description of a framework under active development with an active community.

Re: Introducing Hooks

#97

Post by lexicality »

Oh great. Another React feature that relies on creating anonymous functions every time your component renders.

I presume this is now adequately fast in the various JITs in use, because I seem to remember this being one of the major bottlenecks React developers were instructed to avoid doing at all costs.

Re: Introducing Hooks

#98

Post by renke1 »

baddox wrote: post #5

This is interesting. I'll have to spend some time mulling over this before the benefits sink in. It seems like a much more confusing and less composable API than recompose, which is how I add state, lifecycle, and other React class features to functional components. I've been completely avoiding React classes for a while now and using stateless components with recompose for over a year now, and I find it to be a wond…

Recompose is not really compatible with TypeScript (no clue about Flow). Render props are a good alternative but the nesting made composing a bit cumbersome. Hooks are easy to type and compose quite fine it seems.

Re: Introducing Hooks

#99

Post by emmanueloga_ »

Looks like the default way of writing react components in ClojureScript (with Reagent [1]). Compare:

CLJS, Reagent:

    (def click-count (r/atom 0))
    (defn counting-component []
      [:div
       "The atom " [:code "click-count"] " has value: "
       @click-count ". "
       [:input {:type "button" :value "Click me!"
                :on-click #(swap! click-count inc)}]])
JS, React + Hooks:

    function Example() {
      const [count, setCount] = useState(0);
      return (
        
          
You clicked {count} times

           setCount(count + 1)}>
            Click me
          
        );}
Not sure about the name "hooks". Trying to figure out why they name them like that.

1: https://reagent-project.github.io/

Re: Introducing Hooks

#100

Post by sdegutis »

boubiyeah wrote: post #95
sdegutis wrote: post #88

Earlier quoted context omitted.

React is intended to be a view-only library but in practice people shove all their business logic in there, mostly because React makes it incredibly hard to do anything else. Because of this, innovations in React are going in the wrong direction. This Hooks feature is meant to solve a portion of this, but it's going in the wrong direction. A better bigger-picture innovation would be to have a React-alike that is actu…

React was never a view-only library. Pete Hunt always said he saw React components as mini MVC modules. it's even less true nowadays with features like Context or suspense to supplement the component states. Redux was kind of a temporary hack.

I distinctly remember the phrase "V in MVC" being prominently displayed somewhere on the official React website(s).

Found it: https://web.archive.org/web/20140329114924/http://facebook.g...

> JUST THE UI

> Lots of people use React as the V in MVC. Since React makes no assumptions about the rest of your technology stack, it's easy to try it out on a small feature in an existing project.

So I was mistaken. It didn't say that's what it's only intended for, but that's what many people use it for.

Either way, it's not great at the M or C parts of MVC. Context does very little to ease that pain. Redux was more manageable but also overly complex, but it's only React's design that forced it to be so complex.

Post reply on HN