Enter Your Email Address to Watch This Lesson

Your link to unlock this lesson will be sent to this email address.

Unlock this lesson and all 827 of the free egghead.io lessons, plus get React content delivered directly to your inbox!



Existing egghead members will not see this. Sign in.

Just one more step!

Check your inbox for an email from us and click link to unlock your lesson.



What's new and different in React v0.12.0

3:42 React lesson by

React has changed a bit in version 0.12.0. Let's take a look at what is different. You may need to update some code!

Get the Code Now
click to level up

egghead.io comment guidelines

Avatar
egghead.io

React has changed a bit in version 0.12.0. Let's take a look at what is different. You may need to update some code!

Avatar
Alan

Any particular reason to use React.createFactory over React.createElement?

Avatar
Joseph

Great question!

createFactory is really just a shortcut to createElement. In this simple example they are pretty interchangeable.

React.render( React.createFactory( APP )( { prop: 'red' } ), document.body );
React.render( React.createElement( APP, { prop: 'red' } ), document.body );

There seems to be a lot of discussion regarding these two and how they might be further prescribed in v0.13 so for this lesson I chose to go with the method recommended by the library itself:

"... is calling a React component directly. Use a factory or JSX instead"

In reply to Alan
Avatar
Alan

Interesting. Currently JSX uses React.createElement, so that's what I've been using when writing plain JS. I'm not sure what benefit React.createFactory is supposed to provide over using React.createElement directly (assuming one is already using a partial application / currying library for situations where one wouldn't want to pass the raw component around directly).

I guess it's at least partially for creating an easier upgrade path for legacy code (so you only have to modify the import, not every single use).

In reply to Joseph
Avatar
SalesMaster

If the element on which you use jsx spread attributes {...this.props} (instead of the old TransferPropsTo method) has other properties, they override those in this.props. Is there an easy way to make it merge properties together as the old method did?

Avatar
Alan

SalesMaster, I'm assuming you want to supply fallbacks instead of overrides? In that case, you can just use the spread syntax to extract the properties you want to provide defaults for like this:

var {arg1, arg2, ...props} = this.props;

return <div {...props} prop1={arg1 || 'default1'} prop2={arg2 || 'default2'}/>

Alternatively, you could just use getDefaultProps to define the default values of those properties.

EDIT: Sorry about the formatting. The Markdown parser is a bit retarded and doesn't handle code formatting well (neither github-style fencing nor indenting worked, so I had to use inline backticks).

In reply to SalesMaster
Avatar
Joel

Also note--if it hasn't been mentioned elsewhere--you must use capitalized var names when creating classes or you'll get a "erroneousLine..." error. At least this was the case when I attempted to use the mixins video code with the latest version of react/JSXTransformer.

Hey, guys. In this video, we are going to take a look at some of the changes in React version 0.12. Here, on the page, we've got a really simple application. It's not doing much.

First, we're rendering this component APP, which in turn renders this Title component, passes in a className of red. In that Title component, we're taking that className. We're using this.transferPropsTo in order to pass that into this h1.

Let's go ahead and load that up in the browser. Everything seems to be working just fine, but we're getting these weird messages. We're getting the one about the JSX in-browser transformer. That's fine, but here, we've got "React.renderComponent will be deprecated in a future version. Use React.render instead."

Let's go ahead and implement that. Get rid of component there. Everything's looking good, but now we've got "transferPropsTo is deprecated." Without going to the website, we're going to work around that. We're going to get rid of transferPropsTo.

Right here, what we're going to use is the JSX spread operator. It works just like this. this.props. JSX spread operator works just like the ES6 spread operator. We're just passing in all those values. It's going to get broken out into an array. Yada, yada, yada. It's going to work. Load that up, and everything's looking good.

One other thing. We're not getting a message about this, but we don't need the JSX pragma anymore. We load that up. Everything's working just fine without that JSX pragma.

Let's take a look at some of the changes that we're going to apply to using React.DOM without the JSX transformer. We'll load that up, and everything's working fine. Everything, at this point, is backwards compatible. Skipping around here, we can see React.renderComponent is going to be deprecated, so let's get rid of that. Load this up.

Now it says, "Something is calling a React component directly. Use a factory or JSX instead." We're not going to use JSX here. Therefore, we have to use a factory. The way we do that is React.createFactory. We wrap our component in that. That's going to return our component function.

Actually, I shouldn't be calling them "components." Everything in React used to be a component. Now it's called an "element." There you go. Let's load that up really quick.

Right now, before we load it up, we've got one, two messages about calling a React component directly. Let's load that up. Now we've only got one. It's saying that "APP is calling a React component directly." That's going to be right here.

Do it just like that. We're still going to pass in our props right there. Let's load this up. Now we're back to "transferPropsTo is deprecated." In straight React.DOM, we don't really have access to the spread operator the way that we might want to, unless we were transpiling from ES6 to ES5.

The only way we can really deal with this...There actually is a way to deal with it with Object.assign, but at this very moment, Object.assign is not very well-supported. The way we're going to do it is just say, "this.props.id="message"."

Here, we're just going to pass in this.props. Load that up, and everything is working fine. We have no error or warning messages. There you go. That's a quick look at React version 0.12.



HEY, QUICK QUESTION!
Joel's Head
Why are we asking?