Live data from Hacker News

React v0.14

facebook.github.io

41–50 of 116 posts

Re: React v0.14

#41
post #38

React is cool. Switching to React helped me do : 1. Get rid of any jquery-like library. 2. Get rid of my HTML/Handlebars files :) 3. Generate dynamic CSS classNames for my components allowed me to get rid of stylesheets naming conventions / strategies ( BEM, etc. ) 4. With the help of Flux ( yahoo's implementation ) I got rid of writing two code-bases ( front-end / back-end ). Now I'm putting everything in one place,…

Can you please elaborate on 3.?

I think he's talking about css modules. Postcss or something like that. Webpack can generate unique names for you when you use that loader. I think it's more about webpack for #3 than react.

Re: React v0.14

#42

Earlier quoted context omitted.

Is it a semver project? Doesn't seem like one, the whole idea is to raise major version when you break compatibility.

Only after a 1.0 release. 0.x implies that breaking changes are always possible My experience has been that the React team provides plenty of advance warning with deprecation notices, similar to the experience of others I've never really been caught out by anything The worst case I've dealt with is bringing an app from .12 to .13 after not touching the code for five or six months. It only took me a few hours to bring…

> Only after a 1.0 release. 0.x implies that breaking changes are always possible

Yes, which is why so many projects never reach 1.0. There are basically 2 types:

1. Those who don't want to have to care about compatibility at all. 2. Those who care about compatibility a little bit but don't want a large version number.

React seems to fall into #2 here. They want a small version number and the perception of stability. But in reality there have been 14 breaking changes, this is version 14 software.

It's easier to convince someone to upgrade from 0.13 to 0.14 than it is 1.0 to 2.0 even though breaking changes are just as likely in the former. But the latter has a graver perception.

Re: React v0.14

#43

Wohoo! .getDOMNode() is finally gone! Edit: Haha, I just noticed that someone else was also happy about this. Also, now that classnames is standalone module, I recommend that people start using a standalone implementation of keyMirror (for flux) as well!

.getDAMNNode

Re: React v0.14

#44
post #38

React is cool. Switching to React helped me do : 1. Get rid of any jquery-like library. 2. Get rid of my HTML/Handlebars files :) 3. Generate dynamic CSS classNames for my components allowed me to get rid of stylesheets naming conventions / strategies ( BEM, etc. ) 4. With the help of Flux ( yahoo's implementation ) I got rid of writing two code-bases ( front-end / back-end ). Now I'm putting everything in one place,…

Can you please elaborate on 3.?

Yes.

Since your HTML is all Javascript now, there are people that went a bit further and created libraries for modularising your CSS files, based on that components [1][2].

The basic idea is that, since you are using ReactJS and you are compiling your JSX files to normal JS files, for which you are using a tool like "browserify" or "webpack". These tools are so powerful that can capture your `require` statements and convert your "non-javascript" required modules to something that javascript can use.

In a similar way I'm using webpack & css-loader. My JSX file looks like this :

    // Component.jsx

    var styles = require('./Component.css'); // Component.css is a normal css file that has a .component class inside

    class Component extends React.Component {
       render() { return (  ) }
    }
Now your webpack / browserify tools captures those require files, parses their class names and outputs a concatenated "stylesheets.css" file that has all the class names with a hash prefix. And the final Html/Css look like this :

    
with stylesheets file

    ._12az2X { color: red; }    
[1] https://github.com/css-modules/css-modules [2] https://github.com/webpack/css-loader

Re: React v0.14

#45
post #38

Earlier quoted context omitted.

Can you please elaborate on 3.?

I think he's talking about css modules. Postcss or something like that. Webpack can generate unique names for you when you use that loader. I think it's more about webpack for #3 than react.

Yes it is. But those tools usually rely on your Javascriptified HTML, which is something that React does.

So React is a prerequsite on that.

Re: React v0.14

#46
post #40
post #3

A lot of great ideas in this release and it makes me excited for the future of React. I've been on 0.14-rc1 and my favorite feature so far is stateless function components. So much cleaner than class-based components. One downside is that hot reloading doesn't work with it yet (AFAIK). Hopefully that will come soon now that 0.14 is officially released. (And I believe Dan is/was on vacation.) Andrew Clark (core contri…

What exactly is different? I've been using "stateless function components" with react 0.12 and 0.13. Just write a function that returns a ReactElement, eg: function renderFoo(props) { return {props.foo} ; } Then use it elsewhere in your code like a normal function: function bar(props) { return {props.foos.map(renderFoo)} ; }

Looks like they've just added first-class support for that pattern, so you get propTypes, defaultProps, etc.

Re: React v0.14

#47
Anyone find a list that says what is broken by this update? I couldn't find an easy to parse list of functions/methods/etc that have changed ||&& are broken.

Re: React v0.14

#48

Earlier quoted context omitted.

Is it a semver project? Doesn't seem like one, the whole idea is to raise major version when you break compatibility.

Only after a 1.0 release. 0.x implies that breaking changes are always possible My experience has been that the React team provides plenty of advance warning with deprecation notices, similar to the experience of others I've never really been caught out by anything The worst case I've dealt with is bringing an app from .12 to .13 after not touching the code for five or six months. It only took me a few hours to bring…

> Only after a 1.0 release. 0.x implies that breaking changes are always possible

Oh, I didn't know that, it's unfortunate. IMO, just bump major version every time compat breaks. Otherwise projects end up mincing around forever trying to decide when the shiny 1.0 ribbon can be affixed.

Re: React v0.14

#49
post #17
post #9

> Like always, we have a few breaking changes in this release. We know changes can be painful (the Facebook codebase has over 15,000 React components), so we always try to make changes gradually in order to minimize the pain. Since React is a semver project, from the website: > How do I know when to release 1.0.0? > If your software is being used in production, it should probably already be 1.0.0. If you have a stabl…

I came in here to comment on this. React sounds exciting from what I've read about it, but I didn't realize it was pre-1.0. To teams who are using it in production, did you talk about this? What are arguments for using it despite it not being 1.0?

Why do you care about an imaginary number? FB (and many other large companies) heavily use this in production, and have to migrate their own apps. FB even goes farther and uses the master branch (well, synced every week or so). That's a far heavier endorsement than whatever side of a decimal a number falls on.

Re: React v0.14

#50

Anyone find a list that says what is broken by this update? I couldn't find an easy to parse list of functions/methods/etc that have changed ||&& are broken.

Were my "Upgrade Guide" and "Breaking Changes" sections not clear? I tried to make it as clear as possible but you still seem confused…
Post reply on HN