React v15.0 Released

A number of changes in this look great.
I always found the extra <span> tags to be a bit frustrating.

Are we able to just run meteor npm install --save react react-dom to use this latest version?
I am not able to test this for a couple more hours - away from dev machine, keen to hear if its working with Meteor :slight_smile:

6 Likes

Yep! The primary reason we now recommend using React directly from NPM is that you can use any version you want, immediately after it comes out!

6 Likes

We are now using document.createElement instead of setting innerHTML when mounting components. This allows us to get rid of the data-reactid attribute on every node and make the DOM lighter. Using document.createElement is also faster in modern browsers and fixes a number of edge cases related to SVG elements and running multiple copies of React on the same page.

Rejoice! \o/ Never did like all these extra attributes littering my DOM :smile:

5 Likes

While this isn’t directly related to the release, we understand that in order to receive more community contributions like Michael’s, we need to communicate our goals and priorities more openly, and review pull requests more decisively. As a first step towards this, we started publishing React core team weekly meeting notes again.

That is nice.

2 Likes

I just tried to do the update and it won’t update beyond 0.14.8, I am guessing that is because of the dependencies listed in my package.json file. I think they are limiting the updates because its gone from 0.14 to 15.0…

I’m not super familiar with how this all works with NPM, should I manually update the json file to request 15.0?

1 Like

I don’t know what is the “right” way to do incompatible updates with npm either. I just updated package.json with:

    "react": "15.0.0",
    "react-dom": "15.0.0",

and then ran npm install --save react react-dom

That did the trick for me.

I’m getting errors running meteor with react 15:

W20160408-13:30:11.145(10)? (STDERR) WARNING: npm peer requirements not installed:
W20160408-13:30:11.145(10)? (STDERR)  - react@15.0.0 installed, react@0.14.x needed
W20160408-13:30:11.145(10)? (STDERR)  - react-addons-pure-render-mixin@15.0.0 installed, react-addons-pure-render-mixin@0.14.x needed
W20160408-13:30:11.145(10)? (STDERR)          
W20160408-13:30:11.146(10)? (STDERR) Read more about installing npm peer dependencies:
W20160408-13:30:11.146(10)? (STDERR)   http://guide.meteor.com/using-packages.html#peer-npm-dependencies
W20160408-13:30:11.146(10)? (STDERR)          

anyone else getting this?

3 Likes

Nice! When is MDG going to update the React package?


J.K. - 1.3 for the win! :smiley: :rocket:

5 Likes

Yep, I’m guessing react-meteor-data does not want to play nice with React v15.

I reported this.

1 Like

I am guessing if we move to use react komposer or something that doesn’t use mixins we are good?
I use the mixin currently but might just use this as an opp to migrate to the compose way of doing things.

No, it’s nothing to do with mixins I don’t think. Even if you’re using the new createContainer, it still bombs out.

2 Likes

We should look into this ASAP! @tmeasday

2 Likes

Thanks for that, I will hold off on updating then!
:slight_smile:

1 Like

When you say “bombs out”, do you just mean “displays this warning”? Because it does work with 15.0.0 AFAICT, but (sensibly IMO, when you consider things like mixins could have been deprecated / removed) only guarantees to work with 0.14.x, and thus warns you otherwise.

If there is an issue with it and React 15, please open an issue (and post it here too :wink: ).

I’ll release a new version of the react packages tomorrow that peer-depend on react-15.

Sorry, bad wording - not quite bombs out :slight_smile: Just strange behavior. Though, thinking about it again, that could really be any package that’s suddenly not compatible with React v15. That’s odd though… I don’t think there were any breaking changes in this version. And I wasn’t using any deprecated stuff.

I’ll see if I can hone in on the issue, and I’ll post my findings here.

Ok, things are fine! Whew. The only thing is a couple warnings which I don’t understand.

Warning: Input elements must be either controlled or uncontrolled (specify either the checked prop, or the defaultChecked prop, but not both). Decide between using a controlled or uncontrolled input element and remove one of these props. More info: https://fb.me/react-controlled-components

Warning: ToggleCheckBoxOutlineBlank: key is not a prop. Trying to access it will result in undefined being returned. If you need to access the same value within the child component, you should pass it as a different prop. (https://fb.me/react-special-props)

The problem is that Meteor 1.3 has just been dumping out errors pointing to modules.js?hash=xxxxx and so it’s extremely difficult to trace these.

People should also take note that react-tap-event-plugin is broken under React v15. Dan Abramov made a pull request but it hasn’t been published yet. I may just incorporate these changes locally for now.

Oh wait. We don’t need that plugin anymore! https://news.ycombinator.com/item?id=10389789

Note that you have to disable zooming for your web app to lose the tap delay. Which many people do for web apps anyway. Great news! Time to convert all my onTouchTaps to onClicks! :slight_smile:

2 Likes

I’ve updated to v15.0.0 and all seems well… Granted I get a warning in my console much like @mordrax, but it all works fine. :wink:

The only thing that royally complains is NPM for the react-mounter package by @arunoda, as they have changed to semantic versioning, it doesn’t like the new version very much at all. But it too, still works.

Just adding this in as there has been some confusion around this lately - the createContainer approach still uses mixins:

(but it’s designed so that if mixins are deprecated it can be easily adjusted.)

3 Likes

A small question here… Does createContainer passes the context?

I have been afraid to use this as I use context. Keeping the old way for some components…

For es6, i use:

constructor(props, context) {
  super(props, context);
}

But if createContainer blocks the context down the road, it’s not very useful.

Any thoughts?