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...
Just wanted to express my admiration for her work and gratitude for making this information public, available, and free.
... 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.
But I suck, this talk was great, she's a really good speaker, thanks for weirdly convincing me to watch this
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.
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).
<template>
<div>
<h2>{{ title }}</2>
</div>
<template>
<script>
export default {
data() {
return {
title: "Hello world"
}
}
}
</script>
export default ({title}) => (
<div>
<h2>{title}</h2>
</div>
)
Also wish someone would explain the draw of ES6 classes. React is about composition, not inheritance. Have never seen a `React.Component` extended.
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.
[0]: https://facebook.github.io/react/docs/composition-vs-inherit...
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.
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.
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.
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?
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.
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.
IE11, older FF and Chrome, and especially older mobile devices with older Webkit based browser (Android and iOS)
Messy.
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.
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.
Maybe you could explain how this is the same thing?
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.
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.
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
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.
* 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.
(Unfortunately it's not working with React Native, but I hope that's fixed soon: https://github.com/brigand/babel-plugin-flow-react-proptypes...)
EDIT: Thanks to namuol, I just discovered flow-runtime: https://codemix.github.io/flow-runtime
This looks amazing!
EDIT 2: flow-runtime also doesn't work with React Native: https://github.com/codemix/flow-runtime/issues/17
That's a shame. I might see if I can fix it, otherwise I'll just stick with compile-time checks for now.
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.
class MyComponent extends React.Component {
state: Object;
constructor(props) {
super(props);
this.state = {
foo: 1, // no type error
};
};
}
Anyone have experience with this sort of thing?
Is create-react-class smart enough to determine whether the version of React it is augmenting already implements createClass to prevent bundle size bloat?
class HelloWorld extends React.Component {
}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.
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.
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 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.
class Foo extends Component {
bar = () => {
// ...
}
}constructor(props) { super(props); this.func = this.func.bind(this); }
Is better if you care about performance.
Mixins don't compose safely and were always kind of a hack.
HOCs are also kind of a hack, but at least they behave predictably (i.e. they do compose).
I don't really get the argument that React lacks testing infra. I know a lot of people say this but no one has talked me through an example yet.
It's sad to see how new generation can't learn lessons of the past.
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.
```
interface State {}
interface ISomeComponentProps {
title: string;
tooltip?: string
....
@ReduxConnected
export class SomeComponent extends React.Component<ISomeComponentProps, State> {
....
```
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.
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?
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.
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.
I think that changed recently in Chrome, at least.
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?
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.
npm install react@next react-dom@next --save
Unlike real web components, React components are brittle since React does not have the equivalent of Shadow DOM.
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.
https://facebook.github.io/react/docs/web-components.html
There's also more opinionated integrations like https://www.npmjs.com/package/skatejs-react-integration.
And of course you can do it the other way around too.
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.
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.
function App(params) { const component = new React.Component(params);
component.lifeCycleMethod = function() {...};
component.render = function() {...};
function privateMethod() {...}
return component;
}http://javascript.crockford.com/private.html
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.]
I'm pretty sure Crockford still pushes this. 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.
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.
Classes simplify things IMO.
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.
Edit: Here's Simpson's take: https://github.com/getify/You-Dont-Know-JS/blob/master/this%...
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.
http://justinfagnani.com/2015/12/21/real-mixins-with-javascr...
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).
The 15.5 announcement does thank several people for "transferring ownership of package names", so I'm guessing that may be one of 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.
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.
If you want people to always ignore warnings, this is how you go about it.
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.
Not interested in either? Then don't upgrade.
[1] - fixes enumerated here: https://facebook.github.io/react/blog/2017/04/07/react-v15.5...
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.