Earlier quoted context omitted.
You can just do `onChange={() => this.handler()}`.
This would create a new inline function on every render though, which potentially might cause rendering performance issues.
Hardly ever.
Introducing Hooks
181–190 of 310 posts
Re: Introducing Hooks
#182> 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.
I think the Angular resentment is a little behind the times, the days of Angularjs 1 and the beta versions of Angular 2 are behind us. The new Angular is worth a look, especially if react is now having various extras bolted on ad hoc.
> the days of Angularjs 1 and the beta versions of Angular 2 are behind us
There is still a _heap_ of Angular 1 code out there since the 1 -> 2 move basically meant you couldn't upgrade without a full rewrite. Both my last two jobs have involved re-writing Angular 1 apps.
Re: Introducing Hooks
#183> 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 feel the same way! Maybe I'm just getting older, but I like code to be boring. A class is something everyone can read and understand. If you have to navigate a maze of HOCs withStateHandlers, enchancers, redux actions, reducers and connectors you end up needing to open 10-20 files and jump around between as many functions to build a picture of how a component works. Considering code is read more often than written…
Amen!
Re: Introducing Hooks
#184So 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.
This is an excellent point, not sure why you've been voted down. So now functional components can't be guaranteed to maintain their best property? Weird.
Re: Introducing Hooks
#185I absolutely fell in love with React when I switched over from Angular many years ago. Loved the simplicity of the API and how you had to be explicit about everything. Over the years, I've seen React start adding a lot of "optional" APIs which increase the surface area anyway. This made me explore other options and now that I've started doing some Elm, I feel it's so much easier to reason with.
I guess this is the natural progression of frameworks. What was once simple will get complex until the next thing comes around.
Re: Introducing Hooks
#186Why not support Hooks in classes as well? The motivation is correct in that Hooks can help separate intertwined concerns that are currently mingled in the lifecycle calls. There seems a good usefulness in allowing the same cross-cutting inside classes as well as functions. It would also presumably help avoid a "fork-the-world" situation where projects eventually find themselves having to maintain both HOCs and Custom…
[deleted]
Re: Introducing Hooks
#187Oh great. Another React feature that relies on creating anonymous functions every time your component renders. I presume this is now adequately fast in the various JITs in use, because I seem to remember this being one of the major bottlenecks React developers were instructed to avoid doing at all costs.
Yeah, they answer this in the FAQ too.
> In modern browsers, the raw performance of closures compared to classes doesn’t differ significantly except in extreme scenarios.
https://reactjs.org/docs/hooks-faq.html#are-hooks-slow-becau...
Re: Introducing Hooks
#188This is interesting. I'll have to spend some time mulling over this before the benefits sink in. It seems like a much more confusing and less composable API than recompose, which is how I add state, lifecycle, and other React class features to functional components. I've been completely avoiding React classes for a while now and using stateless components with recompose for over a year now, and I find it to be a wond…
The author of recompose just end of life'd it today in favor of Hooks. Read his comment on the top of the recompose readme.
Still, I'll be looking into the hooks pattern and determining how it will work for my projects and especially how easy it will be to port my large number of reusable HOCs from recompose to React hooks.
Re: Introducing Hooks
#189Why 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...).
Re: Introducing Hooks
#190This is interesting. I'll have to spend some time mulling over this before the benefits sink in. It seems like a much more confusing and less composable API than recompose, which is how I add state, lifecycle, and other React class features to functional components. I've been completely avoiding React classes for a while now and using stateless components with recompose for over a year now, and I find it to be a wond…
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.