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

201–210 of 310 posts

Re: Introducing Hooks

#201

Post by jnbiche »

munchbunny wrote: post #154
xab9 wrote: post #127

Earlier quoted context omitted.

Maybe newish coders should learn the language they are using. And of course there is typescript (and a gazillion of languages that can be transpiled to js these days), which synergizes very well with enterprise people and java/dotnet devs who never did a line of frontend before.

Maybe newish coders should learn the language they are using. It's not a language thing. OOP discipline is a coding thing in general. And of course there is typescript (and a gazillion of languages that can be transpiled to js these days), which synergizes very well with enterprise people and java/dotnet devs who never did a line of frontend before. You sound like you don't actually understand why people like Typescr…

> You sound like you don't actually understand why people like Typescript, or, more specifically, static typing.

Eh, in my experience, there are two types of Typescript users: 1) those users who appreciate the safety that type systems provide when used properly, and 2) those enterprise users of the language who have mostly only coded Java and C# and who like Typescript because it lets them write Java-style code for the browser.

Re: Introducing Hooks

#202

Post by mygo »

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’ve seen this discussion pop up before in other frameworks I have used as they evolved over time. Interestingly enough my favorite framework went from being very magic to being less magic and more explicit and verbose. I liked it better when it was more magic.

Guess I’m in the silent group who isn’t bothered by a bit of magic, and actually likes it. Sometimes I don’t care too much what’s going on under the hood so long as I understand what to expect to happen. If it’s a good framework, magic or not, the documentation will do a good job of detailing how to use such magical features.

Re: Introducing Hooks

#203

Post by iEchoic »

> Hooks allow you to reuse stateful logic without changing your component hierarchy.

Why haven't ES7 decorators been more widely adopted for this? We've been using them for over a year for this purpose now and they've ended up being far cleaner, more powerful, and more composable than the proposed interface.

Re: Introducing Hooks

#204

Post by emmanueloga_ »

wildermuthn wrote: post #177
emmanueloga_ wrote: post #120

Earlier quoted context omitted.

hmmm yeah here's a better example: (defn timer-component [] (let [seconds-elapsed (r/atom 0)] (fn [] (js/setTimeout #(swap! seconds-elapsed inc) 1000) [:div "Seconds Elapsed: " @seconds-elapsed]))) Now the atom is defined inside the component function, and is captured by lexical scope in the returned function. Any timer-components on page will have their own `seconds-elapsed` state.

This was such a common pattern that reagent created a macro for it. But I like the macro-less code, in that it becomes very clear what is happening. A good macro reduces complexity by making code concisely simple. A bad macro hides complexity by making code easy to write. Frameworks like React succeed when they are built like a good macro. In this case, React is both hiding complexity (component lifecycles) while add…

Are you maybe talking about with-let? I'm fairly new to reagent and not really familiar with any of its macros

As it turns, there are only 5 macros, and only a some of those seem to be part of the public API, which is how I found about `with-let` :-)

https://github.com/reagent-project/reagent/search?q=defmacro...

Re: Introducing Hooks

#205

Post by tln »

mhink wrote: post #126
Fellshard wrote: post #94

Earlier quoted context omitted.

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 convolut…

I think people are getting too hung up on the "implicit ordering" thing. The only thing that really matters about the ordering of hooks is that the call pattern remains stable between render passes. This code: const [foo, setFoo] = useState("abc"); const [bar, setBar] = useState("123"); ...is functionally the same thing as const [bar, setBar] = useState("123"); const [foo, setFoo] = useState("abc"); The feature is _d…

Couldn't useState accept a name? How would React DevTools or another debugging tool know the name of a piece of state?

Re: Introducing Hooks

#206

Post by tln »

spankalee wrote: post #133
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)?

It'd be really great for VDOM, builder APIs, and any immediate mode -> retained mode mapping, to be able to get the _callsite_ of a function invocation. Then they could associate state with the callsite unambiguously without resorting to tracking invocations on a stack and disallowing control flow. Tagged template literals already give us something of a callsite, since the template strings object is cached per callsi…

I don't think this will work, when I just tried to add a property in a template function I get:

    TypeError: Cannot define property foo, object is not extensible
Cool idea though

Re: Introducing Hooks

#208

Post by baddox »

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’m guessing that React is keeping track of the current component instance that is executing when the hook is called, instead of JavaScript keeping track of what ‘this’ is bound to when ‘this.setState’ is called. One could say that both systems are “magic,” but it looks like the React team considers the behavior of ‘this’ in JavaScript to be a source of confusion for React developers.

Re: Introducing Hooks

#209

Post by skissane »

mygo wrote: post #202
wereHamster wrote: post #167

Earlier quoted context omitted.

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’ve seen this discussion pop up before in other frameworks I have used as they evolved over time. Interestingly enough my favorite framework went from being very magic to being less magic and more explicit and verbose. I liked it better when it was more magic. Guess I’m in the silent group who isn’t bothered by a bit of magic, and actually likes it. Sometimes I don’t care too much what’s going on under the hood so l…

Magic is great when it works. The problem is when it doesn't do what you are expecting, it can be much harder to troubleshoot. (Did I do something wrong? Am I hitting a bug?)

Magic hides internal details, hence users are less familiar with them, hence they struggle more to diagnose when the magic fails to happen.

Re: Introducing Hooks

#210

Post by sophiebits »

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…

(I work on React.) I think we’re on the same page here. Having a pile of recompose helpers and HOCs is exactly what we think/hope Hooks will help avoid.
Post reply on HN