
React v0.14 - spicyj
http://facebook.github.io/react/blog/2015/10/07/react-v0.14.html
======
clessg
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 contributor to Redux and creator of Flummox) just released
Recompose which provides powerful capabilities for stateless components:
[https://github.com/acdlite/recompose](https://github.com/acdlite/recompose).

Some of the benefits of stateless function components as outlined in
Recompose's readme:

* They prevent abuse of the setState() API, favoring props instead.

* They're simpler, and therefore less error-prone.

* They encourage the smart vs. dumb component pattern.

* They encourage code that is more reusable and modular.

* They discourage giant, complicated components that do too many things.

* In the future, they will allow React to make performance optimizations by avoiding unnecessary checks and memory allocations.

~~~
devit
The idea of giving special consideration to "stateless" UI components in this
sense seems ill-conceived, because adding or removing UI-related state should
not have any extra implications.

For example, if you display photos in a table, there is no state, but if you
display photos with a carousel, then you have state as the current page, but
these two components should otherwise have the same interface and
implementation. Also in general the current selection and scroll position is
state, albeit stored in the browser, so any UI component can potentially have
state, even if it is only stored implicitly in the DOM objects.

What really matters is whether the component holds any state with "semantic"
meaning or that needs to be persisted (like a date the user selected in a date
picker) or whether all the state is "presentational" (like the month a date
picker is showing).

What you should do in React is not hold any "semantic" state in components,
unless it's a component that is solely designed for holding and managing such
state (e.g. Relay container components, or a root App component).

EDIT: slightly reworded to be clearer and more correct, since having the same
API interface regardless of statefulness is implicit in React

~~~
lobster_johnson
You embed stateless (function-based) components just like you do for normal
components. There is no interface difference; the caller doesn't need to know
whether the component it is using is stateless or not.

------
Touche
> 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 stable API on which users have come to depend, you
> should be 1.0.0. If you're worrying a lot about backwards compatibility, you
> should probably already be 1.0.0.

~~~
eric-hu
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?

~~~
masterj
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.

~~~
Touche
> Why do you care about an imaginary number?

It's not imaginary, it represents stability. By not going 1.0 you are saying
it is alpha software and should not be used.

Not everyone has Facebook's budget or resources to upgrade every 2 months.

~~~
danabramov
React upgrade path is stabler and smoother than 90% of >1.0 libraries I have
seen. Please don't jump to conclusions. ;-)

~~~
quarterto
It's about the perception that the number provides.

~~~
danabramov
Fixing this is on the roadmap:
[https://gist.github.com/zpao/6e12ee0f46ce87af2287#versioning](https://gist.github.com/zpao/6e12ee0f46ce87af2287#versioning)

------
losvedir
The enthusiasm around React is infectious and I'm thinking about integrating
it into one of my projects but I can't quite tell what exactly it's supposed
to be used for. Is it only for SPAs or is it reasonable to consider react when
you just want to add some interactions and dynamism to a page that was
rendered server side?

React seems kind of like an all-or-nothing approach. It seems like overkill if
you just want to provide a little more structure to jQuery spaghetti code.

Can React be a competitor to, say, Knockout? React seems more in the realm of
angular or ember to me.

~~~
tootie
React is really 2 things. One is an implementation of web components which
makes it a competitor to Polymer and is is useful on almost any project.
Secondly, React is an implementation of the Flux architecture (one-way data
binding) which is most useful for SPAs, but doesn't disrupt a static site as
much as Angular does.

~~~
robertfw
React is not an implementation of the Flux architecture. Flux is an
architecture that works well with react.

I would argue that the primary contribution from React is not the web
component aspect but the declarative, immutable-friendly approach to UI
rendering

------
drinchev
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,
this is awesome! ( I did it with server-side rendering, so I didn't loose
anything at all )

~~~
s3nnyy
Can you please elaborate on 3.?

~~~
Callmenorm
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.

~~~
drinchev
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.

------
desuvader
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!

~~~
thebigkick
Would you mind explaining? As a jQuery believer, to me this looks like a
selector method - getElementByID or something. I'm guessing this is against
the whole idea of React.

~~~
desuvader
Refs are simply references to DOM nodes that you have to specify through the
ref (HTML) attribute. You can give a DOM node the ref value "foo" and then
later reference it in a react component with this.refs.foo (previously
this.refs.foo.getDOMNode()).

------
omouse
I'm glad they separated out react from the DOM. This makes it much more likely
that people will export the ideas _and the API_ of React to other languages.
The API is sane for data-flow programming and the lifecycle is well-defined.
The separation of properties from state can be useful in other contexts.

------
gh0sts
Great news. I just upgraded our app to 0.14-rc1 last week and particularly
enjoy "refs" being direct references to the DOM nodes. Can't wait to move some
of our stateless components to functional.

------
aaronkrolik
I'm fairly new to react, and have wondered if I was using it correctly (as
intended). Almost always I have a root component that manages state, passing
it to children via props. All changes to state go through that root component,
either by callback (also passed as prop) or some external event.

Is this update in a sense validation of that approach?

~~~
epmatsw
What you've described is pretty similar to Flux or one of its variants. The
main difference would be that instead of managing state inside of the root
component via setState, you have an external state ("store"), which would
handle the state logic and provide the appropriate values as props to the root
component. So yes, it sounds like you're doing it "right".

------
oblio
Is there some sort of React component repository or something?

~~~
clessg
[http://react.parts/web](http://react.parts/web) and [http://react-
components.com/](http://react-components.com/)

~~~
hliyan
Thank you so much for this! [http://react.parts/web](http://react.parts/web)
is very useful (particularly that it shows stars and download counts next to
each component entry).

------
zkhalique
I have a question, why is dirty-checking so great?

Whether it's Angular doing dirty-checking in the $digest cycle or React
walking the virtual DOM and doing dirty-checking?

Why not just subscribe to events and update things when the model changes?
That would seem to be far more efficient, and also make clear the mapping of
dependencies of views on data.

~~~
draw_down
React does not do dirty checking.

~~~
pkozlowski_os
Well, it kind of does when comparing virtual DOMs before and after changes.

~~~
danabramov
Usually people say “dirty checking” when they mean “keep checking in some kind
of event loop whether external entity modified some object, and if so, do
something”.

In React there's no such event loop where it checks virtual DOM—React _knows_
if it needs to _compare_ virtual DOM trees (not arbitrarily check models for
changes, for example) because all changes are explicit and happen either due
to `setState()`, `forceUpdate()` or `React.render()` top-level call.

So React doesn't do dirty checking in the sense Angular does, unless by dirty
checking you mean all kinds of comparisons.

~~~
pkozlowski_os
Right. I guess it really depends how people define "dirty checking". What I
was trying to say is that at the end of the day you do diffing on some data
structure: model in Angular and virtual Dom in React.

Loop vs. one pass is an important distinction, agreed. But when we bring
Angular we should be noted that Angular 2 doesn't do those checks in a loop
but does comparisons in one pass only.

~~~
tracker1
My biggest complaints about angular aren't really the dirty checking system
that it uses (though one of them is a side effect).

My biggest complaint is the weird dependency injection system that makes it
difficult to track down where something comes from. It's better in 2, but
still not as straight forward as React, where your child components are simply
import/require statements that you can follow through to either an installed
npm module, or a relative path. I try to avoid DI in JS wherever possible,
it's almost never needed, and there are almost always simpler ways.

My second largest complaint on angular, is that I find that the way it handles
state (though many are moving to a more react-like approach) leads to anything
outside of the "angular way" being _very_ complicated to work around. The fact
that $scope.apply() is a thing kind of sums it up pretty nicely.

For most applications (we're not all building facebook level interactions),
either comparison approach is not a performance issue in practice. What I do
find is the flux/react way tends to have a bit more cognitive overhead to get
started with, but additional features add less additional complexity than with
angular.

~~~
Bahamut
A bit offtopic, but DI (via IoC container) is for managing runtime
dependencies, which can get complex as an app grows. DI of the IoC container
flavor is never necessary (I would argue that pure DI in itself is only a good
thing though for clean separation of code), but one can say many things are
not necessary - its existence is for making things simpler when working with
complex apps. Without an IoC container, one has to manually pass around
services to those requiring them if there is some complex runtime code - it
sucks greatly when working with increasingly complex code, far more than using
a system with an injector to manage the runtime constructs and to act as a
fetcher that retrieves the necessary instance when requested. An example of
the convoluted nature of handling dependencies without such a system is when
one needs to test one service that say depends on another service that is x
services removed in a dependency chain. In order to properly mock for testing,
one has to potentially dig x levels deep to mock all relevant methods, instead
of mocking the one service of interest.

It should also be noted that imports are orthogonal to the utility of DI. ES
imports does not address the runtime dependency tree, and can certainly live
alongside a tool such as DI - DI is for handling runtime dependency
management, importing/exporting is more for handling initialization/compile
time dependency management. Confusing the two is not understanding the
problems they are meant to solve.

Angular 1's DI, while extremely convenient for testing, unfortunately does
rely on a hacky implementation. Angular 2's DI system is extremely robust
though, using the proposed ES7 decorator standard to more properly implement
DI via IoC by using the services themselves (which are imported in) to fetch
the appropriate instance - Angular 2's component system also makes it
extremely easy to consume the injector with one line, or even creating new
injectors to silo sectors of an application into runtime modules.

Angular 2 also espouses many of the ideas that React has pioneered in frontend
web development - in fact, the Angular team would be quick to admit the faults
present in Angular 1, which didn't have the benefit of the current state of
HTML & JavaScript in the late '00s when it was conceived (ES module standard,
annotations/decorators being a potential language feature, strong browser
standards support across the major 4 browser vendors, etc.). Flux-like
patterns can be easily implemented in Angular 2, and may see a surge in
popularity given its popularity in the React ecosystem. Uni-directional data
flow is at the core of Angular 2's component system.

~~~
tracker1
What does one have to pass around? You can `require`/`import` service modules
directly... for that matter, with a system like redux/react, you can easily
pass anything needed via properties. You can create pretty complex
applications without muddying where your services come from...

I've been following Angular2, and while much better than Angular1, still think
react+redux as a workflow/render solution with separate state management
reducers/handlers is a better workflow... especially as feature count goes up,
because complexity doesn't climb as steeply as with Angular.

------
crudbug
Are there any good component libraries for React ?

JSF ecosystem is a good example of component based web UIs.

------
kraig911
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.

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

~~~
danabramov
If you didn't see warnings running code under 0.13, nothing should break per
se, right? And if you see warnings now, that's the stuff that will break in
0.15 but works for now.

~~~
spicyj
Yes, with the exception of the React.initializeTouchEvents() removal and the
ReactTestUtils change I noted.

------
suchitpuri
Well i think it will take some time for libraries and components to be
updated. For me currently at least react router should provide a compatible
build with react 0.14

