For those who are interested in some of the details of the work that's going on, Lin Clark's recent talk on "A Cartoon Intro to Fiber" at ReactConf 2017 is excellent [0]. There's a number of other existing writeups and resources on how Fiber works [1] as well. The roadmap for 15.5 and 16.0 migration is at [2], and the follow-up issue discussing the plan for the "addons" packages is at [3].<p>I'll also toss out my usual reminder that I keep a big list of links to high-quality tutorials and articles on React, Redux, and related topics, at <a href="https://github.com/markerikson/react-redux-links" rel="nofollow">https://github.com/markerikson/react-redux-links</a> . Specifically intended to be a great starting point for anyone trying to learn the ecosystem, as well as a solid source of good info on more advanced topics. Finally, the Reactiflux chat channels on Discord are a great place to hang out, ask questions, and learn. The invite link is at <a href="https://www.reactiflux.com" rel="nofollow">https://www.reactiflux.com</a> .<p>[0] <a href="https://www.youtube.com/watch?v=ZCuYPiUIONs" rel="nofollow">https://www.youtube.com/watch?v=ZCuYPiUIONs</a><p>[1] <a href="https://github.com/markerikson/react-redux-links/blob/master/react-implementation.md#react-fiber" rel="nofollow">https://github.com/markerikson/react-redux-links/blob/master...</a><p>[2] <a href="https://github.com/facebook/react/issues/8854" rel="nofollow">https://github.com/facebook/react/issues/8854</a><p>[3] <a href="https://github.com/facebook/react/issues/9207" rel="nofollow">https://github.com/facebook/react/issues/9207</a>
React team is doing an amazing job. I remember when it was first announced, I thought Facebook was crazy. "JSX? That sounds like a bad joke!" I don't think I've ever been so wrong. After hearing so much about React, I eventually tried it out and I realized that JSX wasn't a big deal at all, and in fact it was actually pretty awesome.<p>Their migration strategy is great for larger actively developed applications. Since Facebook is actually using React, they must have a migration strategy in place for breaking changes. Since breaking anything has such a big impact on the parent company, it makes me feel like I can trust em.<p>Heck, most of the items in this list of changes won't surprise anyone that's been following the project. Now there's less magic (e.g. React.createClass with its autobinding and mixins), and less React-specific code in your app (e.g. react-addons-update has no reason to live as a React addon when it can clearly live as a small standalone lib).
This is a big deal to deprecate `createClass` and `propTypes`.<p>PropTypes' deprecation is not difficult to handle, but the removal of createClass means one of two things for library maintainers:<p>(1). They'll depend on the `create-class` shim package, or,<p>(2). They must now depend on an entire babel toolchain to ensure that their classes can run in ES5 environments, which is the de-facto environment that npm modules export for.<p>I'm concerned about (2). While we are probably due for another major shift in what npm modules export and what our new minimum browser compatibility is, the simple truth is that most authors expect to be able to skip babel transcompilation on their node_modules. So either all React component authors get on the Babel train, or they start shipping ES6 `main` entries. Either way is a little bit painful.<p>It's progress, no doubt, but there will be some stumbles along the way.
For those still using propTypes, I'd recommend to take a look at Flow as replacement.<p><a href="https://flow.org/en/docs/frameworks/react" rel="nofollow">https://flow.org/en/docs/frameworks/react</a>
The breakup of the React package into a bunch of smaller modules really puts packages that treat React as a peer dependency in a pickle. I have a component module using createClass that works fine and exports a transpiled bundle in package.json. I guess now we'll have to switch to create-react-class, or maintain some kind of "backports" release series for people that are still using older React versions but want bugfixes.<p>Anyone have experience with this sort of thing?
This is a good move. Modernization with sensible deprecation and scope re-evaluation with downsizing when more powerful alternatives exist. Too often codebases get bigger when they should really get smaller.
I absolutely love how React+TypeScript setup handles PropTypes elegantly. And then you get the amazing intellisense automatically.<p>```<p>interface State {}<p>interface ISomeComponentProps {<p><pre><code> title: string;
tooltip?: string
....
</code></pre>
}<p>@ReduxConnected<p>export class SomeComponent extends React.Component<ISomeComponentProps, State> {<p>....<p>```
What is this problem in the Javascript landscape to keep forcing developers to do things differently, with the penalty of your app not working anymore if you don't comply?<p>I mean, creating a new type of brush for painters is ok, but I don't see the need for forcing them to redo their old paintings with the new type of brush in order to keep them visible..<p>IMHO Coffeescript and some other to Javascript transpilers are still a much better language than the entire Babel ES5/ES6/ES7 thing. But for some reason my free choice here is in jeopardy. The community apparently has chosen for Babel and are now happily nihilating things that are not compatible with that.<p>In my opinion this is not only irresponsible, but very arrogant as well.<p>Although I do understand and can write higher order components, I still write and use small mixins in projects because it works for me. I also use createClass because I enjoy the autobinding and don't like the possibility to forget calling super.<p>Now I need to explain my superiors why this warning is shown in the console, making me look stupid using deprecated stuff. And I need to convince them why I need to spend weeks rewriting large parts of the codebase because the community thinks the way I write is stupid. Or I can of course stick to the current React version and wait until one of the dependencies breaks.<p>It would be really great if library upgrades very, very rarely break things. Imagine if all the authors of the 60+ npm libs I use in my apps are starting to break things this way, for me there is no intellectual excuse to justify that.
Awesome changelog with great migration instructions. Bravo to the React team!<p>Going to set aside some hours on Saturday to upgrade our React version.<p>I recently started to go in with functional components where I don't need life-cycle events such as componentDidMount. Does anyone know if React is planning to make optimizations for code structured in this way?
Fiber is what I'm really waiting for. Not much official chatter about it, but looks like a 16 release?<p>They just removed some addons in master that many third party packages rely on, including material-ui. Hopefully these other popular packages can be ready to go with the changes when the fiber release hits.
I'd like to see React support shadow-dom and web components. Not holding my breath however, since Facebook considers web components to be a "competing technology".<p>Unlike real web components, React components are brittle since React does not have the equivalent of Shadow DOM.
I hate that the React team prefers ES6 classes. This is what I do:<p>function App(params) {
const component = new React.Component(params);<p><pre><code> component.lifeCycleMethod = function() {...};
component.render = function() {...};
function privateMethod() {...}
return component;
}</code></pre>
Happy to see propTypes getting shelved. Too many people stubbornly use propTypes even in Typescript projects. Hopefully this change will usher in the final stamping out of that.
Of course, you'd need to use super appropriately, but I wonder if anyone's taken a stab at porting React mixins to ES2105 mixins:<p><a href="http://justinfagnani.com/2015/12/21/real-mixins-with-javascript-classes/" rel="nofollow">http://justinfagnani.com/2015/12/21/real-mixins-with-javascr...</a>
Just curious: did Facebook change the license? AFAIK they can revoke permission to use from 3rd parties. Am I mistaken? If not, isn't this a huge risk for startups?
I still remember the times when warning were actual likely mistakes in your code, not "we're adding some more churn, update your stuff until we churn more".<p>If you want people to always ignore warnings, this is how you go about it.
Why people are always end up with J2EE-like bloatware? There must be some pattern, something social. It, perhaps, has something to do with the elitism of a being a framework ninja, a local guru who have memorized all the meaningless nuances and could recite the mantras, so one could call oneself an expert.<p>The next step would be certification, of course. Certified expert in this particular mess of hundred of dependencies and half-a-dozen tools like Babel.<p>Let's say that there is a law that any over-hyped project eventually would end up somewhere in the middle between OO-PHP and J2EE. Otherwise how to be an expert front-end developer?<p>Google's responsive design looks like the last tiny island of sanity.