16 ms·
React v15.5.0
- nodesocket 9y agoBig news seems to be removal of `React.createClass()` in favor of: class HelloWorld extends React.Component { }
- k__ 9y agoUh, so they take the step to 100% ES2015, yes?
- taylorlapeyre 9y agoYou can still use the createClass API via a separate package: https://www.npmjs.com/package/react-create-class https://www.npmjs.com/package/react-create-class
- thatswrong0 9y agoMild rant: I'm not convinced ES6 classes are better than components created the old way. First, the lack of autobinding callback functions for child props is not ideal. I don't even have to think about it with createClass, and it requires at least one extra step with ES6. It's less convenient. Second, I don't think HOCs are necessarily easier to reason about than mixins in many situations. React is already quite deficient in its own testing utilities (esp. when it comes to functional stateless components and HOCs such that I'd recommend everyone use enzyme), and testing a multi-wrapped HOC can be a PITA whereas whereas a component with multiple mixins is simpler to reason about in comparison. What I care about is testing the output of a component; I don't want to have to understand the internal structure of a component in order to test it in a shallow manner. Id love to see an argument as to why they are better, but I haven't seen anything convincing. Plus our app uses a ton of non-invasive mixins and the upgrade away from them would complicate the app and make testing way more complicated.
- tlrobinson 9y agoIf you don't want to think about binding, just use the arrow function syntax: class Foo extends Component { bar = () => { // ... } }
- acemarke 9y agoRequires the Stage 2 Class Properties syntax to be enabled (via Babel plugin), but yes, that's the "nicest" way to do it, and the current approach recommended by the React team. There's also various binding utilities, like https://github.com/cassiozen/React-autobind https://github.com/cassiozen/React-autobind . I've got discussion of the various binding approaches listed at https://github.com/markerikson/react-redux-links/blob/master/using-react-with-es6.md https://github.com/markerikson/react-redux-links/blob/master... .
- amk_ 9y agoI use and recommend this syntax, but you do have to have babel-preset-stage-2 to enable the class properties transform. https://babeljs.io/docs/plugins/transform-class-properties/ https://babeljs.io/docs/plugins/transform-class-properties/
- TheSisb2 9y agoThis compiles poorly and has a performance cost, it turns out. Doing: constructor(props) { super(props); this.func = this.func.bind(this); } Is better if you care about performance.
- ConAntonakos 9y agoJust curious: are there tests proving this?
- gavinpc 9y agoI felt the same way and avoided `class` for mostly the same reasons. For better or worse, there are many ways to make pseudo-classes using Javascript. Is prototype configurable? Writable? Enumerable? What about the properties of prototype? Are they configurable? Enumerable? Writable? And there are still people who clobber the default prototype, killing its `constructor` and changing the above. And that's just one level. When it comes to calling super constructors and super methods, things get much wilder. I've come to terms with the view that ES6 classes are just a way for us to move on with our lives. We do a common thing in a common way, and never think for a second about what subclassing approach to use, what method is compatible with what other method, and whether it's implemented correctly. Yes, you need a build step to target older browsers. But you needed a dependency anyway, to support whatever ad-hoc method you were using. I never used mixins, but I agree that HoC's present a special problem for testing.
- EugeneOZ 9y ago"extends" is often a bad idea. https://en.wikipedia.org/wiki/Composition_over_inheritance https://en.wikipedia.org/wiki/Composition_over_inheritance It's sad to see how new generation can't learn lessons of the past.
- danabramov 9y agoYes and in fact it is right in our docs. https://facebook.github.io/react/docs/composition-vs-inheritance.html https://facebook.github.io/react/docs/composition-vs-inherit... >So What About Inheritance? >At Facebook, we use React in thousands of components, and we haven't found any use cases where we would recommend creating component inheritance hierarchies. We dislike inheritance as much as you do, but we also dislike ad hoc class systems that have worse performance.
- EugeneOZ 9y agoExample with "extends" is also in your docs (exactly by link of this post), so I'm not sure what it proves.
- seattle_spring 9y agoThat's extending the base react component class, not an existing component class.
- Rapzid 9y agoFiber is what I'm really waiting for. Not much official chatter about it, but looks like a 16 release? 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.
- natmaster 9y agoThis is the prep for fiber. They're releasing something with deprecation warnings so when they have to completely remove those things in 16 (w/ fiber), everyone will be ready.
- YCode 9y agoWhen I saw this post I immediately hit http://isfiberreadyyet.com/ http://isfiberreadyyet.com/ and was sad it went back down to 92% :|
- mlsarecmg 9y agoI think Dan Abramov posted this recently: npm install react@next react-dom@next --save It's still in compat mode, but the new return types for instance are already live.
- ggregoire 9y agoFor those still using propTypes, I'd recommend to take a look at Flow as replacement. https://flow.org/en/docs/frameworks/react https://flow.org/en/docs/frameworks/react
- lfischer 9y agoFlow’s interesting, unfortunately it requires more invasive changes to your code than just prop types. For example, if I remember correctly, you need a declaration for a class component’s state.
- adrice727 9y agoWe decided to use Flow in a rewrite of an existing React project at work. I found all of the type boilerplate around React/Redux to be somewhat cumbersome at first, but after a few days I didn't even think about it anymore. It feels a little strange writing React code without it at this point.
- derekdahmer 9y agoSame, we're using Flow in for our React Native app but not yet in our older webapp. I've found more bugs that way that more than offset the extra time spent writing types and being a little bit more verbose to keep flow happy. The minor annoyances are around the edge cases. Like eslint/flow throws propType errors when using props that were dereferenced from `this.props.someObject`. But you can just write the longer version `this.props.someObject.whatever` and everything's fine.
- mambodog 9y agoI mean if you really want to be loose with the type of your component's state, you can just declare its type as Object, eg. class MyComponent extends React.Component { state: Object; constructor(props) { super(props); this.state = { foo: 1, // no type error }; }; } Providing a more explicit type for the component's state is a great way to catch bugs, however. It also forces you to more clearly think through which combinations of state properties are valid. Jared Forsyth gave a good talk about this at React Conf: https://www.youtube.com/watch?v=V1po0BT7kac https://www.youtube.com/watch?v=V1po0BT7kac
- revelation 9y agoI 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". If you want people to always ignore warnings, this is how you go about it.
- acemarke 9y agoBaloney. This is proper release management planning. People keep complaining that React is too big and needs to shrink down. They're planning to help address those complaints by removing pieces they no longer intend to maintain, or are not the primary usage going forward. So, they're putting out a minor release that will warn people these pieces are being removed, and then they'll be removed in the upcoming major release. Seems like the right approach to me.
- mtrpcic 9y agoYeah, these are basically Deprecation Warnings, which have been a standard part of good release management for a long time, across many projects in many industries.
- clay_to_n 9y agoIf you don't want to upgrade to React v16, why would you upgrade to React 15.5.0 (which includes the new warnings)?
- mparr4 9y agoOnly reason to upgrade is if you care about the specific bug fixes [1] or have your eye on React 16. Not interested in either? Then don't upgrade. [1] - fixes enumerated here: https://facebook.github.io/react/blog/2017/04/07/react-v15.5.0.html#changelog https://facebook.github.io/react/blog/2017/04/07/react-v15.5...
- garfij 9y ago> For each of these new deprecations, we've provided a codemod to automatically migrate your code. They are available as part of the react-codemod project. They gave you tools to automatically fix any new warnings that came from this. I honestly don't know how they could have made it any easier.
- bsimpson 9y agoOf course, you'd need to use super appropriately, but I wonder if anyone's taken a stab at porting React mixins to ES2105 mixins: http://justinfagnani.com/2015/12/21/real-mixins-with-javascript-classes/ http://justinfagnani.com/2015/12/21/real-mixins-with-javascr...
- acemarke 9y agoFor 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]. 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 https://github.com/markerikson/react-redux-links https://github.com/markerikson/react-redux-links . 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 https://www.reactiflux.com https://www.reactiflux.com . [0] https://www.youtube.com/watch?v=ZCuYPiUIONs https://www.youtube.com/watch?v=ZCuYPiUIONs [1] https://github.com/markerikson/react-redux-links/blob/master/react-implementation.md#react-fiber https://github.com/markerikson/react-redux-links/blob/master... [2] https://github.com/facebook/react/issues/8854 https://github.com/facebook/react/issues/8854 [3] https://github.com/facebook/react/issues/9207 https://github.com/facebook/react/issues/9207
- STRML 9y agoI was in awe the entire time Lin was speaking. Not a single "um" or other verbal tic; she's an incredible speaker and was admirably lucid throughout that entire talk. That's so difficult to do. And style aside, she made understanding Fiber incredibly simple. Just wanted to express my admiration for her work and gratitude for making this information public, available, and free.
- acemarke 9y agoAbsolutely. She's also responsible for a slew of other "Code Cartoons" writeups ( https://code-cartoons.com/ https://code-cartoons.com/ ) including Flux, Redux, Hot Reloading, and Relay, and she also wrote an incredibly good 6-part dive into WebAssembly ( https://hacks.mozilla.org/2017/02/a-cartoon-intro-to-webassembly/ https://hacks.mozilla.org/2017/02/a-cartoon-intro-to-webasse... ).
- 9y ago
- sergiotapia 9y agoAwesome changelog with great migration instructions. Bravo to the React team! Going to set aside some hours on Saturday to upgrade our React version. 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?
- acemarke 9y agoEventually, yes. The original release notes announcing functional components mentioned that they would "eventually" add some optimizations, but many people assumed that meant they already _are_ optimized. Right now, there aren't any special optimizations for functional components.
- hueller 9y agoThis 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.
- STRML 9y agoThis is a big deal to deprecate `createClass` and `propTypes`. PropTypes' deprecation is not difficult to handle, but the removal of createClass means one of two things for library maintainers: (1). They'll depend on the `create-class` shim package, or, (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. 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. It's progress, no doubt, but there will be some stumbles along the way.
- spion 9y agoIsn't there option (3) as well? Which would be, writing classes the old way, using prototypes and something like `util.inherits`
- acemarke 9y agoThat's basically what `createClass` does: https://github.com/facebook/react/blob/72196da82915bee400edb1599d4223926aa2a8a0/src/isomorphic/classic/class/ReactClass.js#L726-L831 https://github.com/facebook/react/blob/72196da82915bee400edb...
- fiatjaf 9y agoAre you afraid of Babel monopoly? I recommend trying https://buble.surge.sh/ https://buble.surge.sh/. My life is much better after I started using Buble and bubleify instead of this mess that is Babel.
- STRML 9y agoCome on. Buble is Babel, just with a few presets hardcoded. Yeah, it's better usability, until you need to run a production application.
- TheAceOfHearts 9y agoReact 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. 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. 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).
- fiatjaf 9y agoI still think JSX is a bad joke. Luckily React has nothing to do with it.
- fiatjaf 9y agoYeah, in the beggining there wasn't autobinding, if you remember well. Then comes autobinding, now there's no autobinding anymore.
- linkmotif 9y agoYeah I still use `React.createClass({})` because... autobinding. Also wish someone would explain the draw of ES6 classes. React is about composition, not inheritance. Have never seen a `React.Component` extended.
- ksherlock 9y agoSo... create-react-class is an unrelated node module. react-create-class (the correct one, I guess) is completely empty, other than the package.json.
- deleted 9y ago[deleted]
- prezjordan 9y agoLooks like the README on npm is outdated, but https://www.npmjs.com/package/create-react-class https://www.npmjs.com/package/create-react-class seems like the right one.
- acemarke 9y agoThey haven't actually moved the deprecated code out into separate packages yet - this is the warning they're about to do so. The 15.5 announcement does thank several people for "transferring ownership of package names", so I'm guessing that may be one of them.
- baron816 9y agoI hate that the React team prefers ES6 classes. This is what I do: function App(params) { const component = new React.Component(params); component.lifeCycleMethod = function() {...}; component.render = function() {...}; function privateMethod() {...} return component; }
- nostrademons 9y agoThis is the RevealingModulePattern that Crockford used to advocate back in the day, except assigning to an object that React creates instead of one you create.. http://javascript.crockford.com/private.html http://javascript.crockford.com/private.html https://addyosmani.com/resources/essentialjsdesignpatterns/book/#revealingmodulepatternjavascript https://addyosmani.com/resources/essentialjsdesignpatterns/b... Be aware that memory usage can quickly balloon with this pattern, because the GC needs to keep alive anything referenced from inside the closure, including closure objects for the private methods for each individual instantiation of the component. With normal prototypal inheritance, there's only one function object per class; that's the upside of the explicit 'this'. This (and inability of early debuggers to inspect closure variables, which has since been fixed) were what killed this technique in the 2000s. [Edit: parent post was edited to remove the code sample. I'll keep this up since apparently people are finding it informative, but be aware that I'm replying to the code sample that used to be in the parent comment, not anything in the article.]
- baron816 9y agoSorry, I was getting down voted a lot. I restored the code. I'm pretty sure Crockford still pushes this. https://weblogs.asp.net/bleroy/crockford%E2%80%99s-2014-object-creation-pattern https://weblogs.asp.net/bleroy/crockford%E2%80%99s-2014-obje... It does eat up more memory, but as Crockford says, memory is cheap. It's not likely that it'll cause a problem.
- asdfgadsfgasfdg 9y agoMemory is not cheap for your users. If your webapp (or worse webpage) burns through their memory they will come to regard it as slow, bloated and heavy and close the tab never to return.
- PudgePacket 9y agoWhy do React and other js libraries emit warnings as console.error when browsers support console.warn?
- tlrobinson 9y agoconsole.warn in most (all?) browsers' dev tools didn't/doesn't provide the full stack trace. I think that changed recently in Chrome, at least.
- xamuel 9y agoHappy 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.
- thisbloggerfeed 9y agoI agree with you. :cool: https://img.vehiclepad.com/7858b8ed64bbd127127e1761ab44a845_-maserati-222e-1990-5-sp-maserati-222e-1990_1336-800.jpeg https://img.vehiclepad.com/7858b8ed64bbd127127e1761ab44a845_...
- YCode 9y agoWhat's wrong with propTypes?
- xamuel 9y agoIn a non-Typescript project, they're a shoddy half-baked type system duct-taped together. In a Typescript project, they're almost completely redundant, they add a huge maintenance burden for basically no gain.
- nathan_f77 9y agoI've been using Flow in my React Native app, but I still find PropTypes very useful, because warnings pop up in the iOS simulator whenever a prop is invalid. I think it's important to have both compile-time and run-time checks. I recently (5 minutes ago) discovered 'flow-runtime' [1], which gives you the best of both worlds. It automatically generates PropTypes from your Flow types, as well as checking all of your other types at run-time. [1] https://codemix.github.io/flow-runtime/ https://codemix.github.io/flow-runtime/
- whitefish 9y agoI'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". Unlike real web components, React components are brittle since React does not have the equivalent of Shadow DOM.
- frik 9y agoAs soon as Shadow DOM v1 is implemented and active in stable in Chrome, Safari and Firefox, I am pretty sure it will start a new trend. And React might be persived like JQuery, Ember, Angular1 as a fad, that has been superseeded by new native browser capabilities. KISS. https://en.wikipedia.org/wiki/Web_Components https://en.wikipedia.org/wiki/Web_Components
- mlsarecmg 9y agoIt won't. Web components are simple encapsulation sugar. Apps still have no means for dynamic structures while all the terrible templating pitfalls that frameworks like Angular brought are still present. React is a real solution. It isn't even a question or an "if" any longer. React has taken over, or rather, its principles have. They're clean, concise and don't twist the slightest standard all the while not breaking a sweat. React has grown so powerful it isn't even just about the browser any longer. It runs everywhere. The browser has finally become a dumb pipe, something it should always have been. Web components are trying to reverse that, but you'd be ignoring innovation if you fell for it.
- whitefish 9y agoYou can use JSX for Web Components too, see: https://github.com/wisercoder/uibuilder https://github.com/wisercoder/uibuilder There is no need for a complex framework like React. Web Components + JSX is better than React. Why use a proprietary framework with patent issues when you could be using a standards based solution instead?
- mlsarecmg 9y ago
- smdz 9y agoI absolutely love how React+TypeScript setup handles PropTypes elegantly. And then you get the amazing intellisense automatically. ``` interface State {} interface ISomeComponentProps { title: string; tooltip?: string .... } @ReduxConnected export class SomeComponent extends React.Component<ISomeComponentProps, State> { .... ```
- amk_ 9y agoThe 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. Anyone have experience with this sort of thing?
- danabramov 9y agoSwitching to create-react-class sounds reasonable, that's what we intended. It will work in older versions too.
- amk_ 9y agoIf we switch to it as a hard dependency, library consumers on React <16 will have an extra package in the bundle. If we make it an optional peer dependency, package.json becomes less reliable because we would need to check where createClass is implemented at runtime. Is create-react-class smart enough to determine whether the version of React it is augmenting already implements createClass to prevent bundle size bloat?
- cynx 9y agogetting ready for fiber
- uranian 9y agoWhat 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? 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.. 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. In my opinion this is not only irresponsible, but very arrogant as well. 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. 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. 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.
- Rygu 9y agoAlthough I don't agree with the overall sentiment of your message, I do understand your situation as a professional. In fact I believe by far the largest (less vocal) group of React users only use it at work, and never wilfully agreed to spend their spare time on GitHub because of FOMO, or fear of dependency upgrades (FODU). And I believe there should be a better way to prepare your users for a major version upgrade (React 15 -> 16) than to update the current branch with all kinds of deprecation warnings. Even if a library - as popular as React - doesn't plan to provide lifetime support for any major because they like to to move fast, I understand that, it's simply not okay to ruin older branches this way, madly assuming everyone is surely going to upgrade to React 16 in the immediate future. Ideally, I'd imagine there could be a separate optional package that adds these warnings dynamically. If that's not possible technically, then an optional build flag would be nice. Or two separate releases: react-15.5.0 and react-15.5.0-upgrade-support. Even better: go back to semver, and treat major upgrades as optional for the first 6 months. This allows other libraries like routers and style libs to catch up, so app devs can upgrade even more smoothly. Maybe after all, DX is about when to provide helpful errors and warnings. And when not to?
- aswanson 9y agoI cannot keep up. I just started learning react/apollo/graphql and I'm already out of date.
- TeMPOraL 9y agoI figure web development today works like this: there's no reason to learn any framework thoroughly, because other people did already and there's enough them on StackOverflow to get you out of any difficult situation. The landscape moves too fast for learning anything to be worth it. Also, most webdev is pretty throwaway, which means it's totally fine to get yourself out of trouble with piles of unmaintainable hacks. It'll all get rewritten in a new framework du jour two years from now, anyway.
- danabramov 9y agoYou're not out of date. :-) Two APIs moved from one package to another. That's all. I understand it can be frustrating but there is no big change to learn here. Your code will still work in 15, and we print warnings telling exactly what to do to prepare for 16. And we provide tools to automate this change for your existing code.
- lngnmn 9y agoWhy 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. 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. 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? Google's responsive design looks like the last tiny island of sanity.
- danabramov 9y agoReact removed extra dependencies that some people don't use, not added. Not sure what this has to do with PHP, J2EE, or Babel. Your comment sounds a bit like misdirected rant but if you have specific concerns about React we are happy to discuss! Cheers.
- Drdrdrq 9y agoJust 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?
- bpicolo 9y agohttps://code.facebook.com/pages/850928938376556 https://code.facebook.com/pages/850928938376556 It's purely defensive, they'll only revoke your license if you sue them for patent infringement. And they only revoke the patent-grant of React as far as I can tell, not your license to use it (and there aren't any patents related to React as far as the internet claims).
- DenisM 9y agoWhich in turn means they can infringe on any of your patents with no consequences. If they do, your only choice is to rewrite your entire application in a hurry, and only then you can sue them.
- deleted 9y ago[deleted]
- tracker1 9y agoOf course if you use a similar competing technology and choose to sue them over patents, they could still find you infringing and sue you anyway.
- iLemming 9y agoI wonder how these changes would affect Clojurescript libs built on top of React, e.g.: Om.Next and Reagent