

React v0.14 Beta 1 released - eminh
http://facebook.github.io/react/blog/2015/07/03/react-v0.14-beta-1.html

======
aleem
If you haven't already, you should be betting on React. It's the future:

> More importantly, this paves the way to writing components that can be
> shared between the web version of React and React Native. This isn't yet
> easily possible, but we intend to make this easy in a future version so you
> can share React code between your website and native apps.

Isn't this what we have all been waiting for? Writing components that are
composable, that are "isomorphic or universal", that can run on Native or DOM
without any downsides of it's predecessors.

Aside, the article also mentions a migration tool [1] to help you port your
code from 0.13 to 0.14. While others may have done so before, it's pretty cool
that this is streamlined as part of the beta release.

[1]: [https://www.npmjs.com/package/react-
codemod](https://www.npmjs.com/package/react-codemod)

~~~
tambourine_man
_It 's the future_

[http://blog.circleci.com/its-the-future/](http://blog.circleci.com/its-the-
future/)

~~~
KurtMueller
For CircleCi, it's the present. Their frontend is written in Om, a cljs
wrapper around React.

[https://github.com/circleci/frontend](https://github.com/circleci/frontend)

[https://www.youtube.com/watch?v=LNtQPSUi1iQ](https://www.youtube.com/watch?v=LNtQPSUi1iQ)

------
krat0sprakhar
I think this is the crux -

> _We think the true foundations of React are simply ideas of components and
> elements: being able to describe what you want to render in a declarative
> way. These are the pieces shared by all of these different packages (react-
> native, react-art, react-canvas, react-three). The parts of React specific
> to certain rendering targets aren 't usually what we think of when we think
> of React._

I've not played with React-native yet (waiting for Android) but I feel this is
a positive step towards their vision of "learn once, write anywhere". From the
twitter updates it seems, Sebestian Markbage, gave a pretty cool talk on the
same topic at ReactEurope yesterday. Can't wait to check that out.
[https://twitter.com/chantastic/status/616679794479112193](https://twitter.com/chantastic/status/616679794479112193)

> _To make this more clear and to make it easier to build more environments
> that React can render to, we 're splitting the main react package into two:
> react and react-dom._

Great to see the react team responding positively to the developments in
community and not being afraid to take hard decisions (like this one)

Lastly, if you're a web developer and deciding between going the 'web
components' route or the React route, this announcement gives you, IMHO, an
even more impetus to pick up React.

------
skrebbel
_we looked at what you can do with a ref to a DOM component and realized that
the only useful thing you can do with it is call
this.refs.giraffe.getDOMNode() to get the underlying DOM node. In this
release, this.refs.giraffe is the actual DOM node._

This only holds if you use Facebook's particular flavour of Flux, I guess.

Personally, I use refs a lot to bubble events _down_ the component hierarchy.
For example, when the browser window loses focus and gains it again, some sub
sub component of the root component might want to do set some local state.
Whatever, display a "welcome back!" message or something. I can use refs to do
this.refs.subcomponent.onWindowShow() and this makes my code very clean and
flexible - it keeps browser event stuff out of my flux stores, and only the
actual important user data in there.

Similarly, I use refs to ask an <Input> component whether its value is valid
according to some validation rule. I could also give the Input an
onValueValidityChanged prop, but that just increases the amount of bookkeeping
I need to do. If I'm rendering a form with 2 inputs, name and email, calling
"this.refs.name.isValid()" in some onButtonClick handler makes a lot of sense
to me.

I really liked how React was separated from particular architecture patterns,
but this change makes that a lot more difficult. I really hope this change can
still be reversed.

~~~
matthewmacleod
_Personally, I use refs a lot to bubble events down the component hierarchy.
For example, when the browser window loses focus and gains it again, some sub
sub component of the root component might want to do set some local state.
Whatever, display a "welcome back!" message or something_

Isn't that a bit of an antipattern? It seems that sending events down the
hierarchy is something that React goes out of its way to make awkward, and on
purpose.

In the case you've given, I'm not clear why you wouldn't just bind to the
window's focus and blur events from within componentWillMount, anyway.

~~~
skrebbel
I'm not sure that it is an antipattern. Personally, I feel that attaching
event handlers to global window events from all over the place is just as bad,
basically a singleton in disguise.

Another use case that I came across was where we wanted a search dropdown to
open in the header when a user clicked somewhere in the middle of the page
content. One option would be to make a PageStateStore and add an
isSearchDropdownVisible to it, but I don't like doing flux that way because I
don't want UI details to be part of my model later.

I think having isVisible in the SearchDropdown state is much more elegant, but
that poses the slight problem of how to change that state from the other side
of the page. We did that by having the item in the page have an onWantToSearch
event, which the page had a handler for that invoked
this.refs.header.showSearch(), which in turn invoked
this.refs.searchDropdown.setVisible(true), which did a simple
this.setState({isVisible: true}).

So, in general, the event first bubbles all up the tree (through custom react
onSomething, onSomethingElse props), and then bubbles down the tree (through
method calls on refs). This exposes a really elegant design, because it made
the Header component be "a thing that allows searching" (because it has a
showSearch() method), and the page item an "a thing that allows a user to
initiate a search action" (because it has a onWantToSearch event). The
available methods and onSomething props of all components perfectly matched
the possible behaviors of the components, and no behaviour is "hidden" inside
a singleton mesh of flux stores.

------
hartator
I am using/loving React a lot and is already in several production apps I am
working on (thanks for awesome work Facebook!) but I don't fully get this
release.

I feel it's a bit premature to separate `react` and `react-dom`. React has
proven itself for the web but still has to prove itself as `react-native` and
I don't get the friction/complexity being added by break it down into two
components for the web. I feel React is more the rendering engine `react-dom`
than the class/component system now `react`. What makes React beautiful is to
be able to freely mix html into JS and not being limited to the render() call,
so I feel the cut is a bit non-organic.

Finally, I love the approach `learn once, write anywhere` but having `react`
as a thing by itself points (or at least confuses) to a workflow where you can
write components by themselves then plug a rendering engine DOM or native, I
don't think that's the initial intent and I don't think that's the intent now
of this release as well but it's unnecessary confusing.

[Edit] Don't fully get why I've been downvoted.

~~~
grandalf
Chances are this clear separation will allow the various teams to submit
patches to React without having to worry about time synchronizing with the
release of the stuff that is in ReactDOM ... at least once it stabilizes a
bit.

------
danmaz74
We're considering trying react for a new project, and just read about the
adoption of Babel [1] instead of the internal transpiler previously used for
JSX. One question: does this mean that JSX will be able to use ES6 syntax
supported by Babel out of the box? If so, will this be the default for this
new version of React?

I ask the questions also because we would really like to be able to use React
with CoffeeScript, but, even if there are many solutions to do so, no one is
supported by Facebook and we're worried about future compatibility. Is
adopting Babel going to influence the ability to use React with CS?

[1]
[https://facebook.github.io/react/blog/2015/06/12/deprecating...](https://facebook.github.io/react/blog/2015/06/12/deprecating-
jstransform-and-react-tools.html)

~~~
spicyj
You don't need to use Babel, though we do recommend it. We're just no longer
going to maintain our own JSX transformer since there's no point. (If you want
just Babel's JSX transformation without any other features, that's possible
too.)

There's a CoffeeScript JSX transformer here if you're interested:

[https://github.com/jsdf/coffee-react](https://github.com/jsdf/coffee-react)

and we'll continue to support using React without JSX, and though we use Babel
now internally, we compile React itself to ES5 before putting it on npm so you
don't need to use Babel if you don't want to.

~~~
danmaz74
Thanks for the answer. It would be great to have an officially sanctioned
toolchain for using coffee and react from Rails, but I think that asking too
much :)

------
joesb
Aren't these two changes in conflict with each other?

One change remove assumption about DOM as rendered target, while another
change means DOM must be the rendered target.

Requiring ReacDOM.findDOMNode(ref) should be what they do if they want to
encourage multiple rendering target.

~~~
spicyj
If you use a ref to a DOM component, you don't need ReactDOM.findDOMNode at
all. Calling findDOMNode on a composite drills through abstraction boundaries
and breaks encapsulation, so it's rarely what you should do.

The removal of .getDOMNode() was intentionally done in concert with this
change: previously, all component classes created with React would magically
have that DOM-specific method added to them; this way, component classes are
less tied to specific rendering environments. If you need to call
ReactDOM.findDOMNode then yes, your components will be tied to the ReactDOM
renderer.

------
smhg
tl;dr React (core) is evolving into a kind of component spec.

Sounds good!

If not already, react-dom will probably be easily replaceable by modules like
virtual-dom?

------
ericclemmons
I'm extremely excited about this release because of the change to context from
Owner-based to Parent-based.

Authoring react-resolver meant jumping through weird hoops to avoid context
changing, but this release should mean things will work as expected, rather
than having to sort out "gotchas".

There goes my July 4th weekend :)

~~~
insin
I'm looking forward to the context change the most too, it makes the feature
work the way I've intuitively thought it would/should work when trying to
design for it in the past.

It's going to be a boon for libraries which use DSL-like ancestor components.

------
d0m
About the refs, I've been using a small helper:

    
    
        h.ref(this, 'some-element.children-element');
    

and its companion h.$ref(this, 'some-element.children..'); for the jquery
version.

I don't have a strict rule of when using it, but sometimes it's cleaner than
having lots of nested callback on an inner children.. I.e. I can just do:

    
    
        h.$ref(this, 'header.search.input')..
    

Which basically transforms to this.refs.header.refs.search.refs.input (IIRC)

~~~
spicyj
I wouldn't encourage doing that because it breaks encapsulation of your
children. Like state, you shouldn't peer into another component's refs.

But that should continue to work fine.

~~~
d0m
I think it's fine when the parent and children are really tied together. I
wouldn't use that from the main component to a really nested children for
instance.

Let's say you have a "SearchComponent" with a "SearchButtonComponent" and
"SearchInputComponent", I'm okay with using the strategy I suggested because
using "SearchInputComponent" without its parent somewhere else in the code
would be too risky so the encapsulation is still kept between parent/children.

------
andy_ppp
I am using React and am very happy with it, however I worry about upgrading
because of the interdependencies as well as how fast everything is moving in
this space... Does anyone know when we'll be able to have a 1.0 release that
we can assume stable for a few months and that react-xxx authors can make sure
their modules are stable against.

Presumably the react/react-dom breaks all current third party packages for
now?

~~~
spicyj
These changes require a little work on your part with each release, but we
think they make React better overall – the alternative would be to stop
improving React, which I think is worse. We're already trying to get to a
long-lived release as fast as we can, especially given our commitment to
support each change with a warning for an entire release to give people a
chance to update their code.

One of our goals with this release is actually to help with the problem you
mention of interdependencies and component versioning: we expect most
components to only depend on the "react" package, which will be more stable
and updated less frequently.

Thankfully the React community moves fast and package authors are usually
quick to update to new React versions.

P.S. We've been making releases every 6 months or so, so we're already at
"stable for a few months". We might speed this up a little but we never want
the pace to be unmanageable. (The four of us on the core team need to make
sure the 10,000 components in the Facebook codebase continue to work, so I
assure you we don't take breaking changes lightly.)

~~~
andy_ppp
Fantastic, that's reassuring to know. Given this I'll bite the bullet and move
to 0.14 beta seeing as my app isn't publically available yet.

Thanks so much for React - it really is an amazing way to work and moving to
it has simplified the extremely complex and interactive app I'm building!

------
aaronjgreenberg
It'll be cool to see a WebAssembly implementation of react-dom.

