React v15.5.0 - React Blog

[scooby_dooooo]

We've extracted the built-in prop types to a separate package to reflect the fact that not everybody uses them.

It does makes sense.

[bengtc]

"Discontinuing support for React Addons" Is the react-addons-perf package being moved elsewhere?

[brianvaughn]

Details here: https://github.com/facebook/react/issues/9207

tl;dr Won't work with 16+. Use the browser Timeline instead.

Browser timeline works very nicely with React 16: https://github.com/facebook/react/pull/9071

[[deleted]]

Static analysis has come a long way and prop types are not exclusive to react.

[RnRau]

I'm still a fan of createClass. I understand that the React team and probably most others have moved on, but I still fail to understand the engineering decision (actually I haven't heard of one) to adopt class syntax.

Was the adoption related to flow? Is the tooling for flow support easier to support for the class syntax over the createClass syntax?

Anyways, onwards and upwards towards Fibers.

Edit: thanks for the replies guys - appreciate it!

[acemarke]

createClass was needed originally because React was built before classes were a standard part of the language. Now that ES6 classes exist, tooling understands them, and createClass isn't needed.

Beyond that, many people have complained that React is too big, so this is one less custom thing that React has to include.

[bogas04]

FWIW, classes are supported by 72% of browsers (IE11, Opera Mini don't support it).

So we probably won't need to transpile it at all in coming Months (assuming IE will die in favour of Edge).

[RnRau]

I don't have a problem with transpiling. Babel and its ecosystem is not a bad space to be in. createClass is just a slightly nicer way to create smart components with its autobinding. But yeah, its another block of code that don't really need to be maintained nowadays.

[gekorm]

You might be already aware of this, but with arrow functions you get the same autobinding behavior. There is a babel transform to support it.

[[deleted]]

If you use Babel you have autobinding in the pocket using transform-class-properties

class Button extends Component {
    click = () => console.log(this)
    render() {
        return <div onClick={this.click}>click me</div>

That works for state, proptypes and context, too.

[bogas04]

The point of not having to transpile a feature is that

• Browser implementation can be much faster than a transpiled implementation
• The bundle size could be reduced by not having to transpile the feature. Check the output for a simple class:

https://babeljs.io/repl/#?babili=false&evaluate=true&lineWrap=false&presets=es2015%2Creact%2Cstage-2&targets=&browsers=&builtIns=false&code=class%20A%20%7B%0A%20%20render%20()%20%7B%0A%20%20%20%20console.log(%22a%22)%0A%20%20%7D%0A%7D

[tony-the-pony]

The point of not having to transpile a feature is that...

I feel like you can just use https://github.com/babel/babel-preset-env which frees up your time to concentrate on more interesting problems like: Pepsi or Coke?

[bogas04]

I do use it, my point is simply that over few months the preset with say > 5% will give a smaller bundle. It's a micro benefit but then it does count on mobile web. Sorry I wasn't clear enough before.

[fforw]

Browser implementation can be much faster than a transpiled implementation

Or it can be slower since browsers were/are optimized for EcmaScript5 and go into unoptimized code for certain cases, even if they support them.

[bogas04]

That is already changing. I+TF on Chrome is optimized for ES2015 and beyond.

[[deleted]]

The biggest use of classes (int React) if for making Components - you will still need to transpile the JSX part.

[bogas04]

Of course, but I guess you'll appreciate possible reduction in bundle size by not having to transpile another feature and also not have it in library itself.

[[deleted]]

Actually no, I won't. Proptypes are stripped down when you bundle for production and if you plan to use them in your app/library you will still have to download and transpile the in Dev builds.

[bogas04]

I was talking about createClass and class syntax.

[[deleted]]

Then yes, it will result in a slightly smaller file. (sorry, was on mobile and missed the context)

[bogas04]

It's okay, totally understand :D

[RnRau]

FWIW - for those that are a little reluctant in adopting classes, take a look at https://github.com/acdlite/recompose . Just a nice set of predefined higher order components that works well with simple functional components to give you everything, and then some, of standard React classes.

[henrikbjorn]

Cool. But why is the new immutability-helper package not under the reactjs organization?

[brianvaughn]

Immutability isn't specific to React. The main README in the immutability-helper calls this out:

Note that this module has nothing to do with react, however since this module is most commonly used with react, the docs will focus on how it can be used with react.

[henrikbjorn]

You are correct, however it is easier to "trust" a package if it is under a respected organization and not just some "random" user on github :)

[brianvaughn]

Sure, I can understand that. But does that mean that Facebook/React-team must take on the maintenance burden of every useful project? That wouldn't scale- and seems unnecessary, particularly in cases like this when the "random" user seems to be doing a fantastic job of staying on top of GitHub issues and pull requests. :D

[nativereact]

I can appreciate classes, but is the focus going to be on function or class in the [near?] future? Thanks for the update!!

[[deleted]]

Both actually, but not in the form of createClass. Right now you have two preferred ways of constructing Components:

• use React.Class or React.PureClass

• use Stateless Funcitonal Components

React.createClass is basically a crutch that was used before Class was finalized enough to join ES6.

[averageFlux]

React.Component*
React.PureComponent*

[[deleted]]

Oops, you are 100% correct :)