[eric_b]

I like that they are taking the deprecation of the lifecycle methods slowly. And the automated script to migrate to the 'UNSAFE' version of those methods in 17 is a nice touch. I don't know if I love the new context API, but it's great they're giving an official option.

Of the big JS frameworks that are popular at the moment, I think the React team is doing the best job of balancing new features with minimizing developer pain and breaking changes.

If I had one thing negative to say about this release, it's that I think the forwardRef is maybe moving in the wrong direction a bit. In my experience, higher order components should be the exception, not the rule. They are a neat way to provide some functionality that is otherwise difficult, but their cognitive and maintenance overhead are high. If it stops at forwardRef, no big deal, but I am not sure HOCs are something that deserve explicit API support (and the additional surface area that entails)

[jakelazaroff]

> I like that they are taking the deprecation of the lifecycle methods slowly.

React has a great deprecation strategy. Their general philosophy is "if you can use version X with no warnings, you should be able to use version X+1 with no changes to your app."

[bsimpson]

Using refs to talk to the DOM is a leaky abstraction, but talking the the DOM is a necessity in a framework that renders to the DOM. Before forwardRef, you'd end up with ad-hoc prop names like `domRef` to try to wallpaper around the leak.

I'm happy to see a thoughtful solution. There are some things you just can't do with React alone (like listen for PointerEvents).

[joshribakoff]

You can handle pointer events with synthetic events (onMouseMove and such) unless I am misunderstanding

[bsimpson]

I mean PointerEvent, not MouseEvent:

https://developer.mozilla.org/en-US/docs/Web/API/PointerEven...

[brianvaughn]

HOCs are widely used (and for good reason– they can be very useful). Hopefully forwardRef will make their usage more consistent and predictable.

If anything, I think the new context API (and even forwardRef itself) are endorsements of the render prop pattern more than of HOCs. :)

[zackify]

“higher order components should be the exception, not the rule.”

This just isn’t true. Abstracting form logic. Request logic. Anything else you use across your app. Connect in redux. There are hundreds of good reasons to have a higher order component.

It makes testing easy. Test your request logic in one place, anything that uses it is now a stateless component, and testing it is trivial.

[underwater]

Render props can solve many of those problems without Higher order components.

[hungerstrike]

No, they should still be the exception for the reasons already stated but also because defining all logic in a “render” function means it’s tightly coupled to your view logic, which you do not want.

Request logic doesn’t belong in a render function. Routing definitions don’t belong in a render function and neither does abstract form logic.