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].
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 . 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 .
I 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.
As someone who talks quite (very?) fast and has to carefully slow down for public speaking...
... I found Lin's style of speaking very difficult to listen to. I appreciate the professionalism of the approach (if that's what it is), but if only by a small margin (perhaps 10-20%), I found her speaking too slow to the point that I wanted to skip forward constantly and would have found it difficult to pay attention to in person. :/
Perhaps this might be about the structuring of information as well (I'm familiar with much of what's being talked about). That said however, I've historically found that when listening to really good speakers, I find it easy to sit and have explained to me things that I already know well - so I'm not sure what's happening here.
There is also a minimal Chrome extension called 'Video Speed Controller' that brings this functionality to all HTML5 videos with a bit more granularity. It's invaluable.
I dunno if verbal tics are necessarily the metric to use for great presentations. I know some folks who stumble constantly but present ideas that are pretty incredible. Some people just have amazing recall and can fluidly spew out facts and conclusions. Some people can present compelling ideas they have thought of that no one else but struggle on the vocalization.
Yeah and some people use them to their advantage. For instance, notice that President Obama uses "umms" to ensure that he's never not making a sound. Makes it harder for an interlocutor to interrupt.
Huh? That's funny--I would have said the opposite. It was from watching Obama's speeches that I learned that silent pauses can be much less annoying than "umms". If you want to see someone using a lot of "umms", watch Justin Trudeau.
Terrific presentation and speaker style - I couldn't come close - but she has at least one very common verbal tic that was pointed out in my own speaking style, and now it galls constantly. That's starting a sentence or phrase with a gratuitous "so".
I don't mind if "so" starts a sentence as long as it really means "therefore" but most of Lin's instances don't qualify.
Her "so" affliction is really pretty low compared to most public speakers, but it is there.
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.
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).
The only benefit to the template is if you use fancy features (#each, binding, etc) which is worse because now you have two places where the logic happens.
JSX is a macro (it's expended to plain JS at compile time). Almost every other major framework uses DSLs (strings are evaluated and transformed into code at run time).
Basically nobody does this, as far as I know. I think some of the big component authors like Wijmo do, but not most people, it's way too messy.
The composition is usually in the form of higher order components. It's very simple to wrap a function with another one, with more or different functionality. Classes just make it equally as simple when the wrapped component has its own state to manage.
Point is, nobody really cares whether they're ES6 or createClass, because nobody's actually doing inheritance. It's just that we JS devs like to stay on the bleeding edge, and we like to think that we're converging on standards even if that's a silly dream.
Example: show a spinner for 1 second before displaying.
const F = (props) => <div>{props.content}</div>;
class C extends React.Component {
state = { initial: "state" };
render = () => <div>{this.state.initial}</div>;
}
function delayWithSpinner(WrappedComponent) {
return class extends React.Component {
state = { showSpinner: true };
stop = () {
this.setState({ showSpinner: false });
}
render() {
return this.state.showSpinner
? <Spinner duration={this.props.duration} onCompletion={this.stop}/>
: <WrappedComponent {...this.props}/>
}
}
}
// exactly the same composition pattern for
// both classes and functions.
const SlowC = delayWithSpinner(C);
const SlowF = delayWithSpinner(F);
> 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 have a fairly large react codebase with some components using inheritance. It's not the solution to every problem certainly, but sometimes an abstract base component can be useful.
ES6 classes are a complete mess brought by corporate people loving OO, even in a setting that doesn't make sense.
You can "autobind" with this notation:
myMethod = () => {
}
but it doesn't look as good as myMethod() {} and you have to remember this EVERY TIME you add a method.
Also, you never need to use the constructor in React.
Just do: state = {} in the body of the class.
You may need babel presets #918718$$&ééàdi for it to work though.
Classes and inheritance are features of type systems, not OOP. Plenty of functional programming JS libraries use classes for testing types (for example, the Either monads' Left and Right).
This 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.
I think what we need is a mix between a module bundler and package manager. When you pull in a dependency, it should confirm the code can run on all your targets. If it wouldn't run, e.g. ES2015 classes but you have an ES5 target, it should be compiled. That way when you bundle your app, you can skip the compilation check on all third-party modules. Adopting an incremental compilation strategy will also speed up larger apps.
It's really time to start distributing ES6 via npm. All current browsers support ES6. It's now generally faster than equivalent ES5, it minifies better, tooling is better, etc.
It's the app that should compile all the code to run in the target environment if needed. This is what we've done in the new Polymer CLI / polymer-build: we compile all dependencies but only if necessary.
That's debatable, particularly when you factor in bugs. However, even if they did, it seems unwise to assume that all relevant users for all or even most projects will be on the latest evergreen browsers. Several large groups, including business users on IE and mobile users on slightly older devices, probably won't be.
I know there's a certain type of web developer who would love for everyone to have updated their browser within the last five minutes so all the new toys are available universally, but that has never been the nature of web development. Deliberately breaking major infrastructure is just going to make JS development even more screwed up than it already is.
This is a common theme I'm noticing a lot lately. Meanwhile, I check my product's browser breakdown and IE9/10 is still too significant to ignore. There's just no way our customers would be okay with this. Many are still locked on older IE versions due to (bad) corporate policies. I can't strongarm them into upgrading.
Which leads me to wonder: are developers that are so willing to advocate breaking compatibility with older browsers actually deploying real sites that have normal representative user audiences? Or is this an insular group of developers mostly making things for each other?
For whatever my anec-data is worth, I run a sports stats website as a hobby (which has a decidedly non-developer user base), and when looking at my own user breakdown I found that less than .1% of my traffic was IE10 or below.
So while there's still likely an insular group at play, it's not limited to just developers.
Stats for older IE versions are similar for most sites/apps I'm involved with, though I know in some niches they are still important.
IE11 is a different case entirely, though. Almost everything still gets significant traffic on that platform, and in the business world supporting it is pretty much essential. Not much ES6 support there, though.
Yeah that's interesting. I might be biased since I'm in an exclusive B2B market.
Still though, it's hard to adopt a policy that axes even just 1% of your customer base just for the sake of easier development cycles when alternate options exist.
Oh, I completely agree. If in your circumstances older IE builds are still significant then of course you might want to continue supporting them. I'm just suggesting that that issue is somewhat separate to the original point, because in the case of ES6 support, even the latest version of IE doesn't have it.
I'm afraid this culture is now endemic in web development. Everyone expects everything to be free, so the people building most of the tools, from the libraries to the browsers themselves, are mostly either doing it for fun as an amateur or doing it professionally in order to support something that does bring in revenues. Neither of these necessarily implies writing or maintaining ideal tools to support web development more widely; any wider benefit is largely coincidental. Unfortunately, because so much of the influence is now concentrated with so few organisations or even individual people, and most of them are aligned on this, it's going to be difficult to return to a more widely supportive ecosystem now.
Let's dispense with the "amateurs" first: the complete stack is build almost exclusively by people employed by Google, Facebook, Apple, Mozilla, and a handful of smaller, but at least as professional, companies.
Then, I don't understand the rest of the argument. Open Source software has simply won in the marketplace, mostly because of it's openness, rarely because of it's price.
Example: Operating Systems, which is the rare beast where an actual closed-source competitor still exists. Yet the Windows marketshare on the server is around 10%, and I doubt that it's the price that encourages all those Unicorns to chose Linux. Databases are a similar story.
> Neither of these necessarily implies writing or maintaining ideal tools to support web development more widely
It doesn't necessarily do that, but in the case of Google specifically, it does: they need the open web as a platform to compete against the "walled gardens" of Apple and Facebook. Their interests happen to be aligned with those of web developers, which is why Chrome has revitalised browser competition, easily beating the laser-focused team at Mozilla.
> Unfortunately, because so much of the influence is now concentrated with so few organisations or even individual people
The influence is spread out far wider today than it was at the time where Microsoft and Flash were able write APIs without asking anybody.
But, more importantly, I'm unsure what you want? A version of React that supports IE 6 and lynx? They have that, it's called XHTML 1.0 Transitional.
Let's dispense with the "amateurs" first: the complete stack is build almost exclusively by people employed by Google, Facebook, Apple, Mozilla, and a handful of smaller, but at least as professional, companies.
You might like to take a look at the history of Babel (formerly 6to5) as one prominent counter-example. For several years, much of the web development community has been relying on a great tool that was originally written by one talented young amateur.
Open Source software has simply won in the marketplace, mostly because of it's openness, rarely because of it's price.
Chrome being prominently advertised every time anyone visited a Google site using another browser probably didn't hurt. Being installed by default on the most popular mobile OS also didn't hurt. If openness were all it took, Firefox would surely still be a more prominent player.
It doesn't necessarily do that, but in the case of Google specifically, it does: they need the open web as a platform to compete against the "walled gardens" of Apple and Facebook.
Google wants people to use the Web because it makes its money primarily from advertising on web sites. It is in Google's direct financial interest to support the part of the Web ecosystem that in turn supports advertising. That typically doesn't include, for example, corporate intranets, or embedded UIs in network-connected devices, or academic sites, which are three big areas where web technologies are widely used but stability and long-lasting content are more highly valued.
Their interests happen to be aligned with those of web developers, which is why Chrome has revitalised browser competition
Writing as a professional web developer who often works in those other areas I mentioned, Chrome hasn't revitalised browser competition. On the contrary, it's become the new IE from the old browser wars. A lot of the new functionality only works properly in Chrome, and often it's not reliable even there because of the frequent updates that change behaviour and/or introduce regressions. There's no real concern about proper standardisation or compatibility or longevity any more.
But, more importantly, I'm unsure what you want?
I want the fundamental tools on which much of the ecosystem now relies not to break everything that predates a standard that is less than two years old and still not fully supported across many active browsers. In this case, that means being able to install packages from NPM with a reasonable expectation that they will not require a substantial extra build process to be used.
Obviously no-one contributing NPM packages has any obligation to respect that. It's not as if we're all paying for their openly licensed work. I just think the community as a whole will otherwise suffer yet more overheads getting infrastructure set up instead of actually getting useful work done.
Agree. This is Maker's Triangle stuff (Good, Cheap or Fast, pick two). Everyone is picking Cheap and Fast, and not only Cheap, but Free, so the amount of Good left in this stuff is non-existent.
If there's no Good chosen, then it all gets crufty and full of tech debt. So someone else thinks they can do better, and starts developing a replacement. In order to get traction, though, they need to make it Free and develop it Fast, so after a while they start taking a few short-cuts, and round we go again.
I have faith that it'll settle down eventually, but until then...
I'm unsure if this Maker's Triangle thing applies to OSS. But if it does, it's my impression that it's usually the "Fast" that is abandoned, not the "Good".
But how does that apply to Chrome, or React? Is there any indication that Chrome carries more technical debt than, say IE7? Similarly, in what way does Facebook need people to adopt React, and would that matter enough to accept such compromises? Is there any indication that their code quality is inferior to <pick whatever commercial js library you want>?
And if this is the complaint about churn, that, at this time would be older than our js stack if it were true: React came out in 2013, it's four years old. Before that, most people probably used JQuery, which came out in 2006, i. e. 11 years ago. Is learning a new library every five years too much, considering this is one of the most dynamically evolving ecosystems of technology?
To continue the analogy, the JavaScript community doesn't believe in technical debt. It just declares itself bankrupt every few weeks and moves on, leaving anyone who was relying on earlier arrangements to cover the costs.
To extend it further, this is why you should be very careful who you give credit to in the JavaScript ecosystem. If you're trying to build anything robust and potentially long-lived, relying on anything but the largest and most established dependencies is usually unwise, and even then relying on any any aspect that isn't in mainstream use is a risk.
As someone who's been building against browser/web tech for over two decades now... that React is emphatically no less than "Good"... The diagnostic messages alone are leaps and bounds ahead of anything else I've used. Angular just breaks in weird ways with no warnings, sometimes non-sense error messages, other platforms likewise... React regularly warns on usage that might break something in the next release, and more than a clue how to fix it. Nothing else I've used comes close to that. Not that it was your implication.
Now, I'll admit, I've dev'd against React and deployed with preact-compat as a build sub for size... but a couple times back to React for broader support, and it really didn't save on speed anyway.
React is hands down the first web tech I've used (out of dozens of platforms and toolkits over the years) that just made sense. Not everything I agree with, and would love some adjustments. All the same, more often than not, it does what I expect, and I definitely can't say that of most of the rest.
As to jQuery, I think it's a great idea, was and still is in a lot of ways. I do wish they'd just drop their XHR, and Promise implementation at this point... but the selection library + eventing is cool and easier to grasp to this day, despite going without it for about 2 years now. There are cases where it was just nice, and still is.
I'm actually fine with JSX, imho it's better having some XML in my JS than it ever was having weird DSL in templates in JS.
I think that there is a real split between consumer and corporate at this point (certainly in the West). Some managed corporate setups are definitely still on old versions of IE, but for everyone else, the path of least resistance has been auto-updated platforms for a while now (Windows 10 + Edge, iOS, Chrome, Firefox).
Recently, I updated the browser support docs for my employer, and was surprised to note that IE11 is now the oldest browser with standard vendor support, so everybody on older versions of IE is either working for a company with specific extended support contracts with Microsoft, or they are running with no support at all.
I propose a warning... "For security reasons, all versions of Internet Explorer are no longer supported. Please upgrade to a modern/current browser such as Chrome, Firefox or Edge."
Make sure to state "For security reasons" policies always have that even when it's not true, or bad security, because most people don't question it.
That would scare the hell out of my users and immediately increase support volume by a not insignificant amount. There's not a lot of sense in doing that anyways since many/most of the users stuck on old browser versions are stuck due to corporate policy.
The situation has really improved, mostly due to auto-updating, increased competition between browsers, the iPhone's power to compel modernisation, and the resulting fading of proprietary technology like flash or ActiveX.
Sure, google.com probably needs to support IE 6. For my own business, I'm not willing to make compromises for browsers below 2%. That currently means Safari 10, Chrome 56, and IE 11. And IE 11 is really stretching it by now–next time it gets in my way, I'll give people a reason to upgrade.
Now I don't have "enterprise" customers, and it's a rather small business. For anything medium-size up, the calculus changes, and probably makes it worthwhile. But at some point, these mystical "enterprises" really have to get their act together and stop dragging technology back to 2006.
This can be justified. Multiple times I'd been in the spot when shipping of a feature by a certain date will get your contract signed. And this is dependant of how convenient your workflow is.
particularly for a young or fast-growing product, this makes a ton of sense - shipping features that multiply your target market can be a _much_ better strategy than keeping 2% of your current user base.
Chrome, Firefox, Edge, Safari and Opera all support ES6. That's the current version of all major browsers.
But, I'm not arguing that web sites should only serve ES6 to browsers, only that packages should be distributed as ES6 and the app should be responsible for compilation.
Chrome, Firefox, Edge, Safari and Opera all support ES6. That's the current version of all major browsers.
No, it isn't. For a lot of web developers, two of those aren't major browsers at all and you've missed the 800lb gorilla. You're also ignoring older versions of mobile browsers, the current Firefox ESR, and at least one other browser that has a larger market share than several of the above in parts of Asia, among other things.
But, I'm not arguing that web sites should only serve ES6 to browsers, only that packages should be distributed as ES6 and the app should be responsible for compilation.
And consequently, the entire community has to start incorporating a heavyweight build process that relies on third party tools just to use modules from the de facto standard package repository, and everyone also has to take extra time checking the exact requirements for every module they directly or indirectly depend on to make sure their build process supports it. In an ecosystem with absurd levels of microdependencies, which is certainly what we have today in JS world, the last thing we need is moving goalposts on the basic assumptions that everyone makes. This sort of thing is exactly why proper, long-lived standards are important as the foundation of a productive development ecosystem.
Yes, "current version" specifically doesn't include "older versions", that should be uncontroversial.
Not sure the 800lb gorilla you're referring to, but maybe UC Browser? That thing is so odd it's difficult to know what it supports, and it's not supported in nearly any popular CI service. I'm sure all kinds of things are broken on it, but you can still compile your app to ES5.
And ES6 _is_ a proper long lived standard. I'm not sure what would be more standard.
Compiling dependencies is not that heavyweight, especially when there is no configuration. Babel and TypeScript are fast. The results can be cached, it can be done on the fly for dev servers. Requirements shouldn't need to be checked - I'm not advocating for distributing code using decorators or class properties, nor modules (which without the HTML spec on module specifiers isn't a fully functional spec anyway) just plain ES6.
ES5 and ES6 classes cannot coexist on the same proto chain. Compiling to ES5 prevents things like mixins being usable against ES6 superclasses, so you force all dependents to be ES6. If you're going to force one way or the other, force in the future direction where there's still the option to compile the whole app to the older version of JS. ES5 classes can't extend subclassable built-ins like Array, Promise, Set, Map, HTMLElement, Error, etc. ES5 is now mostly slower than the equivalent ES6, it also doesn't minify as well as ES6.
There's still a handful of features (though far fewer than 2 years ago) that I need babel for anyway, so just sticking with that, and may adjust my babel-preset-env config as things change. I may even do dual builds, one for bleeding edge (a bit more than half the users) and a catch-all ES5 build. YMMV.
I agree that this is the future. But that will mean telling everyone that they should now run their node_modules through Babel - no inconsequential feat, given the size of the code that must now be transpiled.
It's not just that - is JSX part of ES6? It isn't, but a lot of pre-Babel transpiled code uses it. So people would need to transpile to ES6 for distribution, then to ES5 when someone uses the library.
EDIT: I should add, that I didn't want to say that I completely disagree with the change to remvoe this api entirely on twitter to the maintainers. I am sure they get enough crap from people.
Well thanks then! I know social media sucks for this kind of stuff. And I am sorry for my contribution to that. And know we really all do appreciate it, we are just passionate and opinionated people.
Personally I am more concerned about keeping my team building cool features than updating react. This has led to us having two distinctly non-interoperable code bases, one with react 0.12 and one with react 14-15. This makes me worried that now we will have a third with react >15.
I think we can all agree that many of the ideas, while not new, were revolutionary to front-end web developers. And that is what I love about working in this stack. But other than these ideas, the projects themselves are just stumbling along trying to catch up with some perceived "modern" way of coding, and it is the dev teams and projects that suffer.
Are you afraid of Babel monopoly? I recommend trying https://buble.surge.sh/. My life is much better after I started using Buble and bubleify instead of this mess that is Babel.
Yeah, I'm actually completely wrong. My apologies to the Buble team. For whatever reason, I thought I saw an announcement of Buble essentially saying it was an opinionated feature-freeze of Babel with most of the configuration stripped out, but it appears to be a totally new project.
That said, the two are very different tools. Buble appears to be essentially string manipulation (which Babel does to occasionally with babel-template) built on top of Acorn. It's much simpler but there are a lot of useful transformations you simply can't do with that approach.
Edit: After some further looking into the project, I have to say that it seems like it would nice & easy to use for simple transformations, like the aforementioned React.createClass -> class Foo extends React.Component. However, you have to keep in mind that code that is not spec-compliant will break in mysterious ways perhaps months or years into the future. It may not be worth it, despite the ease.
`yarn install babel-cli babel-preset-es2015; ./node_modules/.bin/babel --presets es2015 <sources> -d <out-dir>` is not particularly difficult.
> will break in mysterious ways perhaps months or years into the future
Since you already recognized you know nothing about Buble can you please stop making absurd claims about THINGS YOU DON'T KNOW?
What are specs, by the way? I don't care if Buble isn't following stupid specs. Browser vendors will change these specs a million times, Babel will follow up with new versions with a thousand breaking changes and require you to install a ton of packages, clean old packages, erase your hard disk and kill your neighbours. Buble will just keep working.
you know...if it can be transpiled by babel that means you could write it in es5 compatible syntax...yourself...so if you don't want to use the babel tool chain...what's stopping you? Don't know es5? IMO it's not too fun compared to es6...but...
We use Flow everywhere now and love it. It's not perfect by any means but it's a lot easier to use than Java's static typing and a lot more expressive to boot. I can't overstate how great it is to be able to strongly type your modules and ensure you don't send the wrong input or receive the wrong input from them.
In fact, Flow allows us to confidently implement APIs that would just be cumbersome otherwise; we can use complex string keys for UI actions, rendered templates, etc., and make Flow actually enforce them via its $Keys<T> helper. This has the incredible effect of making it a type error if you try to execute an action that doesn't exist.
Cumbersome APIs become easy with Flow, and that's just scratching the surface of its utility on any sufficiently-complex JS project. It's nothing but wins for your development team.
TS is great too. Honestly, either way is a giant leap forward.
Flow is quite good, but over half of our React codebase is components connected to Redux or Redux Form and unfortunately there are no Flow types for the versions that we use, so type inference is very weak at some points.
Besides, Flow has a very ambitious target of delivering types for APIs which were not written with types in mind at all. I thought I'd be able to recreate some of the Elm's type safety with Flow, but that's just not possible and I doubt it'll ever be. But then again, these two projects have very different objectives.
> This has the incredible effect of making it a type error if you try to execute an action that doesn't exist.
I don't want to start a "JavaScript is bad" flamewar, but it's sad that there is an entire class of problems that we as software developers are solving, where simple type checking seems amazing
Sure, but with ES2016 and Flow, JavaScript becomes a completely different language. And with V8, it's very fast. I actually really enjoy writing JavaScript now, and I recently realized that I like it more than Ruby.
Yes - and no. Flow can express some really complex types that were previously only possible in much more esoteric (or modern) languages. Types as many people know them from Java, C#, etc., are more mature (aka fewer bugs), but far less powerful.
For example:
The utility types in https://flow.org/en/docs/types/utilities/ can be used to great effect to express things like "A type of the keys of T, but values passed through this function" or "A type that is the difference of these two maps".
In practice, this helps me write things like React Components that take some of their props from the root store via context, and the rest of their props directly, and for Flow to actually know which is which just by reading the code (no explicit typedefs!), override root store props as needed (so long as I don't change their types), and throw a type error if I miss or misdefine one. Awesome.
I agree, but for those considering using flow please beware that it's not a trivial undertaking. I recently converted a small app. There were several mind benders—beyond basic types, annotations can get pretty tricky—and the tooling isn't quite seamless. This is not to discourage you. You may well decide it's worth the effort.
Technically true, but how many projects actually are 100% typed, including:
* absolutely no any types or other imprecise types, no files skipped, no lines skipped, etc
* every single piece of external data (API requests, reading from localstorage/IndexedDB, etc) is explicitly validated to make sure it exactly conforms to expectations
* all dependencies are also typed to the same standard (not just some type definitions slapped on top of an npm module, those could easily be wrong and often are)
Probably some are. But none of mine are, sadly. And I don't think I'm in the minority.
You could make some of the same arguments against prop types - what if you miss them, what if they are incorrect (too narrow).
Regarding third party libraries, with prop types you are effectively writing your own bindings to the parts of those libraries that happen to go through your props, except you fail far away from where the error is produced.
Prop types are also a very ad-hoc solution to a very general problem. Why are props for UI components especially deserving of type checking? What about the rest of your application code? Event your components' state is not worthy of type checking?
With JS or typed-JS languages like Typescript or Flow you will never get full type safety (Flow is better at safety than TS if you're interested). For me the solution is to either go 80% of the way for 20% of the effort with those languages, or go full Scala.js or something that is actually type safe. And the latter has many goodies like https://github.com/lihaoyi/autowire to make API calls typed.
Let's not forgot prop type checks are removed during build (if you are building). So they don't happen in production. Like some kind of type erasure, but not :D.
If you don't trust your JSON input to be of proper type, you should validate its type immediately when you receive it, before you start fanning it out to your code. Spreading this work to prop types just makes it harder to keep track of it, and harder to find the source of the problem.
Besides, some of that broken JSON data might never even be passed through proptypes (e.g. if that data lives only in a component's state).
Flow’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.
We 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.
Same, 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.
I 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
That's true, but I think that's a very good thing. It can be very useful to define "StateTypes", as well as PropTypes. I think I've caught more than a few bugs by defining types for my state.
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.
If 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?
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.
I was the guy who came up with autobinding in older Reacts and I'm glad to see it gone. It might save you a few keystrokes but it allocates functions that'll never be called in 90% of cases and has noticeable performance degradation. Getting rid of autobinding is a good thing.
As much as I agree with the performance side here, I believe the usability for devs is an important factor. Let the users who really need that last bit of perf opt-in, and let everyone else just go along in blissful ignorance. And I am honestly alright if "opt-in" means use preact or some other project.
Think about the reasons jQuery and WordPress were popular, despite performance issues, they JUST WORKED for people. React is the jQuery of vdom projects, don't try to make it the something it is not.
Don't you think the fact that React.createClass() behaves differently than JS makes it less usable (i.e. more surprising) for experienced developers? The goal of React is not to fix JavaScript's warts, nor is its goal to make programming easier for non-programmers. I believe if this is the goal of your project the end result would look very different from React (probably would look more like Vue).
Where did we mention making programming easier for non-programmers? I think libraries should strive to be as usable as possible to _all_ programmers, which in this case means reducing or eliminating very common operations (such as binding callback functions). When we're talking about working on a large codebase, useless boilerplate is a legimate cost both in productivity and maintenance.
I 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.
I'm one of those people that still use coffeescript (if I'm going to transpile anyway, I'd rather use a language I like).
I use coffeescript classes as components without any problem and that inserts an "extends" function into every compiled .js-file that has a class.
I suspect people that need ES5/ES6 compatibility that currently rely on React.createClass as a peer dependency can switch to maintaining their own createClass function local to the project. Suboptimal, but not a lot of code.
>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.
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.
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?
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.
Although 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?
The JavaScript world is going to fragment soon. I'm an old school JavaScript developer... I'm not interested in Async, I'm not interested in promises, I'm not interested in classes. I think Javascript had some incredibly powerful features (functional, event-driven, small language) and ES6 removes all of those features.
I totally understand why the ES6 community likes it. It lets you write very Rubyish code and has lots of ergonomics for developers who don't want to have to think through the kinds of problems that functional programming forces you to think through. It's a push towards the Rails declarative aesthetic and away from functional/imperative. Declarative programming makes you feel like a wizard, until you have to debug something and then you feel like you don't know how to code at all. I've come to terms with the fact that the majority of JavaScript developers like this change.
But as libraries slowly drift out of compatibility with the older Node-style of programming, there comes a point where it's really a completely new language.
I think we're in for a fork of the community. Maybe there can be one runtime, but I think we're going to start seeing an alternative to NPM that allows developers to have an opinion about what JavaScript is.
What the hell are you talking about? None of those features are removed. The issue at hand is that we are developing more and more complex single page apps and we desire our primary language to support that trend.
Don't use classes. Don't use promises. Can't comment on what you said about async since it's literally nonsensical.
There is no fork coming, or if there is, it will only be used by a tiny portion of the community who thinks they are brilliant because they can "think through" functional programming problems but don't understand what role async calls play in modern development.
Can't not use promises because they're littered all over NPM now.
Not sure what's wrong with what I said about async? it's a new keyword in ES2017. It's a difficult to use control structure that doesn't do anything you couldn't do with callbacks. What part of "modern programming" do you need Async for?
I don't think I'm brilliant for being able to think through basic functional programming concepts. Actually the opposite... I think you need to be very smart to understand and debug promises, that's why they are bad. I like callbacks because they don't require me to be smart.
Maybe I'm smart for knowing I'm shooting my future self in the foot when I write code that requires smarts, but that's a little convoluted. The reason I care is because the ES6 community sold out beginners by adding all of this syntactic sugar. Javascript used to be a good beginner language.
Awesome 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?
Eventually, 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.
Fiber 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.
This 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.
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".
Unlike real web components, React components are brittle since React does not have the equivalent of Shadow DOM.
Nothing stops you from using web components in React. There's even standalone (https://github.com/Wildhoney/Standalone) which allows you to transform React components into common web components.
But modelling React into web components makes about zero sense. The spec started many years ago and it is utterly outdated and useless. Web components aren't event components, they are pluggable templates. They expose all the problems and issues that React has already solved. While web components are dependent on vendor policies and specs, yet do a fraction of what a React component does, React is already out there serving apps to mobile, desktops, shell console, watches and so on - because it is what web components should have been.
The problem when you use Web Components in JSX is that there is no way to wire up any custom events fired by the Web Component. JSX will only wire up "known events".
That's just when you use custom elements in _React_.
I've definitely wired up JSX createElement implementations that handle attributes and events properly. My preference is for Polymer-style naming: `on-*` for event handlers, `$` suffix for attributes and everything else is a property. Others who've done this use special `attributes` and `events` properties.
As 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.
It 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.
You can use JSX for Web Components too, see:
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?
React is not complex, it solves complex problems, elegantly. Web components make it worse than it already is. By catering to the dom they fragment HTML even further. Now you rely on attributes for "if", "each", "of", "loop" and so on. It literally enforces frameworks shipping template parsers and script engines that duplicate and fight against Javascript, each with their own syntax. Without frameworks like Polymer you only get encapsulation and that's utterly pointless.
The extensible web is about low-level access. Web components go against everything that stands for. They're again pushing a bad vision that was decided on almost 10 years ago by people sitting in a closed room trying to interfere with how we write apps, resulting in a useless spec that adds complexity and weight. That spec btw took years of pushback against Apple and other vendors that weren't even interested in web apps rivalling their native stores. They have eventually given it green light because the spec is so tame it won't threaten a native app in a hundred years.
React on the other hand isn't much more than a simple idea:
const Component = ({ text }) => <span>{text}</span>
const Another = () => <Component text="hi there" />
We can express UI declaratively and functionally. It solves our problems and pretty much has set the web free. Now there are dozens of frameworks that follow these principles, it's made it possible for Javascript to move on to native space, other platforms and devices. We're closer to truly universal apps than ever. Nothing proprietary about it, just technology that has managed to come through by its own merits which has evolved into an actual, living standard.
The W3C has the worst kind of track record, don't expect anyone to fall for all this hand waving for "standards," no one is that naive anymore. If a spec doesn't perform it gets discarded and by this point we already know web component don't.
This 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..
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.]
Memory 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.
Care to add more to this? I've been doing javascript in some form or another for 10 years. We've always been able to do something "class like", but having actual real classes in ES6 is great. What is there not to like?
I think this is just a trope that JS devs and newbies have launched on to, and that it's without merit.
Classes are good. Classes express concrete taxonomies of concrete things in ways that most developers can understand.
I think we should be happy that JS is flexible enough that adding "class" to the language is almost purely syntactical: it clarifies and makes semantic a bunch of otherwise boilerplate "Foo.prototype.blah" code that you see in so many non-trivial JS apps.
There's nothing wrong with classes, they're just not right for JavaScript. I'm not going to claim that I'm a JS expert or anything, this is just something I've learned from pretty well established JS experts like Kyle Simpson and Douglas Crockford.
The reasons they give are that 1) you should favor composition and delegation over classical inheritance 2) classes keep you from using and understanding closure and other functional patterns and 3) you just get a lot of really weird behavior when trying to use classes in JS which results in a lot of confusion and wasted time, especially for those who don't have 10 years of experience under their belt.
It's worth noting that the React team promotes composition over inheritance, and discourages any levels of inheritance past `class MyComponent extends React.Component`.
Long term, the React team plans to investigate concepts like "stateful functional components", but until then, classes are the most straightforward way of having lifecycles. The existence of ES6 classes is based on the wide range of third-party "class" implementations across the JS ecosystem, so clearly there was a desire to have them available. Since they're available, React is using them.
I was responding to a comment saying "classes are a bad idea in JS in general". `React.createClass` is a homegrown implementation of classes, React.Component builds on ES6 classes, both would be disliked by Kyle Simpson or Douglas Crockford.
There are three major differences between `createClass` and React.Component:
- Autobinding
- Mixins
- Custom class system vs one that's built into the language
Autobinding is the most useful aspect, but there's a variety of ways to deal with it: use the Class Properties syntax and write methods as arrow functions, use one of the many autobind utilities in a constructor, write your own base class that extends React.Component and do autobinding in its constructor, etc.
Mixins are now a discouraged approach for writing React code. If you still want to use mixins in React components, there's some "compat component" classes on NPM, or you could use a non-React-specific method of applying mixins.
And finally, deprecating a custom class implementation means that it's one less thing the React team has to maintain, and the lib size is that much smaller.
To me, classes make more sense when you carry context with event binding, which components often do. It's syntax sugar over the Foo.prototype.* drivel, and I don't mind it...
That said, I tent to follow more functional patterns for workflows (prefer Redux and similar extension), but for some components the class syntax is usually nicer. Most components are probably best served as simple render methods though.
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.
I'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.
In 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.
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?
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).
Which 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.
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.
I 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.
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".
If you want people to always ignore warnings, this is how you go about it.
Baloney. 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.
Yeah, 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.
> 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.
Interesting, I didn't expect a downvotes. If this is factually incorrect, please do point it out. I looked at the tool and it seems it only works on plan JS and Facebook's JS dialect (flowtype)
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.
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.
React 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.
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 . 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 .
[0] https://www.youtube.com/watch?v=ZCuYPiUIONs
[1] https://github.com/markerikson/react-redux-links/blob/master...
[2] https://github.com/facebook/react/issues/8854
[3] https://github.com/facebook/react/issues/9207