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

161–170 of 310 posts

Re: Introducing Hooks

#161

Post by WorldMaker »

krapp wrote: post #91
beatgammit wrote: post #9

Earlier quoted context omitted.

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?

Prototypal inheritance, and scope controls more refined/easier to work with than IIFEs. In the end the class notation is "simply" syntax sugar giving the object syntax the benefit of Function.prototype and IIFE closures, without having to resort to layers of either/both.

Re: Introducing Hooks

#162

Post by kaoD »

maaaats wrote: post #109
needz wrote: post #71

Earlier quoted context omitted.

It's meant for functional components, not classes.

"This" existed in javascript long before classes. No idea why my relevant question is down voted.

"this" isn't bound in functional components because there's nothing to bind it to.

Re: Introducing Hooks

#163

Post by nathan_f77 »

acemarke wrote: post #148
nathan_f77 wrote: post #129

This is really interesting. I'm a big fan of any abstractions that reduce the amount of code I have to write. Just a personal preference. Other programmers like to avoid "magic", but I love it. `useEffect` feels much cleaner than the component lifecycle methods, and I could add some abstractions on top of those. e.g. a higher-order function that adds/removes a window event listener, and you can just pass the event an…

Hi, I'm a Redux maintainer. If you've got some suggestions on how we can improve the API and usage, please file an issue! I'm currently looking at revamping our WIP React-Redux v6 branches to use hooks internally. Looks really promising so far, but I'll have to keep playing with it and see how it turns out. Our goal at the moment is to publish React-Redux v6 that is basically API-compatible with v5, and then open thi…

Hi, thanks for your reply! I've had a look at some of the higher-level abstractions for Redux [1], but none of them really appealed to me. I'm just looking for something magical and opinionated so that I can write less code, so I might even try to write my own abstraction. I want to see if it's possible to automatically generate actions and action creators just based on the reducer. Maybe a special way of writing reducers, or maybe leverage the type system and write a babel plugin.

[1] https://redux.js.org/introduction/ecosystem#higher-level-abs...

Re: Introducing Hooks

#164

Post by Guillaume86 »

joelg236 wrote: post #22
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)?

In the keynote, Dan talked about how this works. It depends on the order that useState is called, which makes conditional branches a no-no (there's a linter for it).

Just looking at the code I came to the conclusion it had to work that way, I don't like it, way too easy to break and some people are going to be very confused when things goes wrong. It's a uncommon/unfamiliar coding constraint. If you have to declare them all in the same order every time, you might as well force a single state (like the setState API) and/or keyed state values and have a safe API.

Re: Introducing Hooks

#165

Post by rhacker »

acemarke wrote: post #153
rhacker wrote: post #37

Earlier quoted context omitted.

What is the downside to changing the example here: https://reactjs.org/docs/hooks-reference.html#usereducer To something without strings and hard-coding the actual "reduction code" to something like export const increment = (state) => ({count: state.count + 1}); And give modern JS languages like typescript import the increment function and use it directly? Why are we so attached to these action type strings?

Redux is based on the Flux Architecture. In particular, it carries on the idea of describing events or state update requests as plain objects. One of the key insights of Redux is that you can then write additional logic to act on those actions as they progress through a centralized pipeline (ie, middleware). I've seen lots of Redux-alikes that are "Redux, but without reducers/actions/etc". They mostly claim that they…

I think then perhaps redux may simply not be for me. I do feel like unfortunately a lot of teams use it anyway, giving React and a few other things a complex feel. When you suddenly take it out of React, at least for simple use-cases, you suddenly feel like React is incredibly simple.

If more teams had been more selective about Redux or to simply use it JUST for global state things like color themes, logged in user, and probably a half dozen other things it might have fewer people burned on it.

I'm definitely not in your shoes - you're a redux maintainer and I do apologize for my "clusterfuck" comment. But I think fewer people would be burned if architects at the top didn't mis-use and abuse. I've been in projects where just about every tiny little input, checkbox, on 30 or so forms had to go through a convoluted redux action. Then when I finally got into my own React usage, without redux, it was like a super-genius baby landed in my lap dancing like it was 1999.

Re: Introducing Hooks

#166

Post by nathan_f77 »

acemarke wrote: post #148
nathan_f77 wrote: post #129

This is really interesting. I'm a big fan of any abstractions that reduce the amount of code I have to write. Just a personal preference. Other programmers like to avoid "magic", but I love it. `useEffect` feels much cleaner than the component lifecycle methods, and I could add some abstractions on top of those. e.g. a higher-order function that adds/removes a window event listener, and you can just pass the event an…

Hi, I'm a Redux maintainer. If you've got some suggestions on how we can improve the API and usage, please file an issue! I'm currently looking at revamping our WIP React-Redux v6 branches to use hooks internally. Looks really promising so far, but I'll have to keep playing with it and see how it turns out. Our goal at the moment is to publish React-Redux v6 that is basically API-compatible with v5, and then open thi…

Whoa, I just found this redux-auto [1] project, which is a really interesting approach. You just apply it as a middleware and then you can import and call actions from anywhere. The API is a bit ugly but I like the general idea.

[1] https://github.com/codemeasandwich/redux-auto

Re: Introducing Hooks

#167

Post by wereHamster »

acemarke wrote: post #146
adriancooney wrote: post #123

My gut reaction is that Hooks isn't the greatest addition to React. One thing I've always pitched about React is the clean and extremely explicit API (with `dangerouslySetInnerHTML` being my favourite example). The hooks API is taking the dangerous road down to implicitness and magic which can only ever mean bad things in my book. It's really not clear to me how calling the setter for these individual pieces of state…

Have you looked at what `React.Component.setState()` actually does under the hood? The logic isn't implemented in `React.Component` itself - instead, it tells the core React rendering logic to queue up a re-render. The real work is all inside React's internals. I agree that the `useState()` aspect _looks_ a bit magical, but it's ultimately doing the same thing that `setState()` does in the end. React already knows wh…

The 'this' in 'this.setState()' tells react which component queued the setState. With the new API that information is collected by react through.. ehm.. some kind of magic.

I understand why the react developers chose not to make the component an explicit argument in the new API, as it would open doors to misuse. But magic never seems to work out in the long run, IME.

Re: Introducing Hooks

#168

Post by acemarke »

wereHamster wrote: post #167
acemarke wrote: post #146

Earlier quoted context omitted.

Have you looked at what `React.Component.setState()` actually does under the hood? The logic isn't implemented in `React.Component` itself - instead, it tells the core React rendering logic to queue up a re-render. The real work is all inside React's internals. I agree that the `useState()` aspect _looks_ a bit magical, but it's ultimately doing the same thing that `setState()` does in the end. React already knows wh…

The 'this' in 'this.setState()' tells react which component queued the setState. With the new API that information is collected by react through.. ehm.. some kind of magic. I understand why the react developers chose not to make the component an explicit argument in the new API, as it would open doors to misuse. But magic never seems to work out in the long run, IME.

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.

Re: Introducing Hooks

#169

Post by acemarke »

nathan_f77 wrote: post #163
acemarke wrote: post #148

Earlier quoted context omitted.

Hi, I'm a Redux maintainer. If you've got some suggestions on how we can improve the API and usage, please file an issue! I'm currently looking at revamping our WIP React-Redux v6 branches to use hooks internally. Looks really promising so far, but I'll have to keep playing with it and see how it turns out. Our goal at the moment is to publish React-Redux v6 that is basically API-compatible with v5, and then open thi…

Hi, thanks for your reply! I've had a look at some of the higher-level abstractions for Redux [1], but none of them really appealed to me. I'm just looking for something magical and opinionated so that I can write less code, so I might even try to write my own abstraction. I want to see if it's possible to automatically generate actions and action creators just based on the reducer. Maybe a special way of writing red…

Funny you should mention that :)

There's a lot of existing libraries out there that will indeed generate action creators, reducers, etc (see my Redux addons list [0] for examples).

One of the most interesting ones I've seen is Eric Elliott's `autodux` project [1], which does some clever bits of handling inside a `createSlice()` function.

Earlier this year, I put together a new project called `redux-starter-kit`] [2]. Its goal is to simplify several common use cases with Redux usage, including store setup, reducer definitions and immutable update logic, and default behavior out of the box. While we don't plan to add these things to the Redux core itself, `redux-starter-kit` is an official Redux-branded library, and we're going to start encouraging that people use it in most situations.

We just added a `createSlice` function to `redux-starter-kit`, based on the `autodux` approach. I'd encourage you to try it out, as it does _exactly_ what you're asking for. I'd also really appreciate some feedback on how well it works, and any additional ideas for things the starter kit should include!

[0] https://github.com/markerikson/redux-ecosystem-links

[1] https://github.com/ericelliott/autodux

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

Re: Introducing Hooks

#170

Post by [deleted] »

acemarke wrote: post #146
adriancooney wrote: post #123

My gut reaction is that Hooks isn't the greatest addition to React. One thing I've always pitched about React is the clean and extremely explicit API (with `dangerouslySetInnerHTML` being my favourite example). The hooks API is taking the dangerous road down to implicitness and magic which can only ever mean bad things in my book. It's really not clear to me how calling the setter for these individual pieces of state…

Have you looked at what `React.Component.setState()` actually does under the hood? The logic isn't implemented in `React.Component` itself - instead, it tells the core React rendering logic to queue up a re-render. The real work is all inside React's internals. I agree that the `useState()` aspect _looks_ a bit magical, but it's ultimately doing the same thing that `setState()` does in the end. React already knows wh…

[deleted]
Post reply on HN