Introducing Hooks • Hacker News Board

Re: Introducing Hooks

#51

Post by lacker » Thu, Oct 25, 2018, 7:18 PM UTC

eric_b wrote: post #41

There are a lot of gotchas with these. Don't call in conditionals, branches, loops. Can only be called from function components. Order of invocation matters (yeck!) If the goal is helping developers "fall in to the pit of success" I think classes are a much better option than this.

There are a lot of gotchas with the object-oriented way of doing these things too. Don't set `this.state` directly, don't forget to keep your side effect logic in `componentWillMount` parallel to your cleanup logic in `componentWillUnmount`, et cetera.

Re: Introducing Hooks

#52

Post by scrollaway » Thu, Oct 25, 2018, 7:19 PM UTC

nyclowkey wrote: post #50

scrollaway wrote: post #11

Earlier quoted context omitted.

Care to write a substantial contributing comment, or do you intend to keep this random complaint about the simplification of a common pattern in React as shallow as possible? Edit: No really, I'd like to hear why you think this would make React a "clusterfuck mess" rather than... simpler.

I agree React is turning into a clusterfuck mess.For evidence look at the pull requests https://github.com/facebook/react/pulls?q=is%3Apr+is%3Aclose... Even the developers have no idea WTF is going on.

You're not showing me anything of note here. Is this some low key trolling or am I missing something?

Re: Introducing Hooks

#53

Post by pcmaffey » Thu, Oct 25, 2018, 7:19 PM UTC

I think this is a really positive solution to creating a streamlined functional api.

However, in its simplicity (and hidden magic), I fear that it won't encourage junior devs to understand what's actually going on, and thus may lead to bad code (eg monster components with lots of side-effects running on render).

In a way, this reminds me of MeteorJS, which was awesome for new devs getting up to speed with a powerful JS environment under the hood. However, by internalizing much of that power, it became too closed off, too difficult to build and compose new patterns around. And is now mostly irrelevant. Not saying that's React's future (I'm all-in on React and excited for this), just a concern / thought.

Re: Introducing Hooks

#54

Post by scrollaway » Thu, Oct 25, 2018, 7:20 PM UTC

nyclowkey wrote: post #44

eric_b wrote: post #41

There are a lot of gotchas with these. Don't call in conditionals, branches, loops. Can only be called from function components. Order of invocation matters (yeck!) If the goal is helping developers "fall in to the pit of success" I think classes are a much better option than this.

yep I see nothing wrong with classes, infact I think I'm going to go back to an older build of React. All this suspense, the messy fiber rewrite and all is just screwing up library. LONG LIVE class based component, there was nothing wrong with them. Don't fix it if ain't broke.

Good thing then that, as the page says, "There are no plans to remove classes from React.".

Re: Introducing Hooks

#55

Post by btown » Thu, Oct 25, 2018, 7:20 PM UTC

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…

You also can call functions that call functions that set up hooks. What if those functions have control flow? Must we build linters that recursively taint any hook-touching code segments?

Since Fiber, React has become difficult to reason about. There is a stateful crawler that is going up and down and sideways in your hierarchy, running code with side effects and telling you that it will isolate those side effects. The golden brick road is surrounded by briars, because you cannot know the nuances of that renderer’s contracts, because you cannot read the code of that renderer, because it’s too dense to understand. I miss the days when React was a simpler “dive” than Angular in this regard, and I could boast about its simplicity. In the interest of efficiency, we have forgotten how to climb the walls of our garden.

Re: Introducing Hooks

#56

Post by wichert » Thu, Oct 25, 2018, 7:21 PM UTC

lacker wrote: post #49

This looks like a nice but not enormous improvement to React. First, I really like how these hooks are optional. You can still use the current class-based mechanisms wherever you want. Existing code will keep working the exact same way. For the specific hooks they provide: `useState` seems like a slight improvement over using `this.state`, at least for simpler use cases. You save about 5 lines of object-oriented setu…

I can see the benefit being enormous if you use typescript. Currently it is often a struggle to come up with the magic combination of generic parameters and HoC ordering to make things work, which might still fail if your HoC has an incomplete typing specification. Using a couple of very simple easily typed functions makes things much easier to reason about and to specify correctly.

Re: Introducing Hooks

#57

Post by maaaats » Thu, Oct 25, 2018, 7:23 PM UTC

> React doesn’t offer a way to “attach” reusable behavior to a component

I know the angular resentment here is high, but some things Angular 1 got right. Directives added as attributes to another component was very powerful and allowed this in better ways than HOCs in React. Im looking forward to try this out.

Re: Introducing Hooks

#58

Post by CuriouslyC » Thu, Oct 25, 2018, 7:23 PM UTC

oldboyFX wrote: post #38

rhacker wrote: post #26

Earlier quoted context omitted.

I feel like Redux was a clusterfuck mess and this is the cleanup. Excuse the language. Edit: Expanding on this and why (I think) this solution is cleaner: * In redux you ended up with pointless constant piles of strings that are the named actions. Totally useless in a JS world where a function that IS an action can take up that mantle. * While reducers are a good way to make state consistent, using redux for state ma…

People use Redux way too often and think of features like time travel as nice-to-haves, when in reality they're the main reason why you'd want to use Redux in the first place. Using Redux just to simply set and get data on every page is an overkill. For the majority of applications making API calls directly from the component and storing data in the comp state is the way to go. This is coming from someone who used re…

What do you do when you want to update state in other places in response to a change in a component? How about if you want to make your component's state persistent (particularly when the component is external to your project)? Also, what do you do to generate state dumps for error reporting?

Re: Introducing Hooks

#59

Post by sergiotapia » Thu, Oct 25, 2018, 7:27 PM UTC

So adding class lifecycle events to functional components? Why not just use a class?

The beauty of the functional components is that immediately you know there's ZERO state in here. It's just rendering markup based on input.

Now there's more to look out for given this `hook` thing. I don't like it.

Re: Introducing Hooks

#60

Post by eknkc » Thu, Oct 25, 2018, 7:27 PM UTC

I’d say the useState hook should receive a name parameter first and not depend on the call order. That way one can do branching, loops etc. This way it feels like too much magic.