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

251–260 of 310 posts

Re: Introducing Hooks

#251

Post by renke1 »

baddox wrote: post #190
renke1 wrote: post #98

Earlier quoted context omitted.

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.

I don't know much about TypeScript, but is any React HOC function composition compatible with it? It seems like it would be difficult for TypeScript to typecheck a compose function where you can do compose(hoc1, hoc2, hoc3), where each HOC renders a child component with some props added.

You can write HoC with working typings [1]. As far as I know the compose function is harder to type because of the varargs it uses (although I heard recent TS versions can actually handle that).

[1]: https://medium.com/@jrwebdev/react-higher-order-component-pa...

Re: Introducing Hooks

#252

Post by devit »

dceddia wrote: post #189
devit wrote: post #178

Why aren't these functions methods on "this" instead of magic freestanding functions?

Hooks only work in function components, so there's no "this" (at least, not one that React owns...).

Couldn't it just bind "this" to whatever object it uses to store component data?

Re: Introducing Hooks

#253

Post by cormacrelf »

k__ wrote: post #2

Cool idea, feels a bit like observables, especially the unsunscription via returned callback. The call order thing seems odd. Don't know how to sell this to people.

Angular's problem with observables is being completely mismatched with component state. You have to unsubscribe stuff manually all the time with any complex app, and it's a nightmare to debug when you've forgotten. You can use `@ngrx/utils` with class-property attributes now, but it's still weird and not always applicable and like most angular things, couldn't be coded by a newbie as it relies on the vomit-worthy-but-kinda-works metadata system.

AFAICT, with state+event hooks you could just write a function in a few lines to subscribe to an observable you pass to it, setState on each new value, and unsubscribe, and then use it everywhere.

(Edit: yes, of course there is the | async pipe. Not everything is in the template though.)

Re: Introducing Hooks

#254

Post by [deleted] »

baddox wrote: post #219
codefined wrote: post #157

Earlier quoted context omitted.

> because it's apparently hard to work out all the ways that the method could be invoked Simple example case of a statement that makes it impossible to minify function names: class Test { static func() { /* function code */ } } test[prompt('function to call')]()

Doesn’t that example also make it impossible to minify the names of anything? Perhaps other than JavaScript modules, since AFAIK the popular module builders like Webpack do compile-time module importing (I believe that even the dynamic import function is recognized at compile time and doesn’t support throwing in a prompt).

[deleted]

Re: Introducing Hooks

#255

Post by engineeringwoke »

Vinnl wrote: post #247
acemarke wrote: post #168

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.

> I'd agree it's "magic" in the sense that it's not entirely visible to the end user. I didn't dive into hooks to completely yet to have a proper opinion on it, but the primary disadvantage of "magic" is that the end user can not deduce what's going on just by looking at the code. If magic is therefore "only" restricted to the end user, that's not much of a restriction...

There's already so much magic going on in React's code base. For Fiber, they put the stack in the heap so they could go around the JavaScript call stack and schedule work as they see fit

The real magic is in traversal APIs, like Context

Re: Introducing Hooks

#256

Post by Vinnl »

engineeringwoke wrote: post #255
Vinnl wrote: post #247

Earlier quoted context omitted.

> I'd agree it's "magic" in the sense that it's not entirely visible to the end user. I didn't dive into hooks to completely yet to have a proper opinion on it, but the primary disadvantage of "magic" is that the end user can not deduce what's going on just by looking at the code. If magic is therefore "only" restricted to the end user, that's not much of a restriction...

There's already so much magic going on in React's code base. For Fiber, they put the stack in the heap so they could go around the JavaScript call stack and schedule work as they see fit The real magic is in traversal APIs, like Context

Oh absolutely - by now I have read through the docs, and as I mentioned at [1] as well, I'm even expecting hooks to do away with more magic than it introduces.

That said, my main point was that "it's only magic for end users" is not really a valid excuse :)

[1] https://twitter.com/VincentTunru/status/1055747566393085952

Re: Introducing Hooks

#257

Post by Sacho »

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.

what are we supposed to see here?

Re: Introducing Hooks

#258

Post by engineeringwoke »

btown wrote: post #55
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. T…

But they needed Fiber to make AsyncMode possible

And once it's well baked enough, it works very cleanly with universal rendering strategies. It means you don't have to separate logic into components where it doesn't belong because the server render ignores loading logic in componentDidMount. It's suddenly all first class

And, then, theoretically you can remove Redux and just use Context

It has gotten really wacky along the way. I hope they don't lose sight

Re: Introducing Hooks

#259

Post by k__ »

cormacrelf wrote: post #253
k__ wrote: post #2

Cool idea, feels a bit like observables, especially the unsunscription via returned callback. The call order thing seems odd. Don't know how to sell this to people.

Angular's problem with observables is being completely mismatched with component state. You have to unsubscribe stuff manually all the time with any complex app, and it's a nightmare to debug when you've forgotten. You can use `@ngrx/utils` with class-property attributes now, but it's still weird and not always applicable and like most angular things, couldn't be coded by a newbie as it relies on the vomit-worthy-but…

I always had the feeling Cycle.js is the better observable framework.

Re: Introducing Hooks

#260

Post by engineeringwoke »

xab9 wrote: post #242
munchbunny wrote: post #154

Earlier quoted context omitted.

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…

I "don't actually understand why people like Typescript", or lemonade, or skiing, or eating fish. I know why I like it, including static typing, and how I can find a balance with using its features (and not using some). On the other hand I'm not trying to hide that I'm bitter about the mental lazyness around typescript - I had some bad experience with interviewers who praised ts (without ever bothering to learn the c…

You wish we went back to bind and apply? And not being able to trace logic, state, and DOM through a labyrinth of Backbone views? We have come so far

How is static typing "mental laziness"?

Post reply on HN