Live data from Hacker News

Introducing Hooks

reactjs.org

281–290 of 310 posts

Re: Introducing Hooks

#281
post #250

Earlier quoted context omitted.

I can't speak for GP, but have used angular up through 4.x (not quite current) and don't find it better than React's ecosystem imho. With React I can often bring in additional components and libraries without friction. With Angular it feels like doing anything means significant friction. And heaven help you if you want to change the way something internal works, or work around things.

I can’t say I’ve had that much trouble bringing in third party libraries, nor have I had a need to change how the framework works internally. I think this is the same as with most frameworks, you tend to just use them rather than doing stuff under the hood. Can you give an example?

At this point not really... it's been over a year since I've had to really worry about it. It was better using angular-redux or ngrx, but still was a weird experience. When you have eventing issues with RXJS, or handling integration with other libraries, it's definitely not as broad or mature as the React space is. Anything from chartjs to color pickers, I'm trying to recall the last big issue I had in an angular app. In the end, I just remember pain all along the way more than most specific examples.

Oh yeah... drag-drop integration... that was the single biggest pain. None of the component libraries worked well, and doing it manually was harder than I've experienced before, including just straight JS, and definitely worse as a whole than using say jQuery-UI.

If it were a year or more ago, I could cite better examples of pain points. 2+ is better than 1.x, but still horrible. I'd rather see people adopt Vue over Angular. I still prefer a react-alike over any of them.

Re: Introducing Hooks

#282

Earlier quoted context omitted.

> React assumes that if you call useState many times, you do it in the same order during every render. Note they also say: > We provide a linter plugin to enforce these rules automatically. Makes me feel a little better.

I doubt the linter will enforce the same-ordering, that would require state between runs. I think the linter just ensures hooks are run at the top level in the functional component.

And it wouldn't need to. You're free to move around calls to useState() to your heart's content in your code, you just need to call them in the same order during the lifecycle of your component.

Re: Introducing Hooks

#283

Earlier quoted context omitted.

> A class is something everyone can read and understand. This is simply not true. Your post is very strange, you just assume classes are simple and boring but everything else is 10-20 files with fancy magic and blah blah blah. The truth is that Dan is wrong about what makes code boring. Immutability is boring. Dan just likes Go.

A class has all the related code in one place in one file (some languages excepted, base classes excepted, but true enough for React purposes where inheritance hierarchies are quite limited and rare in my experience.) I like immutability. It can make code easier to read and understand if done well. But within reason. It's not that I'm creating some strawman where the alternative to a class is 10-20 functions across a…

[deleted]

Re: Introducing Hooks

#284

Earlier quoted context omitted.

I'd agree it's "magic" in the sense that it's not entirely visible to the end user. But, the key is that React is _already_ tracking _which_ component it renders as it traverses through the component tree. It's just now also keeping track of some additional data as it goes through the process of rendering that component. So in that sense, it's not any more "magical" than any of the existing render algorithm.

The problem is that the hooks seem to be much more restricting than setState. You can `if (condition) this.setState({x: 1})` but you can not with hooks because React keeps track and doesn't allow you to break out of a very narrow usage. Look at the rules from the docs: > Only call Hooks at the top level. Don’t call Hooks inside loops, conditions, or nested functions. > Only call Hooks from React function components.…

I think it's best to treat the various hooks the same as method definitions: you wouldn't conditionally define componentDidUpdate or componentWillUnmount in a class component. Instead, you would conditionally do something within those (always-present) functions. The same applies for these hooks.

Re: Introducing Hooks

#285

Unpopular opinion: There are too many cooks. I used React two years ago because the API was tiny, simple and elegant. They are adding new API features left and right, and the framework feels very uncoordinated now. The surface area is way bigger than it needs to be. This is my cue to finally explore other frameworks.

I agree with you, but I've also tried other frameworks and there isn't a single one that is all-around better than React. Unless you're willing to migrate to other compile-to-js languages.

es6 (with babel) is already effectively a compile-to-js language

Re: Introducing Hooks

#286

Earlier quoted context omitted.

> and using HoC's, just to avoid classes makes my head hurt I don't know if it's just something I don't see that often and aren't that familiar with, but I also can't stand the overuse of HoC's for this purpose. Seen some very clever and very, very unreadable HoC's so far and I hate working on codebases that use them liberally.

I think it depends on the use... I think some can be ugly... right now react-loadable and a custom InRoles component are the two I'm using the most. One is for loading state and code-splitting, the other is for allow/deny state... } deny={'/route' /* or a render, or skip */} /> InRoles works for a router redirect, displaying alternate content or no content. In the end it depends on what you're trying to accomplish. H…

I think the HoC's that get me the most are the ones written by JS devs who think 100% functionally. Actually a lot of the hard ones to grok were written by Jason Miller of the Preact fame, who seems to think out JS in a minified, functional fashion. I've had to step through and re-write several things just to see what was actually happening, then pare it back to it's original form before I "get it". It's super clever, but man did it take me a while to distill it's logic.

Re: Introducing Hooks

#287
post #227

Earlier quoted context omitted.

Just a FUCK-TON of boilerplate :P

People use the word "boilerplate" a lot, but everyone seems to have something different in mind when they say it. What specific concerns do _you_ have? I'm a Redux maintainer, and I'm always happy to try to help offer possible solutions.

I don’t really think there is a way around it if you go with the action/reducer/saga model.

I enjoy my code fairly explicit, so writing a button click that invokes some request has me writing:

- A click handler

- 3 new action name consts (request, success, failure)

- An action instantiation function that takes the necessary arguments for request.

- A saga function that catches these request actions, runs a request, and invokes the success action/failure action depending

- 3 handlers in my reducers. One for every action.

It all adds up if you have a ton of buttons :P

Re: Introducing Hooks

#288
post #287

Earlier quoted context omitted.

People use the word "boilerplate" a lot, but everyone seems to have something different in mind when they say it. What specific concerns do _you_ have? I'm a Redux maintainer, and I'm always happy to try to help offer possible solutions.

I don’t really think there is a way around it if you go with the action/reducer/saga model. I enjoy my code fairly explicit, so writing a button click that invokes some request has me writing: - A click handler - 3 new action name consts (request, success, failure) - An action instantiation function that takes the necessary arguments for request. - A saga function that catches these request actions, runs a request, a…

This is exactly the thing we need fixed. I get that Angular has one way of doing it, but I still feel like it's going in the wrong direction (too Java-like).

Re: Introducing Hooks

#289
post #287

Earlier quoted context omitted.

People use the word "boilerplate" a lot, but everyone seems to have something different in mind when they say it. What specific concerns do _you_ have? I'm a Redux maintainer, and I'm always happy to try to help offer possible solutions.

I don’t really think there is a way around it if you go with the action/reducer/saga model. I enjoy my code fairly explicit, so writing a button click that invokes some request has me writing: - A click handler - 3 new action name consts (request, success, failure) - An action instantiation function that takes the necessary arguments for request. - A saga function that catches these request actions, runs a request, a…

Sagas are a great power tool, but I personally wouldn't use them for most simple API requests, largely because of the need for "signal actions" to trigger the logic.

You might want to check out our new `redux-starter-kit` package [0], which can simplify some common use cases for things like action creators and reducers. There's also many other existing libraries to handle repetitive code like API requests as well [1].

[0] https://github.com/reduxjs/redux-starter-kit

[1] https://github.com/markerikson/redux-ecosystem-links/blob/ma... , https://github.com/markerikson/redux-ecosystem-links/blob/ma...

Re: Introducing Hooks

#290
post #250

Earlier quoted context omitted.

I can’t say I’ve had that much trouble bringing in third party libraries, nor have I had a need to change how the framework works internally. I think this is the same as with most frameworks, you tend to just use them rather than doing stuff under the hood. Can you give an example?

At this point not really... it's been over a year since I've had to really worry about it. It was better using angular-redux or ngrx, but still was a weird experience. When you have eventing issues with RXJS, or handling integration with other libraries, it's definitely not as broad or mature as the React space is. Anything from chartjs to color pickers, I'm trying to recall the last big issue I had in an angular app…

Funny you should mention drag drop, it’s now built in as of version 7, just released a few days ago. Look up the CDK for more details.

Whenever I’ve needed drag and drop functionality in the past I’ve found it in existing UI components. A fairly comprehensive one is primeng. I’ve also added an angular colour picker and highcharts without very much trouble.

Often when I hear people complain about angular, I wonder if they just don’t understand it very well and are trying to do things the wrong way. Angular is opinionated, but I don’t find it terribly difficult or painful, though at this point I do have rather a lot of experience with it and find it’s difficult to put myself back in the shoes of someone with less.

I really do enjoy the framework and how comprehensive it is. I like having a framework that gives me so much out of the box without having to go to a somewhat unstable ecosystem of related projects. Frankly I think Angular’s bad name is due in part to it simply being fashionable to put Angular down, and partially because it’s critics never really learned how to use it.

Also, something about jsx just rubs me up the wrong way.

Post reply on HN