- Add missing object-assign dependency
- Add batchedUpdates to ReactDOMClient, rename the two addons to `unstable_`
- Delete react/addons/* (leaving react/addons with a slightly updated warning)
- Add README.md, LICENSE, PATENTS to each addons package
Changes:
- moves after_script to script
- adds `set -e`
- creates a seperate matrix 'build'
Way at the bottom of the travis output:
```
1571: curl: (26) couldn't open file "build/react.tgz"
```
This seems to be broken since 12c9fee94e
No reason to limit at 100. I can't imagine a reasonable tree with depth over 10,000 but that should still be small enough to "catch infinite loops" quickly.
This hack allow us to get rid of the stateful module ReactLifeCycle since
we can infer the value of isMounted even without it. This gets rid of
the try/catch which is deopting all mountComponent calls.
As a next step we could deprecate isMounted completely and avoid stateful
APIs. Since it can be easily simulated if you truly need it.
Since I fixed the server-side rendering it is now possible to trigger these
callbacks on the client alone. They will still be queued up on the server
but they are never executed.
This allows updates to be enqueued during render. setState in
componentWillMount will still be collected as part of the first pass so
if nothing else get added as pending, they won't trigger a second rerender.
This allow us to get rid of one more stateful special case.
This simply ignores any enqueued actions. This means that we don't have to have special logic for componentWillMount. It is just that those updates are never enqueued.
This was used for any invariant that was subsequently removed. It turns
out that this is completely unnecessary now. Any setState calls will
enqueue and update and the component added to the update queue. However,
since the pending fields are reset after componentWillUnmount, any update
will still be ignored.
It was impossible to get here because if you enqueue something
Also ensure that they're only used in DEV because we will be reading
state that is DEV only here.
This should only be used for tracking string refs. For that purpose, we
need a single central stateful module that is coupled to createElement.
Which is why it needs to live in isomorphic.
Eventually this will go away completely.
This decouples the stateful imperative API from the class creation.
Instead, they get injected into the class from the renderer. Stateful
modules should always be injected.
As a convenience, just like props/context/refs, we set it up after
construction using mutation. That way it is optional to pass it along
the super call constructor chain.
We won't be able to support this after DOM-components-as-refs but we don't expect many people to be passing DOM components to this function anyway, and it should be fairly straightforward for people to clean up failing unit tests using this function.
(This module also isn't public API and never has been.)
We won't be able to support this after DOM-components-as-refs but we don't expect many people to be passing DOM components to this function anyway, and it should be fairly straightforward for people to clean up failing unit tests using this function.
Squashed commit:
[4564e55] Ensures we don't need to update this page for every release.
[b0d60f9] update script sources to be even with the example file in reactjs/react-tutorial repo
This is kind of a confusing place for it but it is intimitely tied to the
update life cycle which is what the update queue is about.
This kills some dependencies from isomorphic to the renderer.
We keep track of the fact that something is rendering for a bunch of
warnings. (ReactCurrentOwner.current !== null)
Once we get rid of owner for string refs, I'll convert those to something
like "isRendering" instead. The interesting part is that feature `__DEV__`
only. It is only used for warnings. Except for this case.
This means that we can get rid of the special case for the isRendering
stack on in prod.
- babel-eslint ^3.1.14 fixesbabel/babel-eslint#120
- babel updated from ^5.3.3 to ^3.5.5, which changes stuff, I guess
- eslint updated from ^0.21.2 to ^0.22.1, which makes `no-shadow` also
check class declarations
In xml node name casing is exactly the same as the node was originally named.
Make sure to convert node and tag names to lower case before making any node
and tag name checks.
Fixes#3960.
spicyj noticed newer versions of babel-eslint seemed not to error on
no-unused-vars, and I was able to repro. It seems like something broke
between 3.1.9 and 3.1.10. (Smaller repro case and babel-eslint bug
report to come)
His commit failed on travis, but not on his local machine:
https://travis-ci.org/facebook/react/jobs/65468729
> The two callers of this function have different warning configs
> internally (static_upstream/core/createWarning.js) so we can't sync it
> like this without changing behavior. We should just split this out
> into two separate warning calls probably – this code is a little
> overabstracted.
https://github.com/facebook/react/pull/4021#discussion_r31690020
@spicyj
I think completely removing warnAndMonitorForKeyUse is a bit difficult, without
duplicating a ton of code. This at least ensures that the format string passed
to `warning` is unique. Plus, because the FB internal code in question only
matches the beginning of the format string, I think there should be zero
internal changes that need to be made to support this refactor.
The `warning` implementation checked that the message is long enough to
be useful. See commit f5038829d for more information.
It makes more sense to move this into a lint rule, and also to apply it
for both `warning` and `invariant`. We can safely remove stuff from the
`warning` implementation as we replace the function internally anyways.
https://github.com/facebook/react/pull/4021#issuecomment-108694976
@spicyj
The wording for an incorrect number of arguments based on counting %s
substitutions. The previous wording was backwards and a bit yoda-like
leading to possible ambiguity.
This should contain all the rules we probably want to use, except
react/wrap-multilines, which requires a larger codemod, and would
clutter this commit.
See #2869
Checks that the *second* argument of warning and invariant are a literal
string, or a concatination of literal strings, and that the number of
arguments is correct based on the number of %s substrings.
This commit also fixes a few places where the existing code had broken
error messages!
The rule itself is pretty straightforward, although adding the tests
ended up being a bit painful, as eslint-tester depends on mocha, and
therefore needs to be run in a separate grunt task.
This is a machine-generated codemod, but it's pretty safe since it was
generated by hooking into eslint's own report.
A few files had to be touched up by hand because there were existing
formatting issues with nested arrays/objects:
src/shared/utils/__tests__/OrderedMap-test.js
src/shared/utils/__tests__/Transaction-test.js
src/shared/utils/__tests__/traverseAllChildren-test.js
src/isomorphic/children/__tests__/ReactChildren-test.js
Introducing: a really lame version of composite components, right inside of ReactDOMComponent!
Now ReactDOMInput isn't an actual component. This brings us closer to exposing DOM nodes as refs.
Closes#3971.
> After #3968, the next thing we should do is start linting our tests.
> Historically we've ignored them due to lack of parser compatibility.
> But that shouldn't be a problem anymore. We may want to integrate
> https://www.npmjs.com/package/eslint-plugin-react to more aggressively
> lint our JSX in tests.
I understand this diff touches a lot of stuff, so I tried to keep it to
a near-minimal set of changes to make eslint happy.
- Removes esprima-fb dependency
- Tightens up eslintrc with some minor rules we were pretty-much
following anyways.
- Adds pretty colors to the `grunt lint` output
- Breaks block-scoped-var :(
Follow-up to #3963. (Returning an Error wasn't useful; it just caused a later error when actually using it because type checkers need to be functions.)
Chrome allowed some of these to be 'null' (allow `node.challenge` etc),
but FF didn't work. This will tell React to use node.setAttribute() to
set these values.
Tested in FF, Chrome, Safari. <keygen> isn't supported on IE.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/keygen
The code sample in tip 18 in the docs contained a call to the
.getDOMNode() method which has been deprecated. The method call was
replaced with a call to React.findDOMNode(), which is the preferred way
of getting DOM nodes from a ref.
This heuristic isn't great because it relies on inspecting deep children which aren't guaranteed to be React elements. In particular, this was causing stack overflows in a component we had that used a *DOM node* as children, like `<DOMContainer>{node}</DOMContainer>`.
This reverts commits:
0a3aa8493a64c9d9d7620c58f4f6b18cf226e442086636747f
The new folder structure is organized around major packages that are expected to ship separately in some form.
`/isomorphic`
I moved classic/modern and children utils into a directory called "isomorphic" with the main export being ReactIsomorphic. This will eventually become the "react" package.
This includes all the dependencies that you might need to create a component without dependencies on the renderer/reconciler.
The rest moves into decoupled renderers.
`/renderers/dom/client` - This is the main renderer for DOM.
`/renderers/dom/server` - This is the server-side renderer for HTML strings.
`/addons` and `/test` - Same as before for now.
You're not supposed to take on a dependency inside another package.
Shared code is organized into a "shared" directory which is intended to support all the packages in that subdirectory. Meaning that once we swap to CommonJS modules, the only time you should use `..` is to target `../shared/` or `../../shared`.
E.g. `/shared/` is common utils that are used by everything.
`/renderers/shared/` is code that is shared by all renderers, such as the main reconciliation algorithm.
Shared code will likely be copied into each package rather than referenced. This allow us to have separate state and allow inlining and deadcode elimination.
Size comparison:
```
raw gz Compared to master @ 6ed98ec0c8
= = build/JSXTransformer.js
-15736 -3247 build/react-with-addons.js
+287 +7 build/react-with-addons.min.js
-14412 -2887 build/react.js
+274 +15 build/react.min.js
```
Differences mostly look to be various bits of whitespace that Babel ends up removing during its transforms (https://gist.github.com/spicyj/21ef31f4d95fb7a58daf). In minified files, mostly additions of `"use strict";`.
My old code here didn't work properly -- for a string child, getIteratorFn would return an iterator that gave each character as its own string, and we'd attempt to loop over that too.
Tests now work in Chrome again.
Also when reusing elements in multiple contexts -- before we were mutating each element to indicate its validity; now we mutate the array containing it (which we create, in the case of rest-arg children).
Fixes#2496. Fixes#3348.
Updated documentation to reflect that using React.cloneElement is the new way to copy an element and preserve `key` and `ref`.
Fixes#3432, closes#3447.
Update links to use https:// where it is supported. There's probably a lot
more that could be fixed, but these are the core ones I found (especially
the download links in order to prevent MITM attacks). Note that there are
some fb.me links that will redirect to http:// even while accessed over
https://, but this seemed like the best way to fix those for now.
NOTE: Only non-third-party files were modified. There are references to
http:// URLs in vendored/third-party files, but seems appropriate to fix
upstream for those rather than editing the files.
Also, copy one image locally to the blog, as it was hotlinking to a site
that did not support https://.
Last, use youtube-nocookie.com instead of youtube.com for video embeds,
as the former doesn't try to set a cookie on load (privacy enhancement).
I'm not super attached to this, but this feels cleaner to me. Might even be faster since flattenChildren doesn't use the index. Probably no change though.
If there are no listeners for `onSelect` yet, do not extract events. This way we can avoid issues where listeners have been set up for some event dependencies for `SelectEventPlugin`, but not all.
For instance, if `topMouseDown` has been registered but not `topMouseUp`, event extraction will set the `mouseDown` flag to true but never unset it. This leads to bugs when `onSelect` is registered and should be firing during normal key behavior. Since no `topMouseUp` has yet occurred to unset the flag, `onSelect` fails to fire.
When the style property existed, but was set to null, `this._previousStyleCopy`
was not set back to `null` causing an old value to persist. This broke setting
the style to `null` the next time.
Fixes#3606.
As far as I can tell, this is almost equivalent and is simpler. When a component's componentDidMount is called, all the listeners for that subtree will have been attached which I think is all that matters.
All testes successfully completed.
- for-in in browsers is slow, i replaced him by Object.keys + for(array)
- simple check of lengths let us not iterate if not same
- now we dont need to test for B's keys missing from A, because if length's is same and prev check success - objB hasn't more keys
- micro optimize: calling objB.hasOwnProperty
- micro optimize: replaced !objA || !obj for more speedy check === null
#inspiredby https://github.com/jurassix/react-immutable-render-mixin/pull/4
$REACT_WEBSITE_BRANCH in https://travis-ci.org/facebook/react/settings/env_vars now needs to point to the stable branch (currently 0.13-stable). I haven't tested the commit-and-push part of this but everything else works so I'm hopeful.
I ended up needing to add this attribute to work around a common IE bug, that clicking on a scrollbar gives focus to the scroll container. I needed to set it as MUST_USE_ATTRIBUTE or the attribute would not be passed through by React successfully.
remove trailing spaces
The current documentation states that the `<select>` tag supports `defaultChecked`, but it actually doesn't. I believe this documentation was meant to be written in the proposed order.
Non-working fiddle using `defaultChecked`: http://jsfiddle.net/jqs1hsLr/1/
Working fiddle using `defaultValue`: http://jsfiddle.net/nv7z0yzL/1/
Turns out lots of people write invalid HTML all the time and no one, including your browser or React, cares. Most invalid HTML combinations don't cause magic reparented nodes; only some do. The HTML5 parsing spec (https://html.spec.whatwg.org/multipage/syntax.html) specifies which tag combinations cause strange parsing behavior. I did my best to encode the logic here. It's more lenient than before in some cases, but more strict in others (before we didn't look at the whole stack of tags; now we warn with deeply nested `p` or `form` or `a` tags).
Rendering to `document.body` in the examples is conveniently short, but it can
be misleading at the same time, especially for newcomers.
While it's possible to render React components to `document.body`, any 3rd
party scripts can also mess up with it, and it can have unintended consequences
and be source of difficult-to-trace bugs.
Now that #1169 is fixed, the only thing this is used for is to determine whether `onTouchTap` causes touch listeners to be added. The only internal uses of TapEventPlugin are where touch events are already initialized (so this doesn't make a difference) and we don't support `onTouchTap` as part of the public API so this should be safe.
This reverts an early commit that made it so that elements from two
different owner in the same slot wouldn't share state.
That behavior was helpful, and we did hit a case which was solved by this.
However, this pattern is extremely uncommon. I've yet to even find the
original case, let alone any existing cases in our codebase.
Therefore, we're dropping this to simplify elements and enable new
optimizations.
We currently override a couple DOM components. We need to ensure everything we
override is still treated as a DOM component, even if it has a composite
component wrapper.
_mountImageIntoNode moved into ReactMount and wasn't being counted where it was supposed to be. In addition, all DOM elements are now wrapped in a composite wrapper but for the perf tools we want to skip over those or else we'll double-count (at least with the current accounting -- and that's effectively what we did before so this brings us back up to parity).
Fixes#3407.
Test Plan:
Used the jsbin from #3407 and saw similar output from this branch and 0.12:
$TRAVIS_COMMIT_RANGE was broken but it seems what we're doing is worse and
resulting in false negatives.
The result of the bad range was that we weren't running lint or tests for
things we should have been. It actually looks like $TRAVIS_COMMIT has been
wrong and it's not clear why this has been working at all.
ReactDOMComponent maintains a copy of the previous style
object to support in-place mutations of props.style.
This cached object was not cleared when the style
property was removed in a props update.
Fixes#3409
There is an exception when value or defaultValue is set but there are no
children as ReactDOMSelect tries to mark the first children as selected
even if there are no children.
I mis-parsed 'shallow copies' as adjective noun, instead of as a compound verb. I've adjusted the text to make it easier to parse on the first read, which should also help ESL learners to be able to parse it easier.
Summary:
Right now, if a component specifies a propType as, for example,
`myProp: React.PropTypes.shape`, without an actual shape
parameter, any prop type will be accepted, because
`React.PropTypes.shape` returns a function (the actual validator),
not an Error, currently indicating that propType checking passed.
This can create an unfortunate situation where a component looks
like it has fully specified `propTypes`, but in fact does not.
This commit addresses this by warning if a propType checker returns
anything non-falsy that is not an Error (currently all the library
PropTypes return null or an Error).
Test Plan:
Added a unit test; ran `jest` in the root repo directory.
Also ran `grunt lint` and `grunt test`
If either argument is not an object and unequal, then shallowEqual should return false.
If only one argument is an object, then shallowEqual should return false.
Fixes#3369
This is in response to #3207 to address concerns regarding third-party
scripts and browser plugins potentially altering DOM nodes within
document.body, causing problems with reconciliation.
Closes#3211.
The only substantial difference here is that I made the harmony example use ES6
classes. The server rendering example was pretty wacky and hard to run but
I did confirm that it works.
Console is undefined in earlier versions of IE when it is not open. This causes an uncaught exception, and breaks applications in these versions of IE when attempting to warn when the console is closed.
Admittedly, console will usually be open when testing in development, but still React should not break the application when it is not.
We added this test internally and it never got added here. We haven't broken it
with any transforms *yet* but it's still good to actually run all of our tests
here too.
These are the only places that seems to be including environment specific
variables in the message format.
By ensuring that they're static, we make it easier to group logs by
format. I also ensure that I keep each addendum separate so that they can
be filtered/grouped separately.
This is a new version of cloneWithProps but this one is moving out of
add-ons. Unlike cloneWithProps, this one doesn't have special logic for
style, className and children.
This one also preserves the original ref. This is critical when upgrading
from a mutative pattern where a child might have a ref on it.
It also preserves context, which is similar to how context would work when
it is parent based. It also ensures that we're compatible with the old
mutative pattern which makes updates easier.
Note: we need to manually specify date in these files so that the sort order is
correct (2 posts on the same day). Otherwise it will just be ABC order, which
is wrong.
Closes: #3256
Without this, transitioning from `<div onClick={null} />` to `<div />` triggered `willDeleteListener` to delete the `click` handler which caused problems; now, we only call `putListener` and `deleteListener` when we have an actual listener.
I now also clean up the `onClickListeners` map upon deletion and don't double-listen when updating the event listener.
* 'master' of https://github.com/facebook/react: (30 commits)
Expose --target flag on jsx executable
Contributing: cleanup quote style
Add Relay blog post
Fix long lines in vendor/fbtransform/visitors
lint vendor/*.js
fix .eslintignore
remove ballmer example
Fix a doc. cloneWithProps clones a ReactElement.
lint from root
Fixed mistake in jsdocs types for cloneWithProps
Put deprecation warning for classSet
Lint vendor/fbtransform as well
More warnings to ReactFragment.create
Warn when using constructor function directly
Move option parsing into react-tools proper.
Remove lodash devDependency
Added the immutability talk to the React.js Conf update.
Use same pathways for browser transforms as we use in react-tools
lint: remove spaces from array brackets
lint: remove spaces from object braces
...
Valid values are 'es3' and 'es5'.
es3: perform reserved words quoting, don't use defineProperty
es5: default, don't do the above, class methods non-enumerable
Apparently I could've used these too because if you accept an arbitrary
node, then these could end up being objects, but those objects might
also be arrays or elements.
We no longer support the legacy factory style of calling component constructors
directly. We only support createElement or the wrapping of classes with
createFactory. Instead of letting this fail in a gross way as we try to run,
add a nice warning that shows up before the gross TypeError.
We were doing some preprocessing for module options in the command line. Since
we also expose the same API via react-tools (and JSXTransformer), we need to do
the same processing from the API. So just move it all to the same place.
This makes sure we can use the same options everywhere, even from react-rails,
without having to specify each one separately in JSXTransformer as well.
This is an anti-pattern that can be easily avoided by putting the logic
in componentDidMount and componentDidUpdate instead.
It creates a dependency on stale data inside render without enforcing
a two-pass render.
We're not sure if this is the way we want to support this API. It creates
two ways of doing things.
It is convenient to avoid needing to explicitly redefine the key of Maps.
However, this use case isn't as common as having an iterable where the
key is on the value, not the key.
This was an important convenience as an upgrade path but shouldn't be
necessary if you're using best-practice of calling createFactory in the
consuming component.
Summary:
This section was confusing. I reworded it from:
"JSX is completely optional. You don't have to use JSX with React.
You can create these trees through `React.createElement`. The first
argument is the tag, pass a properties object as the second
argument and children to the third argument."
to:
"JSX is completely optional; you don't have to use JSX with React.
You can create React elements in plain JavaScript using
`React.createElement`, which takes a tag name or component, a
properties object, and variable number of optional child
arguments."
and additionally added another child element to the example code.
Test Plan:
Read the new paragraph!
Fixes#1297.
onMouseEnter and onMouseLeave shouldn't *actually* use direct dispatch, but doing so is more useful than doing nothing (and I don't think it precludes adding proper enter/leave dispatching later, either).
Test Plan:
grunt test
Previously, `checkAndWarnForMutatedProps` would flag `NaN` props as
having been mutated, because `NaN !== NaN`. This prevents that warning
from being emitted by explicitly checking for `NaN`s.
This ensures that we have a prefix that can be easily identified in logs
so that we can filter out warnings based on their prefix.
This also turns the remaining two monitorCodeUse callers into warnings.
We'll probably still use monitorCodeUse until we know if we want to
deprecate but most releases should only have warnings.
Updated the mention of "facebook.com" on line 3 of the CONTRIBUTING.md file to link to Facebook. Previously, this mention was just in plain text.
Changed from `facebook.com` to `[facebook.com](https://facebook.com)`
No other content has been changed. Content has not been removed from this file in any way.
I made this mistake while upgrading a few callers.
I'm leaving this as warning so that it is always safe to wrap any existing
child in React.addons.createFragment without breaking prod.
This makes upgrading easier.
Currently we use an invariant to prevent this code pattern. That is really
aggressive for something that doesn't actually put React in a bad state. This
diff replaces invariants with warnings and makes those code paths no-ops.
Eslint now allows us to use a different parser, which allows us to use
esprima-fb explicitly. This means we don't have to wait for espree to add
things like rest-param parsing. Though we do need eslint to upgrade its rules
to handle that AST.
I had hoped to enable parsing of our tests but we can't do that until we
change esprima-fb's XJS nodes to JSX.
While I was here, I also enabled the no-unused-vars rule since eslint
understands template strings. I also made the single quote enforcement
actually fail instead of just warn.
This triggers a warning if you try to pass a keyed object as a child.
You now have to wrap it in React.addons.createFragment(object) which
creates a proxy (in dev) which warns if it is accessed. The purpose of
this is to make these into opaque objects so that nobody relies on its
data structure.
After that we can turn it into a different data structure such as a
ReactFragment node or an iterable of flattened ReactElements.
We've actually diverged more with some modules, but we don't want
a cascade of dependencies out here. Mostly, the changes internally that
we don't want are tied to FB infrastructure but otherwise are
functionally equivalent (usually around error reporting, code monitoring).
This diff enables setState to accept a function in addition to a state partial. If you provide a function, it will be called with the up-to-date `state, props, context` as arguments.
This enables some nicer syntax for complex setState patterns:
If setState is doing an increment and wants to guarantee atomicy, you need a function:
```
this.setState(state => ({ number: state.number + 1 }));
```
This atomicy is particularly important if setState is called multiple times in a single frame of execution as the result of complex user actions. It's a tricky bug to chase down and difficult to determine how to fix when you find it. The current pattern of reaching into _pendingState relies on an implementation detail.
In this example: props.doAction() may result in your ancestor re-rendering and providing you with new props. If setState is called directly with an object literal referencing `this.props`, it will use the *old* version of props, not the new value. Using a function solves for this case:
```
this.props.doAction();
this.setState((state, props) => ({ number: state.number * props.multiplier }));
```
enqueueCallbackInternal forgot to schedule an update.
We could rely on the implicit contract of enqueueElement to do it. However,
if we're currently outside a transaction, it'll flush synchronously. Before
we enqueue the callback. We could also enqueueCallback before we
enqueueElement, but that causes a fragile relationship between them. E.g.
enqueueElement should not need to schedule an update if it is the same
element.
In 1.4.0 we can use the TypeScript API directly to preprocess our files.
This lets us get rid of a dependency.
https://github.com/Microsoft/TypeScript/wiki/Using-the-Compiler-API
We can also use this to provide our default libraries so that we don't
need to keep the references in the test file.
This is to make sure we don't end up with differences in our different
testing methods. We may switch out the failure allowances later (maybe
just jest will be good enough and we can let phantom fail for a little
bit).
It's possible to configure Jest to not dump the module cache between
specs. This makes it tricky when we silence warnings one a 2nd call.
In this case, the same message was getting logged so when we expected
the count of warning calls to increment, it didn't.
This makes it more difficult to find bugs in mixins both dynamically
and using a static type system.
We also don't have a way to find these to be upgraded to a new mixin
syntax if we needed to.
This hook is currently an optional noop but could be made required to
create a mixin class.
We freed up this internal name by removing the internal base class.
We're now free to use this name as it was intended.
ReactDOMComponent and ReactCompositeComponent are still confusing as
they're internal but we'll rename them later.
All entry points are for reconciliation are within batching strategies.
Since we don't have any batching strategies with synchronous updates,
there can't be more than one life-cycle method on the stack at any given
time.
Therefore, it's safe to move the composite life cycle flag to a singleton.
This saves us some memory management.
I think that we can get rid of these life cycle states completely in the
future.
Currently, the first setState that happens during initial render will
start a new batch. Any subsequent updates will be batched. That means that
the first setState is synchronous but any subsequent setStates are
asynchronous.
This commit makes it so that the batching starts at the root. That way all
the setStates that happen within life-cycle methods are asynchronous.
I originally did this work so that we could allow setState to be called
before the internal ReactCompositeComponent was constructed. It's unlikely
that we'll go down that route now but this still seems like a better
abstraction. It communicates that this is not immediately updating an
object oriented class. It's just a queue which a minor optimization.
It also avoids bloating the ReactCompositeComponent file.
Since they both depend on the life cycle I break that out into a common
shared dependency. In a follow up I'll refactor the life-cycle management.
We need to move instantiation into the mount phase for context purposes.
To do this I moved the shallow rendering stuff into ReactTestUtils and
reused more of the existing code for it by instantiating a noop child.
Everywhere we refer to the "type" we should pass it to ReactNativeComponent
to resolve any string value into the underlying composite.
As part of the new class effort it is now possible to define React
Components using any type of generic JavaScript class syntax.
This includes TypeScript classes. This test ensures that we don't regress
that support, and also serves as an example for using React in TypeScript.
TypeScript provides a good demo of where we think property initializers
are going.
We don't have any official *type* support for TypeScript yet.
This test trails the ReactES6Class-test file. Some manual tweaking is
required when converting tests.
This adds a matcher called toEqualSpecsIn which executes two test suites,
without reporting the result. It then compares the specs and the number
of expects executed by each spec.
This will be used to ensure that tests written in other languages test the
same thing as the base line, ES6 classes.
Sets up CoffeeScript equivalence test.
As part of the new class effort it is now possible to define React
Components using any type of generic JavaScript class syntax.
This includes CoffeeScript. This test ensures that we don't regress that
support, and also serves as an example for using React in CoffeeScript.
This test fail trails the ReactES6Class-test file. Some manual tweaking is
required when converting tests.
There is no way to queue an update to a context so there is no need for
this field. The only way to get a new context is from above.
Soon _pendingElement will get the same treatment. Once _setPropsInternal
can be removed.
Instead of putting the shared code in a base class method, we use a wrapper
call around all invokations. That way they're free to add code before AND
after the non-shared code.
That way we ensure that component extensions don't need to implement
ReactComponentMixin and do super() calls into it. This helps to create a
tighter API for custom component extensions.
This provides the first step towards moving these methods to static
methods which allows to use a different dispatch mechanism instead of
virtual method calls. E.g. pattern matching.
We need to move instantiation into the mount phase for context purposes.
To do this I moved the shallow rendering stuff into ReactTestUtils and
reused more of the existing code for it by instantiating a noop child.
Everywhere we refer to the "type" we should pass it to ReactNativeComponent
to resolve any string value into the underlying composite.
You can only get a ref to a ReactCompositeComponent, so move the ref code here which gives us more flexibility to put it at the correct time in the lifecycle.
There should be no behavior change in this commit.
Test Plan: jest
This will be based on the site generation time, making doc generation
slightly less deterministic but that's ok. Now we won't depend on
helpful community members updating it for us (#2874) when we forget,
it'll just happen naturally the next time the site is generated.
Summary:
If `getDOMNode()` returns null in `LocalEventTrapMixin`, `listener` will also be null and `accumulateInto` will throw. This changes `LocalEventTrapMixin` to throw a more helpful error message.
Test Plan:
Ran unit test successfully:
```
npm test LocalEventTrapMixin-test.js
```
document.createElement throws an error if you don't pass it any
arguments. Neither PhantomJS nor jest (via jsdom at version jest is
using) behave as browsers do now so this went unnoticed.
This allows state to be set up in the constructor instead of through
getInitialState. getInitialState is now considered part of "classic".
Therefore, they move into ReactClass's constructor.
As a consequence of this, we no longer have a mapping between the internal
representation and the public instance during the mounting process.
Because the constructor hasn't returned yet.
We used to have a special case for calling setState in getInitialState
which was just ignored. This makes that throw and the component is
considered unmounted during the construction phase.
We added a bind to the public instance, but instead we can just pass the
public instance as the context when we execute.
This avoids a warning that fires when we call bind on auto-bound methods.
I don't agree with 80 on principal but it's what we have for now.
This fixes the reasonable cases. Most of the long lines are in docblocks
with long type information or containing links.
These rules are very close to what we have internally. We may still miss
a couple things (jsdoc params being a big one) but it's good enough.
This is also more restrictive than what we enforce internally, but it's
for the best.
In ReactClass we use early validation to warn you if a accidentally defined
propTypes in the wrong place or if you mispelled componentShouldUpdate.
For plain JS classes there is no early validation process. Therefore, we
wait to do this validation until the component is mounted before we issue
the warning.
This should bring us to warning-parity with ReactClass.
This is the base class that will be used by ES6 classes.
I'm only moving setState and forceUpdate to this base class and the other
functions are disabled for modern classes as we're intending to deprecate
them. The base classes only have getters that warn if accessed. It's as if
they didn't exist.
ReactClass now extends ReactComponentBase but also adds the deprecated
methods. They are not yet fully deprecated on the ReactClass API.
I added some extra tests to composite component which we weren't testing
to avoid regressions.
I also added some test for ES6 classes. These are not testing the new
state initialization process. That's coming in a follow up.
Fix outdated copyright year (update to 2015)
The copyright year was out of date. Copyright notices must reflect the current year. This commit updates the listed year to 2015.
ES6 classes won't have an early validation step. Therefore I added some
extra validation later on in the process. These would've normally have
been caught by createClass in classic React.
This throws an error that is immediately caught. This allows you to use the
debugger's "break on caught exception" feature to break on warnings.
This should help with tracking down these warnings using the stack.
However, it could also add more noise to other debugging pattern.
This essentially copies all classic element creation tests to the modern
JSX tests. The classic tests doesn't use JSX and modern tests do.
The idea is that the JSX tests can start dropping dynamic checks once
we have Flow support for those features. JSX won't be necessary for
dropping dynamic checks. Plain object will also work. Flow will also not
be necessary for JSX. However, the tests should test for the suggested
combination (JSX + Flow).
This also moves some misplaced tests to ReactDOM and Validator.
Note that the modern tests uses ES6 classes. I will add separate tests for
those. However, these are not guaranteed to have .displayName so all our
error messages should check .name if available instead. This should be
better abstracted but I just adhoc fix this for now.
This should make it more clear that even though `$` is used in 4 methods, only 2 of them are crucial for integrating the modal into the components lifecycle methods and the other 2 are just helpers.
This adds a warning to React.createElement in __DEV__ about using null
or undefined. This is technically valid since element creation can be
considered safe and usable in multiple rendering environments. But
rendering in a DOM environment with an element with null/undefined type
is not safe.
Update tutorial.md to improve grammatical parallelism in features list. Also added periods to follow first item's syntax.
BEFORE: "Live updates: as other users comment we'll pop them into the comment view in real time"
AFTER: "Live updates: other users' comments are popped into the comment view in real time."
BEFORE: "Markdown formatting: users can use Markdown to format their text"
AFTER: "Markdown formatting: users can use Markdown to format their text."
This moves ReactClass, ReactElement and ReactPropTypes into a legacy folder
but since it's not quite legacy yet, I call it "classic".
These are "classic" because they are decoupled and can be replaced by
ES6 classes, JSX and Flow respectively.
This also extracts unit tests from ReactCompositeComponent, which was
terribly overloaded, into the new corresponding test suites.
There is one weird case for ReactContextValidator. This actually happens in
core, and technically belongs to ReactCompositeComponent. I'm not sure
we will be able to statically validate contexts so this might be a case
for dynamic checks even in the future. Leaving the unit tests in classic
until we can figure out what to do with them.
In order to improve support for Chinese and Japanese IME input in
Internet Explorer, use a fallback composition state to determine
inserted text. IE composition events are mostly okay, except for
certain punctuation characters that are ignored. Using the fallback, we
can detect these characters.
The fallback is also useful for emitting `beforeInput` events, so it
makes sense to simply combine these plugins.
This change also incorporates a recent change to the Google Input Tools
browser extension that exposes a `data` field via the `detail` object
on the custom composition events it emits.
IE9+ has support for window.getSelection, but we’re still using
document.selection for IE9/10. Only use the old IE selection API if the
modern one is unavailable.
Based on conversation in https://github.com/facebook/react/pull/2501. A good place to guide people further in finding the complete set of tools needed to build an application.
This was a file we probably never should have synced out in the first
place. We don't use it and it provides the same basic functionality that
bin/jsx provides.
ART, just like MultiChild adds an expando property to manage it's diffing
state. This is ugly and bad. We should be moving this state outside the
component for use by the diffing algorithm. This state is not needed by
components nested in composites, and varies by diffing algorithm.
It sucks that I have to add it to every component just to support ART,
but that's the quickest solution, other than disabling preventExtensions.
At least now we know that it sucks.
This separates the reconciliation step of children into a separate module.
This is the first step towards prerendering.
The stateful instances are reconciled and put into a "rendered children"
set. Updates creates a new of these sets. These two sets are then diffed
to create insert/move/remove operations on the set.
The next step is to move the ReactChildReconciler step to before the
native DOM component. That way it's possible to rely on child
reconciliation without relying on diffing.
Summary:
After #2570, `mountDepth` is only used to enforce that `setProps` and `replaceProps` is only invoked on the top-level component. This replaces `mountDepth` with a simpler `isTopLevel` boolean set by `ReactMount` which reduces the surface area of the internal API and removes the need to thread `mountDepth` throughout React core.
Reviewers: @sebmarkbage @zpao
Test Plan:
Ran unit tests successfully:
```
npm run jest
```
Currently, `ReactUpdates` updates dirty components in increasing order of mount depth. However, mount depth is only relative to the component passed into `React.render`. This breaks down for components that invoke `React.render` as an implementation detail because the child components will be updated before the parent component.
This fixes the problem by using the order in which components are mounted (instead of their depth). The mount order transcends component trees (rooted at `React.render` calls).
Reviewers: @sebmarkbage @zpao
Test Plan:
Ran unit tests successfully:
```
npm run jest
```
Summary:
Changes the way we instrument methods for `ReactPerf` so that developer tools can assign implicit method names to measured functions.
Reviewers: @zpao @sebmarkbage
Update to the animation documentation for ReactTransitionGroup to clear the air on where one can use it.
If someone tries to use it off of React.addons.ReactTransitionGroup, which is undefined, instead of its real location, React.addons.TransitionGroup, they get a vague error about being unable to set defaultProps of undefined in the React createElement body.
Summary:
Currently, `ReactClass` mutates values returned by `getDefaultProps`, `getInitialState`, and `getChildContext`. This is bad because the objects may, for example, be cached and re-used across instances of a React component.
This changes `ReactClass` to instead create a new object. In return for allocating a new object, I've replaced `mapObject` with a `for ... in` so that we are no longer allocating an unused object.
Fair trade, IMO.
Test Plan:
Ran unit tests successfully:
```
npm run jest
```
Conflicts:
src/core/ReactCompositeComponent.js
Conflicts:
src/class/ReactClass.js
The word "Friends" does establish a relationship however it does not fit in the vernacular of react.
This change makes the phrase more explicit and more familiar.
We currently have three DOM specific hooks that get injected. I move those
out to ReactComponentEnvironment. The idea is to eventually remove this
injection as the reconciler gets refactored.
There is also a BackendIDOperation which is specific to the DOM component
itself so I move this injection to be more specific to the DOMComponent.
E.g. it makes sense for it to be injectable for cross-worker DOM operations
but it doesn't make sense for ART components.
If several children complete leaving before rendering TransitionGroup,
only the last one was removed. This could easily happen if
callback in componentWillLeave is called synchronously and several items
are removed from array. The other case is when ReactCSSTransitionGroup
has transitionLeave={false} and array is also cleaned up.
The bug was happening because this.state.children was used as a base for
children removal and it wasn't updated until the render, so only the last
removal was actually happening.
Fix involves keeping the updated children state between invocations of
_handleDoneLeaving. After updating this.state and rendering,
updatedState is cleaned up and ready for subsequent array modifications.
Test case included.
This is part of moving more logic out of the base classes.
setProps, replaceProps etc. are not accessible from anything other than
ReactClass so we can safely move it to ReactCompositeComponent.
mountComponentIntoNode is tightly coupled to ReactMount. It's part of the
outer abstraction, the mount point, not the individual component.
The _owner field is unnecessary since it's reachable from _currentElement.
The _lifeCycle field is unnecessary because an internal component should
not even need to exist at all if it's unmounted. It should be dereferenced
internally, and never exposed externally.
The only case where it's important is for batching updates where we
currently avoid calling performUpdateIfNecessary if it's mounted. However,
this function is already only executed "if necessary" so we just make sure
that it's not necessary after unmount by resetting all the pending fields.
We currently make a copy of .style because we support mutating the style object in place. Instead of storing it back on props, store it separately on the component instance so that we don't mutate props anywhere. This is gross but should all be cleaned up after #2008 is resolved.
Test Plan: jest
createFullPageComponent doesn't reference ReactBrowserComponentMixin directly so the mixin should get injected before the components are created. Previously, this test failed because getDOMNode wasn't present on the component instance.
Test Plan: jest
...unless they already have a wrapper. Also, add tagName to every wrapper.
This ensures that refs are consistent. They always look like composite
components. This effectively hides the internal implementation details of
real DOM components since you can no longer get a ref to one.
In the future we might want to drop this wrapper and have refs refer
directly to the DOM node.
I currently use a hacky way of auto-wrapping inside of ReactNativeComponent
so that any given string can be wrapped. Better suggestions are welcome.
Fixes#2493, also closes#2353 as it incorporates a variant of that fix.
- Instead of having getEmptyComponent return `<noscript />` directly, wrap it in a class that we can easily identify later as being an empty component
- Cache the empty component element instead of recreating one each time
- Avoid touching the nullComponentIdsRegistry dictionary at all when not dealing with empty components
- Move empty-component tests to a separate file
Test Plan: jest
ReactTextComponent's implementation is DOM-specific; instead of flattenChildren creating the ReactTextComponent instances, ReactNativeComponent now takes care of having ReactTextComponent injected and creating the component instance. I also renamed ReactTextComponent to ReactDOMTextComponent and moved it to browser/ui/ where it belongs. ReactDOMTextComponent no longer inherits directly from ReactComponent and instead implements construct and {mount,receive,unmount}Component directly.
This diff removes `ReactTestUtils.isTextComponent` which should have previously never returned true when using public APIs.
Test Plan: jest, use ballmer-peak example.
"appear" differs from "enter" in that all children of a transition group at mount time will "appear" but will not "enter". All children later added to an existing transition group will "enter" but not "appear".
This extra transition phase allows for animation-on-mount effects.
A mirroring "appear" prop has been added to ReactCSSTransitionGroup, however for reverse-compatibility (and because "appear" is less common) it defaults to false.
Thanks to @afa for his work investigating the possible ways to implement this.
monitorScrollValue is only called with `ViewportMetrics.refreshScrollValues` (https://github.com/facebook/react/blob/master/src/browser/ReactBrowserEventEmitter.js#L333-L334) and the window scroll properties (scrollTop and scrollLeft) don't change on resize (from my testings), so there is no need to listen for window resizes.
I also tried to see why the resize listener was added from the history but it was introduced on the initial commits.
I created a simple page that shows that http://jsbin.com/nuhice, open the console.
While working on #2382, I accidentally broke this behavior (causing text components to get unmounted and remounted for any update) but we didn't have any unit test for it. Now we do.
Test Plan: jest TextComponent
ReactClass is now composed by ReactCompositeComponent rather than
inherit from it.
The state transition functions currently use ReactInstanceMap to map an
instance back to an internal representation.
I updated some tests to use public APIs. Other unit tests still reach into
internals but now we can find them using ReactInstanceMap.
I will do more cleanup in follow ups. The purpose of this diff is to
preserve semantics and most of the existing code.
This effectively enables support for ES6 classes. All you would need to
expose is ReactClassMixin.
The use of the conjunction "and" leads to an improper assertion about what should/shouldn't be done. Using a semicolon resolves this by indicating the contrasting alternative.
* master: (113 commits)
Remove esprima-fb and use Syntax from jstransform
Update React.renderToString argument type in docs
[traverseAllChildren] fix out-of-scope var use.
Use double quote for transformed `displayName` and `data-*`
Remove unrelated comment
Fix typo in If/Else JSX doc.
Cleanup a couple unused variables
Use dump cache and remove factory from ReactElement-test
Update deprecated propTypes
Bring in jsfiddle integration script, add harmony
Extending period in which click events are ignored
React.renderComponent --> React.render
Followup fix for React.PropTypes.node
Add comma for readability in tutorial
Drop internal uses of .type on the class
Drop Legacy Factories Around Classes
Drop ReactDOM from internal DOM extensions
Added comma to increase readability.
Add 0.12 starter kit
Change the date and the link url to match the proper roundup
...
Conflicts:
docs/docs/02.1-jsx-in-depth.md
Dear ES6 gods, bring us `let` soon.
This fixes an issue where non-keyed iterables are used as children and the value of `i` would be undefined because its used out of scope. This adds a separately scoped iteration index value and appropriately increments it as iteration continues. Doi.
While I'm in there, make the usage of falsey `nameSoFar` more obvious and more consistent with the existing usage on L115
Test plan: first wrote a test covering this previously untested path. Saw an identical issue as was experienced in development environment. Then ensured test passed after this diff.
JSX currently transforms everything to double quote except these two. This way, it's at least consistent and will satisfy half of the people who do put a strict quotation linting on their project.
Test: `jest`, check the double quoted transformed `data-bla="something"`.
We need to use dump cache because we don't enable it by default internally.
While I'm at it, I might as well kill the ComponentFactory variable which
is now just an alias.
Classes are now pure classes without a legacy factory around them.
Since classes will become just any function that returns a valid instance,
let's drop isValidClass.
There's some hacks in here for auto-mocking frameworks (jest) that mock the
prototype of these classes. These hacks allow these classes to be mounted.
On ios device, browser simulates mouse events, but does that with
a delay, because of double tap gesture. The problem is that
TapEventPlugins listens to both types of events, so it fires twice
Everytime there is a touch event, we should ignore mouse events that
follow it. This way, we still respond to both mouse and touch events,
just ignore the device generated ones.
For example, warning might be replaced with a module that throws errors,
as is the case internally when running tests. Previously we were
whitelisting this test to provide time to update callsites. Now we
aren't and it fails.
Hi in chrome debugger, the files that use sourcemaps from the transformer get "null" as the filename during debug, https://github.com/facebook/react/blob/master/main.js#L15 "sourceFilename" is used instead of "filename" to specify the filename in the sourcemap.
This prevents feature tests like:
var ReactElement = React.createElement(...).constructor;
if (element.constructor === ReactElement)
This is intentional so that we have the option to make these plain objects.
E.g. for direct inlining or replacing them with value types.
This moves logic responsible for class creation and mixins into
the ReactClass module. This currently creates a class that extends
the ReactCompositeBase but in the future, this will be decoupled as
ReactCompositeComponent will compose these classes.
This is just a cut/paste.
Fixes#1392.
Previously, ReactComponent.updateComponent set the new props and owner and updated the component's refs. Because it did the actual props assignment, it had to be called by ReactCompositeComponent between componentWillMount and componentDidMount, meaning that it was skipped if shouldComponentUpdate returned false. Now, updateComponent takes the old and new descriptors and only updates refs, allowing a subclass to call updateComponent at a convenient time (specifically, it can be before `this._descriptor` is updated if the subclass also overrides performUpdateIfNecessary).
The new update cycle for composites is:
- receiveComponent is called which stores `this._pendingDescriptor` and calls performUpdateIfNecessary directly or a state update is enqueued, in which case ReactUpdates will call performUpdateIfNecessary
- performUpdateIfNecessary ensures that an update is still pending (which might no longer be the case if an update is queued for a subcomponent that was updated through a parent's reconciliation) and calls updateComponent with the old and new descriptors
- updateComponent calls super to update refs, then calls componentWillReceiveProps (if applicable) and shouldComponentUpdate -- if shouldComponentUpdate returns false, `this._descriptor`, `this.props`, and `this.state` are updated and the update is skipped; else, _performComponentUpdate is called
- _performComponentUpdate calls componentWillUpdate and _updateRenderedComponent, and enqueues the componentDidUpdate call (in that order)
- _updateRenderedComponent calls render and updates the rendered component appropriately
For DOM components (essentially unchanged):
- receiveComponent is called which does a short-circuit check for descriptor equality and delegates to super (which stores `this._pendingDescriptor` and calls performUpdateIfNecessary)
- performUpdateIfNecessary (not overridden) sets new values for `this.props`, etc. and calls updateComponent
- updateComponent does the DOM property and children updates (some synchronously, some queued for the transaction close)
For text and ART components (unchanged):
- receiveComponent updates the DOM or ART directly based on the new props
- updateComponent is never called
Notable changes:
- When shouldComponentUpdate returns false, refs are still updated
- ReactDefaultPerf now includes lifecycle methods in component timings
- updateComponent's signature changed (technically this is part of the public API, though we've never documented it)
Test Plan: jest
Same for <pre> and <listing>. Browsers are crazy.
Test Plan: jest, verify in Chrome that starting textareas with a value starting with two newlines renders both newlines instead of one newline, as it did before.
This lets you use any kind of iterable as a container of react child elements. It also preserves keys when possible if the iterable is keyed.
* Use an ES6 Map or Set to hold children.
* Use an Immutable-js collection to hold children.
* Use a function* which yields children.
Concretely, this removes the necessary conversion to JS objects if you're mapping over Immutable-js collections to get children, i.e.:
```
<div>
{myImmutable.map(val => <span>{val}</span>).toJS()
</div>
```
Now we can remove the `toJS()` and the intermediate allocation along with it.
This also cleans up the traverseAllChildrenImpl method.
* Improved warnings for deprecated methods in plain JS classes
#### Bug Fixes
* Loosened `dangerouslySetInnerHTML` restrictions so `{__html: undefined}` will no longer throw
* Fixed extraneous context warning with non-pure `getChildContext`
* Ensure `replaceState(obj)` retains prototype of `obj`
### React with Add-ons
### Bug Fixes
* Test Utils: Ensure that shallow rendering works when components define `contextTypes`
## 0.13.2 (April 18, 2015)
### React Core
#### New Features
* Added `strokeDashoffset`, `flexPositive`, `flexNegative` to the list of unitless CSS properties
* Added support for more DOM properties:
*`scoped` - for `<style>` elements
*`high`, `low`, `optimum` - for `<meter>` elements
*`unselectable` - IE-specific property to prevent user selection
#### Bug Fixes
* Fixed a case where re-rendering after rendering null didn't properly pass context
* Fixed a case where re-rendering after rendering with `style={null}` didn't properly update `style`
* Update `uglify` dependency to prevent a bug in IE8
* Improved warnings
### React with Add-Ons
#### Bug Fixes
* Immutabilty Helpers: Ensure it supports `hasOwnProperty` as an object key
### React Tools
* Improve documentation for new options
## 0.13.1 (March 16, 2015)
### React Core
#### Bug Fixes
* Don't throw when rendering empty `<select>` elements
* Ensure updating `style` works when transitioning from `null`
### React with Add-Ons
#### Bug Fixes
* TestUtils: Don't warn about `getDOMNode` for ES6 classes
* TestUtils: Ensure wrapped full page components (`<html>`, `<head>`, `<body>`) are treated as DOM components
* Perf: Stop double-counting DOM components
### React Tools
#### Bug Fixes
* Fix option parsing for `--non-strict-es6module`
## 0.13.0 (March 10, 2015)
### React Core
#### Breaking Changes
* Deprecated patterns that warned in 0.12 no longer work: most prominently, calling component classes without using JSX or React.createElement and using non-component functions with JSX or createElement
* Mutating `props` after an element is created is deprecated and will cause warnings in development mode; future versions of React will incorporate performance optimizations assuming that props aren't mutated
* Static methods (defined in `statics`) are no longer autobound to the component class
*`ref` resolution order has changed slightly such that a ref to a component is available immediately after its `componentDidMount` method is called; this change should be observable only if your component calls a parent component's callback within your `componentDidMount`, which is an anti-pattern and should be avoided regardless
* Calls to `setState` in life-cycle methods are now always batched and therefore asynchronous. Previously the first call on the first mount was synchronous.
*`setState` and `forceUpdate` on an unmounted component now warns instead of throwing. That avoids a possible race condition with Promises.
* Access to most internal properties has been completely removed, including `this._pendingState` and `this._rootNodeID`.
#### New Features
* Support for using ES6 classes to build React components; see the [v0.13.0 beta 1 notes](https://facebook.github.io/react/blog/2015/01/27/react-v0.13.0-beta-1.html) for details.
* Added new top-level API `React.findDOMNode(component)`, which should be used in place of `component.getDOMNode()`. The base class for ES6-based components will not have `getDOMNode`. This change will enable some more patterns moving forward.
* Added a new top-level API `React.cloneElement(el, props)` for making copies of React elements – see the [v0.13 RC2 notes](/react/blog/2015/03/03/react-v0.13-rc2.html#react.cloneelement) for more details.
* New `ref` style, allowing a callback to be used in place of a name: `<Photo ref={(c) => this._photo = c} />` allows you to reference the component with `this._photo` (as opposed to `ref="photo"` which gives `this.refs.photo`).
*`this.setState()` can now take a function as the first argument for transactional state updates, such as `this.setState((state, props) => ({count: state.count + 1}));`– this means that you no longer need to use `this._pendingState`, which is now gone.
* Support for iterators and immutable-js sequences as children.
#### Deprecations
*`ComponentClass.type` is deprecated. Just use `ComponentClass` (usually as `element.type === ComponentClass`).
* Some methods that are available on `createClass`-based components are removed or deprecated from ES6 classes (`getDOMNode`, `replaceState`, `isMounted`, `setProps`, `replaceProps`).
### React with Add-Ons
#### New Features
* [`React.addons.createFragment` was added](/react/docs/create-fragment.html) for adding keys to entire sets of children.
#### Deprecations
*`React.addons.classSet` is now deprecated. This functionality can be replaced with several freely available modules. [classnames](https://www.npmjs.com/package/classnames) is one such module.
* Calls to `React.addons.cloneWithProps` can be migrated to use `React.cloneElement` instead – make sure to merge `style` and `className` manually if desired.
### React Tools
#### Breaking Changes
* When transforming ES6 syntax, `class` methods are no longer enumerable by default, which requires `Object.defineProperty`; if you support browsers such as IE8, you can pass `--target es3` to mirror the old behavior
#### New Features
*`--target` option is available on the jsx command, allowing users to specify and ECMAScript version to target.
*`es5` is the default.
*`es3` restores the previous default behavior. An additional transform is added here to ensure the use of reserved words as properties is safe (eg `this.static` will become `this['static']` for IE8 compatibility).
* The transform for the call spread operator has also been enabled.
### JSXTransformer
#### Breaking Changes
* The return value of `transform` now contains `sourceMap` as a JS object already, not an instance of `SourceMapGenerator`.
### JSX
#### Breaking Changes
* A change was made to how some JSX was parsed, specifically around the use of `>` or `}` when inside an element. Previously it would be treated as a string but now it will be treated as a parse error. The [`jsx_orphaned_brackets_transformer`](https://www.npmjs.com/package/jsx_orphaned_brackets_transformer) package on npm can be used to find and fix potential issues in your JSX code.
## 0.12.2 (December 18, 2014)
### React Core
* Added support for more HTML attributes: `formAction`, `formEncType`, `formMethod`, `formTarget`, `marginHeight`, `marginWidth`
* Added `strokeOpacity` to the list of unitless CSS properties
* Removed trailing commas (allows npm module to be bundled and used in IE8)
* Fixed bug resulting in error when passing `undefined` to `React.createElement` - now there is a useful warning
### React Tools
* JSX-related transforms now always use double quotes for props and `displayName`
## 0.12.1 (November 18, 2014)
### React Tools
* Types transform updated with latest support
* jstransform version updated with improved ES6 transforms
* Explicit Esprima dependency removed in favor of using Esprima information exported by jstransform
## 0.12.0 (October 28, 2014)
### React Core
@@ -169,7 +332,7 @@
#### New Features
* Added warnings to help migrate towards descriptors
* Made it possible to server render without React-related markup (`data-reactid`, `data-react-checksum`). This DOM will not be mountable by React. [Read the docs for `React.renderComponentToStaticMarkup`](http://facebook.github.io/react/docs/top-level-api.html#react.rendercomponenttostaticmarkup)
* Made it possible to server render without React-related markup (`data-reactid`, `data-react-checksum`). This DOM will not be mountable by React. [Read the docs for `React.renderComponentToStaticMarkup`](https://facebook.github.io/react/docs/top-level-api.html#react.rendercomponenttostaticmarkup)
* Added support for more attributes:
*`srcSet` for `<img>` to specify images at different pixel ratios
*`textAnchor` for SVG
@@ -181,7 +344,7 @@
### Addons
*`update` function to deal with immutable data. [Read the docs](http://facebook.github.io/react/docs/update.html)
*`update` function to deal with immutable data. [Read the docs](https://facebook.github.io/react/docs/update.html)
### react-tools
* Added an option argument to `transform` function. The only option supported is `harmony`, which behaves the same as `jsx --harmony` on the command line. This uses the ES6 transforms from [jstransform](https://github.com/facebook/jstransform).
@@ -343,7 +506,7 @@
### React with Addons (New!)
* Introduced a separate build with several "addons" which we think can help improve the React experience. We plan to deprecate this in the long-term, instead shipping each as standalone pieces. [Read more in the docs](http://facebook.github.io/react/docs/addons.html).
* Introduced a separate build with several "addons" which we think can help improve the React experience. We plan to deprecate this in the long-term, instead shipping each as standalone pieces. [Read more in the docs](https://facebook.github.io/react/docs/addons.html).
### JSX
@@ -376,10 +539,10 @@
* Switch from using `id` attribute to `data-reactid` to track DOM nodes. This allows you to integrate with other JS and CSS libraries more easily.
* Support for more DOM elements and attributes (e.g., `<canvas>`)
* Improved server-side rendering APIs. `React.renderComponentToString(<component>, callback)` allows you to use React on the server and generate markup which can be sent down to the browser.
*`prop` improvements: validation and default values. [Read our blog post for details...](http://facebook.github.io/react/blog/2013/07/11/react-v0-4-prop-validation-and-default-values.html)
* Support for the `key` prop, which allows for finer control over reconciliation. [Read the docs for details...](http://facebook.github.io/react/docs/multiple-components.html)
* Removed `React.autoBind`. [Read our blog post for details...](http://facebook.github.io/react/blog/2013/07/02/react-v0-4-autobind-by-default.html)
* Improvements to forms. We've written wrappers around `<input>`, `<textarea>`, `<option>`, and `<select>` in order to standardize many inconsistencies in browser implementations. This includes support for `defaultValue`, and improved implementation of the `onChange` event, and circuit completion. [Read the docs for details...](http://facebook.github.io/react/docs/forms.html)
*`prop` improvements: validation and default values. [Read our blog post for details...](https://facebook.github.io/react/blog/2013/07/11/react-v0-4-prop-validation-and-default-values.html)
* Support for the `key` prop, which allows for finer control over reconciliation. [Read the docs for details...](https://facebook.github.io/react/docs/multiple-components.html)
* Removed `React.autoBind`. [Read our blog post for details...](https://facebook.github.io/react/blog/2013/07/02/react-v0-4-autobind-by-default.html)
* Improvements to forms. We've written wrappers around `<input>`, `<textarea>`, `<option>`, and `<select>` in order to standardize many inconsistencies in browser implementations. This includes support for `defaultValue`, and improved implementation of the `onChange` event, and circuit completion. [Read the docs for details...](https://facebook.github.io/react/docs/forms.html)
* We've implemented an improved synthetic event system that conforms to the W3C spec.
* Updates to your component are batched now, which may result in a significantly faster re-render of components. `this.setState` now takes an optional callback as it's second parameter. If you were using `onClick={this.setState.bind(this, state)}` previously, you'll want to make sure you add a third parameter so that the event is not treated as the callback.
React is one of Facebook's first open source projects that is both under very active development and is also being used to ship code to everybody on facebook.com. We're still working out the kinks to make contributing to this project as easy and transparent as possible, but we're not quite there yet. Hopefully this document makes the process for contributing clear and preempts some questions you may have.
React is one of Facebook's first open source projects that is both under very active development and is also being used to ship code to everybody on [facebook.com](https://www.facebook.com). We're still working out the kinks to make contributing to this project as easy and transparent as possible, but we're not quite there yet. Hopefully this document makes the process for contributing clear and answers some questions that you may have.
## Our Development Process
@@ -23,11 +23,11 @@ The core team will be monitoring for pull requests. When we get one, we'll run s
5. Make sure your code lints (`grunt lint`) - we've done our best to make sure these rules match our internal linting guidelines.
6. If you haven't already, complete the CLA.
### Contributor License Agreement ("CLA")
### Contributor License Agreement (CLA)
In order to accept your pull request, we need you to submit a CLA. You only need to do this once, so if you've done this for another Facebook open source project, you're good to go. If you are submitting a pull request for the first time, just let us know that you have completed the CLA and we can cross-check with your GitHub username.
Complete your CLA here: <https://code.facebook.com/cla>
[Complete your CLA here.](https://code.facebook.com/cla)
## Bugs
@@ -41,24 +41,29 @@ The best way to get your bug fixed is to provide a reduced test case. jsFiddle,
### Security Bugs
Facebook has a [bounty program](https://www.facebook.com/whitehat/) for the safe disclosure of security bugs. With that in mind, please do not file public issues and go through the process outlined on that page.
Facebook has a [bounty program](https://www.facebook.com/whitehat/) for the safe disclosure of security bugs. With that in mind, please do not file public issues; go through the process outlined on that page.
## How to Get in Touch
* IRC - [#reactjs on freenode](http://webchat.freenode.net/?channels=reactjs)
*Mailing list - [reactjs on Google Groups](http://groups.google.com/group/reactjs)
* IRC - [#reactjs on freenode](https://webchat.freenode.net/?channels=reactjs)
*Discussion forum - [discuss.reactjs.org](https://discuss.reactjs.org/)
## Style Guide
### Code
Our linter will catch most styling issues that may exist in your code.
You can check the status of your code styling by simply running: `grunt lint`
* Use semicolons;
* Commas last,
However, there are still some styles that the linter cannot pick up. If you are unsure about something, looking at [Airbnb's Style Guide](https://github.com/airbnb/javascript) will guide you in the right direction.
### Code Conventions
* Use semicolons `;`
* Commas last `,`
* 2 spaces for indentation (no tabs)
* Prefer `'` over `"`
*`"use strict";`
*`'use strict';`
* 80 character line length
*"Attractive"
*Write "attractive" code
* Do not use the optional parameters of `setTimeout` and `setInterval`
### Documentation
@@ -67,4 +72,4 @@ Facebook has a [bounty program](https://www.facebook.com/whitehat/) for the safe
## License
By contributing to React, you agree that your contributions will be licensed under its BSD license..
By contributing to React, you agree that your contributions will be licensed under its BSD license.
React is a JavaScript library for building user interfaces.
* **Just the UI:** Lots of people use React as the V in MVC. Since React makes no assumptions about the rest of your technology stack, it's easy to try it out on a small feature in an existing project.
* **Virtual DOM:** React uses a *virtual DOM* diff implementation for ultra-high performance. It can also render on the server using Node.js — no heavy browser DOM required.
* **Virtual DOM:** React abstracts away the DOM from you, giving a simpler programming model and better performance. React can also render on the server using Node, and it can power native apps using [React Native](https://facebook.github.io/react-native/).
* **Data flow:** React implements one-way reactive data flow which reduces boilerplate and is easier to reason about than traditional data binding.
[Learn how to use React in your own project.](http://facebook.github.io/react/docs/getting-started.html)
**NEW**! Check out our newest project [React Native](https://github.com/facebook/react-native), which uses React and JavaScript to create native mobile apps.
[Learn how to use React in your own project](https://facebook.github.io/react/docs/getting-started.html).
## Examples
We have several examples [on the website](http://facebook.github.io/react/). Here is the first one to get you started:
We have several examples [on the website](https://facebook.github.io/react/). Here is the first one to get you started:
```js
varHelloMessage=React.createClass({
@@ -27,7 +29,7 @@ React.render(
This example will render "Hello John" into a container on the page.
You'll notice that we used an HTML-like syntax; [we call it JSX](http://facebook.github.io/react/docs/jsx-in-depth.html). JSX is not required to use React, but it makes code more readable, and writing it feels like writing HTML. A simple transform is included with React that allows converting JSX into native JavaScript for browsers to digest.
You'll notice that we used an HTML-like syntax; [we call it JSX](https://facebook.github.io/react/docs/jsx-in-depth.html). JSX is not required to use React, but it makes code more readable, and writing it feels like writing HTML. A simple transform is included with React that allows converting JSX into native JavaScript for browsers to digest.
## Installation
@@ -35,12 +37,12 @@ The fastest way to get started is to serve JavaScript from the CDN (also availab
We've also built a [starter kit](http://facebook.github.io/react/downloads/react-0.12.0.zip) which might be useful if this is your first time using React. It includes a webpage with an example of using React with live code.
We've also built a [starter kit](https://facebook.github.io/react/downloads/react-0.13.3.zip) which might be useful if this is your first time using React. It includes a webpage with an example of using React with live code.
If you'd like to use [bower](http://bower.io), it's as easy as:
@@ -86,7 +88,7 @@ grunt test
grunt test --debug
# For speed, you can use fasttest and add --filter to only run one test
grunt fasttest --filter=ReactIdentity
# Lint the code with JSHint
# Lint the code with ESLint
grunt lint
# Wipe out build directory
grunt clean
@@ -103,3 +105,6 @@ Examples provided in this repository and in the documentation are [separately li
### More…
There's only so much we can cram in here. To read more about the community and guidelines for submitting pull requests, please read the [Contributing document](CONTRIBUTING.md).
## Troubleshooting
See the [Troubleshooting Guide](https://github.com/facebook/react/wiki/Troubleshooting)
The easiest way to do this is to have a separate clone of this repository, checked out to the `gh-pages` branch. We have a build step that expects this to be in a directory named `react-gh-pages` at the same depth as `react`. Then it's just a matter of running `grunt docs`, which will compile the site and copy it out to this repository. From there you can check it in.
The easiest way to do this is to have a separate clone of this repository, checked out to the `gh-pages` branch. We have a build step that expects this to be in a directory named `react-gh-pages` at the same depth as `react`. Then it's just a matter of running `grunt docs`, which will compile the site and copy it out to this repository. From there, you can check it in.
**Note:** This should only be done for new releases. You should create a tag corresponding to the release tag in the main repository.
[JSFiddle](http://jsfiddle.net) just announced support for React. This is an exciting news as it makes collaboration on snippets of code a lot easier. You can play around this **[base React JSFiddle](http://jsfiddle.net/vjeux/kb3gN/)**, fork it and share it! A [fiddle without JSX](http://jsfiddle.net/vjeux/VkebS/) is also available.
[JSFiddle](https://jsfiddle.net) just announced support for React. This is an exciting news as it makes collaboration on snippets of code a lot easier. You can play around this **[base React JSFiddle](http://jsfiddle.net/vjeux/kb3gN/)**, fork it and share it! A [fiddle without JSX](http://jsfiddle.net/vjeux/VkebS/) is also available.
<blockquote class="twitter-tweet" align="center"><p>React (by Facebook) is now available on JSFiddle. <a href="http://t.co/wNQf9JPv5u" title="http://facebook.github.io/react/">facebook.github.io/react/</a></p>— JSFiddle (@jsfiddle) <a href="https://twitter.com/jsfiddle/status/341114115781177344">June 2, 2013</a></blockquote>
React was open sourced two weeks ago and it's time for a little round-up of what has been going on.
@@ -38,10 +38,10 @@ It looks like [Ben Alpert](http://benalpert.com/) is the first person outside of
## Origins of React
[Pete Hunt](http://www.petehunt.net/blog/) explained what differentiates React from other JavaScript libraries in [a previous blog post](http://facebook.github.io/react/blog/2013/06/05/why-react.html). [Lee Byron](http://leebyron.com/) gives another perspective on Quora:
[Pete Hunt](http://www.petehunt.net/blog/) explained what differentiates React from other JavaScript libraries in [a previous blog post](/react/blog/2013/06/05/why-react.html). [Lee Byron](http://leebyron.com/) gives another perspective on Quora:
> React isn't quite like any other popular Javascript libraries, and it solves a very specific problem: complex UI rendering. It's also intended to be used along side many other popular libraries. For example, React works well with Backbone.js, amongst many others.
>
> React was born out of frustrations with the common pattern of writing two-way data bindings in complex MVC apps. React is an implementation of one-way data bindings.
>
> [Read the full post...](http://www.quora.com/React-JS-Library/How-is-Facebooks-React-JavaScript-library/answer/Lee-Byron?srid=3DcX)
> [Read the full post...](https://www.quora.com/React-JS-Library/How-is-Facebooks-React-JavaScript-library/answer/Lee-Byron?srid=3DcX)
Since the launch we have received a lot of feedback and are actively working on React 0.4. In the meantime, here are the highlights of this week.
@@ -21,12 +21,12 @@ Since the launch we have received a lot of feedback and are actively working on
## React and Socket.IO Chat Application
[Danial Khosravi](http://danialk.github.io/) made a real-time chat application that interacts with the back-end using Socket.IO.
[Danial Khosravi](https://danialk.github.io/) made a real-time chat application that interacts with the back-end using Socket.IO.
> A week ago I was playing with AngularJS and [this little chat application](https://github.com/btford/angular-socket-io-im) which uses socket.io and nodejs for realtime communication. Yesterday I saw a post about ReactJS in [EchoJS](http://www.echojs.com/) and started playing with this UI library. After playing a bit with React, I decided to write and chat application using React and I used Bran Ford's Backend for server side of this little app.
> [Read the full post...](http://danialk.github.io/blog/2013/06/16/reactjs-and-socket-dot-io-chat-application/)
> [Read the full post...](https://danialk.github.io/blog/2013/06/16/reactjs-and-socket-dot-io-chat-application/)
## React and Other Frameworks
@@ -36,7 +36,7 @@ Since the launch we have received a lot of feedback and are actively working on
>
> We've designed React from the beginning to work well with other libraries. Angular is no exception. Let's take the original Angular example and use React to implement the fundoo-rating directive.
>
> [Read the full post...](http://www.quora.com/Pete-Hunt/Posts/Facebooks-React-vs-AngularJS-A-Closer-Look)
> [Read the full post...](https://www.quora.com/Pete-Hunt/Posts/Facebooks-React-vs-AngularJS-A-Closer-Look)
In the same vein, [Markov Twain](https://twitter.com/markov_twain/status/345702941845499906) re-implemented the examples on the front-page [with Ember](http://jsbin.com/azihiw/2/edit) and [Vlad Yazhbin](https://twitter.com/vla) re-implemented the tutorial [with Angular](http://jsfiddle.net/vla/Cdrse/).
@@ -64,7 +64,7 @@ Mozilla and Google are actively working on Web Components. [Vjeux](http://blog.v
Many of you pointed out differences between JSX and HTML. In order to clear up some confusion, we have added some documentation that covers the four main differences:
We have a ton of great stuff coming in v0.4, but in the meantime we're releasing v0.3.3. This release addresses some small issues people were having and simplifies our tools to make them easier to use.
The highlight of this week is that an interaction-heavy app has been ported to React. React components are solving issues they had with nested views.
## Moving From Backbone To React
[Clay Allsopp](http://twitter.com/clayallsopp) successfully ported [Propeller](http://usepropeller.com/blog/posts/from-backbone-to-react/), a fairly big, interaction-heavy JavaScript app, to React.
[Clay Allsopp](https://twitter.com/clayallsopp) successfully ported [Propeller](http://usepropeller.com/blog/posts/from-backbone-to-react/), a fairly big, interaction-heavy JavaScript app, to React.
> [<img style="float: right; margin: 0 0 10px 10px;" src="/react/img/blog/propeller-logo.png" />](http://usepropeller.com/blog/posts/from-backbone-to-react/)Subviews involve a lot of easy-to-forget boilerplate that Backbone (by design) doesn't automate. Libraries like Backbone.Marionette offer more abstractions to make view nesting easier, but they're all limited by the fact that Backbone delegates how and went view-document attachment occurs to the application code.
>
@@ -19,7 +19,7 @@ The highlight of this week is that an interaction-heavy app has been ported to R
## Grunt Task for JSX
[Eric Clemmons](http://ericclemmons.github.io/) wrote a task for [Grunt](http://gruntjs.com/) that applies the JSX transformation to your Javascript files. It also works with [Browserify](http://browserify.org/) if you want all your files to be concatenated and minified together.
[Eric Clemmons](https://ericclemmons.github.io/) wrote a task for [Grunt](http://gruntjs.com/) that applies the JSX transformation to your Javascript files. It also works with [Browserify](http://browserify.org/) if you want all your files to be concatenated and minified together.
> Grunt task for compiling Facebook React's .jsx templates into .js
React v0.4 is very close to completion. As we finish it off, we'd like to share with you some of the major changes we've made since v0.3. This is the first of several posts we'll be making over the next week.
@@ -8,7 +8,7 @@ React v0.4 is very close to completion. As we finish it off, we'd like to share
## What is React.autoBind?
If you take a look at most of our current examples, you'll see us using `React.autoBind` for event handlers. This is used in place of `Function.prototype.bind`. Remember that in JS, [function calls are late-bound](http://bonsaiden.github.io/JavaScript-Garden/#function.this). That means that if you simply pass a function around, the `this` used inside won't necessarily be the `this` you expect. `Function.prototype.bind` creates a new, properly bound, function so that when called, `this` is exactly what you expect it to be.
If you take a look at most of our current examples, you'll see us using `React.autoBind` for event handlers. This is used in place of `Function.prototype.bind`. Remember that in JS, [function calls are late-bound](https://bonsaiden.github.io/JavaScript-Garden/#function.this). That means that if you simply pass a function around, the `this` used inside won't necessarily be the `this` you expect. `Function.prototype.bind` creates a new, properly bound, function so that when called, `this` is exactly what you expect it to be.
title: "New in React v0.4: Prop Validation and Default Values"
author: Paul O'Shannessy
author: zpao
---
Many of the questions we got following the public launch of React revolved around `props`, specifically that people wanted to do validation and to make sure their components had sensible defaults.
Over the past 2 months we've been taking feedback and working hard to make React even better. We fixed some bugs, made some under-the-hood improvements, and added several features that we think will improve the experience developing with React. Today we're proud to announce the availability of React v0.4!
This release could not have happened without the support of our growing community. Since launch day, the community has contributed blog posts, questions to the [Google Group](http://groups.google.com/group/reactjs), and issues and pull requests on GitHub. We've had contributions ranging from documentation improvements to major changes to React's rendering. We've seen people integrate React into the tools they're using and the products they're building, and we're all very excited to see what our budding community builds next!
This release could not have happened without the support of our growing community. Since launch day, the community has contributed blog posts, questions to the [Google Group](https://groups.google.com/group/reactjs), and issues and pull requests on GitHub. We've had contributions ranging from documentation improvements to major changes to React's rendering. We've seen people integrate React into the tools they're using and the products they're building, and we're all very excited to see what our budding community builds next!
React v0.4 has some big changes. We've also restructured the documentation to better communicate how to use React. We've summarized the changes below and linked to documentation where we think it will be especially useful.
@@ -18,10 +18,10 @@ When you're ready, [go download it](/react/downloads.html)!
* Switch from using `id` attribute to `data-reactid` to track DOM nodes. This allows you to integrate with other JS and CSS libraries more easily.
* Support for more DOM elements and attributes (e.g., `<canvas>`)
* Improved server-side rendering APIs. `React.renderComponentToString(<component>, callback)` allows you to use React on the server and generate markup which can be sent down to the browser.
*`prop` improvements: validation and default values. [Read our blog post for details...](http://facebook.github.io/react/blog/2013/07/11/react-v0-4-prop-validation-and-default-values.html)
* Support for the `key` prop, which allows for finer control over reconciliation. [Read the docs for details...](http://facebook.github.io/react/docs/multiple-components.html)
* Removed `React.autoBind`. [Read our blog post for details...](http://facebook.github.io/react/blog/2013/07/02/react-v0-4-autobind-by-default.html)
* Improvements to forms. We've written wrappers around `<input>`, `<textarea>`, `<option>`, and `<select>` in order to standardize many inconsistencies in browser implementations. This includes support for `defaultValue`, and improved implementation of the `onChange` event, and circuit completion. [Read the docs for details...](http://facebook.github.io/react/docs/forms.html)
*`prop` improvements: validation and default values. [Read our blog post for details...](/react/blog/2013/07/11/react-v0-4-prop-validation-and-default-values.html)
* Support for the `key` prop, which allows for finer control over reconciliation. [Read the docs for details...](/react/docs/multiple-components.html)
* Removed `React.autoBind`. [Read our blog post for details...](/react/blog/2013/07/02/react-v0-4-autobind-by-default.html)
* Improvements to forms. We've written wrappers around `<input>`, `<textarea>`, `<option>`, and `<select>` in order to standardize many inconsistencies in browser implementations. This includes support for `defaultValue`, and improved implementation of the `onChange` event, and circuit completion. [Read the docs for details...](/react/docs/forms.html)
* We've implemented an improved synthetic event system that conforms to the W3C spec.
* Updates to your component are batched now, which may result in a significantly faster re-render of components. `this.setState` now takes an optional callback as its second parameter. If you were using `onClick={this.setState.bind(this, state)}` previously, you'll want to make sure you add a third parameter so that the event is not treated as the callback.
We launched the [React Facebook Page](https://www.facebook.com/react) along with the React v0.4 launch. 700 people already liked it to get updated on the project :)
@@ -52,7 +52,7 @@ Learning a new library is always easier when you have working examples you can p
## React Chosen Wrapper
[Cheng Lou](https://github.com/chenglou) wrote a wrapper for the [Chosen](http://harvesthq.github.io/chosen/) input library called [react-chosen](https://github.com/chenglou/react-chosen). It took just 25 lines to be able to use jQuery component as a React one.
[Cheng Lou](https://github.com/chenglou) wrote a wrapper for the [Chosen](https://harvesthq.github.io/chosen/) input library called [react-chosen](https://github.com/chenglou/react-chosen). It took just 25 lines to be able to use jQuery component as a React one.
```javascript
React.renderComponent(
@@ -60,7 +60,7 @@ React.renderComponent(
<optionvalue="Facebook">Facebook</option>
<optionvalue="Harvest">Harvest</option>
</Chosen>
,document.body);
,document.getElementById('example'));
```
@@ -68,14 +68,14 @@ React.renderComponent(
[Domenic Denicola](http://domenicdenicola.com/) wrote a slide deck about the great applications of ES6 features and one slide shows how we could use Template Strings to compile JSX at run-time without the need for a pre-processing phase.
[Tom Occhino](http://tomocchino.com/) and [Jordan Walke](https://github.com/jordwalke), React developers, did a presentation of React at Facebook Seattle's office. Check out the first 25 minutes for the presentation and the remaining 45 for a Q&A. I highly recommend you watching this video.
React v0.4.1 is a small update, mostly containing correctness fixes. Some code has been restructured internally but those changes do not impact any of our public APIs.
Today we're releasing a gem to make it easier to use React and JSX in Ruby on Rails applications: [react-rails](https://github.com/facebook/react-rails).
@@ -38,7 +38,7 @@ When you name your file with `myfile.js.jsx`, `react-rails` will automatically t
Today we're happy to announce the initial release of [PyReact](https://github.com/facebook/react-python), which makes it easier to use React and JSX in your Python applications. It's designed to provide an API to transform your JSX files into JavaScript, as well as provide access to the latest React source files.
* [15 blog posts](http://facebook.github.io/react/blog/)
* [15 blog posts](/react/blog/)
* 2 early adopters: [Khan Academy](http://benalpert.com/2013/06/09/using-react-to-speed-up-khan-academy.html) and [Propeller](http://usepropeller.com/blog/posts/from-backbone-to-react/)
A lot has happened in the month since our last update. Here are some of the more interesting things we've found. But first, we have a couple updates before we share links.
@@ -66,4 +66,4 @@ While this is not going to work for all the attributes since they are camelCased
[Vjeux](http://blog.vjeux.com/) re-implemented the display part of the IRC logger in React. Just 130 lines are needed for a performant infinite scroll with timestamps and color-coded author names.
This release is the result of several months of hard work from members of the team and the community. While there are no groundbreaking changes in core, we've worked hard to improve performance and memory usage. We've also worked hard to make sure we are being consistent in our usage of DOM properties.
This release focuses on fixing some small bugs that have been uncovered over the past two weeks. I would like to thank everybody involved, specifically members of the community who fixed half of the issues found. Thanks to [Ben Alpert][1], [Andrey Popp][2], and [Laurence Rowe][3] for their contributions!
We organized a React hackathon last week-end in the Facebook Seattle office. 50 people, grouped into 15 teams, came to hack for a day on React. It was a lot of fun and we'll probably organize more in the future.
@@ -29,7 +29,7 @@ We organized a React hackathon last week-end in the Facebook Seattle office. 50
The video will be available soon on the [JSConf EU website](http://2013.jsconf.eu/speakers/pete-hunt-react-rethinking-best-practices.html), but in the meantime, here are Pete's slides:
React is, in my opinion, the premier way to build big, fast Web apps with JavaScript. It has scaled very well for us at Facebook and Instagram.
One of the many great parts of React is how it makes you think about apps as you build them. In this post I'll walk you through the thought process of building a searchable product data table using React.
## Start with a mock
Imagine that we already have a JSON API and a mock from our designer. Our designer apparently isn't very good because the mock looks like this:
## Step 1: break the UI into a component hierarchy
The first thing you'll want to do is to draw boxes around every component (and subcomponent) in the mock and give them all names. If you're working with a designer they may have already done this, so go talk to them! Their Photoshop layer names may end up being the names of your React components!
But how do you know what should be its own component? Just use the same techniques for deciding if you should create a new function or object. One such technique is the [single responsibility principle](http://en.wikipedia.org/wiki/Single_responsibility_principle), that is, a component should ideally only do one thing. If it ends up growing it should be decomposed into smaller subcomponents.
Since you're often displaying a JSON data model to a user, you'll find that if your model was built correctly your UI (and therefore your component structure) will map nicely onto it. That's because user interfaces and data models tend to adhere to the same *information architecture* which means the work of separating your UI into components is often trivial. Just break it up into components that represent exactly one piece of your data model.
You'll see here that we have five components in our simple app. I've italicized the data each component represents.
1.**`FilterableProductTable` (orange):** contains the entirety of the example
2.**`SearchBar` (blue):** receives all *user input*
3.**`ProductTable` (green):** displays and filters the *data collection* based on *user input*
4.**`ProductCategoryRow` (turquoise):** displays a heading for each *category*
5.**`ProductRow` (red):** displays a row for each *product*
If you look at `ProductTable` you'll see that the table header (containing the "Name" and "Price" labels) isn't its own component. This is a matter of preference and there's an argument to be made either way. For this example I left it as part of `ProductTable` because it is part of rendering the *data collection* which is `ProductTable`'s responsibility. However if this header grows to be complex (i.e. if we were to add affordances for sorting) it would certainly make sense to make this its own `ProductTableHeader` component.
Now that we've identified the components in our mock, let's arrange them into a hierarchy. This is easy. Components that appear within another component in the mock should appear as a child in the hierarchy:
Now that you have your component hierarchy it's time to start implementing your app. The easiest way is to build a version that takes your data model and renders the UI but has no interactivity. It's easiest to decouple these processes because building a static version requires a lot of typing and no thinking, and adding interactivity requires a lot of thinking and not a lot of typing. We'll see why.
To build a static version of your app that renders your data model you'll want to build components that reuse other components and pass data using *props*. *props* are a way of passing data from parent to child. If you're familiar with the concept of *state*, **don't use state at all** to build this static version. State is reserved only for interactivity, that is, data that changes over time. Since this is a static version of the app you don't need it.
You can build top-down or bottom-up. That is, you can either start with building the components higher up in the hierarchy (i.e. starting with `FilterableProductTable`) or with the ones lower in it (`ProductRow`). In simpler examples it's usually easier to go top-down and on larger projects it's easier to go bottom-up and write tests as you build.
At the end of this step you'll have a library of reusable components that render your data model. The components will only have `render()` methods since this is a static version of your app. The component at the top of the hierarchy (`FilterableProductTable`) will take your data model as a prop. If you make a change to your underlying data model and call `renderComponent()` again the UI will be updated. It's easy to see how your UI is updated and where to make changes since there's nothing complicated going on since React's **one-way data flow** (also called *one-way binding*) keeps everything modular, easy to reason about, and fast.
Simply refer to the [React docs](http://facebook.github.io/react/docs/) if you need help executing this step.
### A brief interlude: props vs state
There are two types of "model" data in React: props and state. It's important to understand the distinction between the two; skim [the official React docs](http://facebook.github.io/react/docs/interactivity-and-dynamic-uis.html) if you aren't sure what the difference is.
## Step 3: Identify the minimal (but complete) representation of UI state
To make your UI interactive you need to be able to trigger changes to your underlying data model. React makes this easy with **state**.
To build your app correctly you first need to think of the minimal set of mutable state that your app needs. The key here is DRY: *Don't Repeat Yourself*. Figure out what the absolute minimal representation of the state of your application needs to be and compute everything else you need on-demand. For example, if you're building a TODO list, just keep an array of the TODO items around; don't keep a separate state variable for the count. Instead, when you want to render the TODO count simply take the length of the TODO items array.
Think of all of the pieces of data in our example application. We have:
* The original list of products
* The search text the user has entered
* The value of the checkbox
* The filtered list of products
Let's go through each one and figure out which one is state. Simply ask three questions about each piece of data:
1. Is it passed in from a parent via props? If so, it probably isn't state.
2. Does it change over time? If not, it probably isn't state.
3. Can you compute it based on any other state or props in your component? If so, it's not state.
The original list of products is passed in as props, so that's not state. The search text and the checkbox seem to be state since they change over time and can't be computed from anything. And finally, the filtered list of products isn't state because it can be computed by combining the original list of products with the search text and value of the checkbox.
OK, so we've identified what the minimal set of app state is. Next we need to identify which component mutates, or *owns*, this state.
Remember: React is all about one-way data flow down the component hierarchy. It may not be immediately clear which component should own what state. **This is often the most challenging part for newcomers to understand,** so follow these steps to figure it out:
For each piece of state in your application:
* Identify every component that renders something based on that state.
* Find a common owner component (a single component above all the components that need the state in the hierarchy).
* Either the common owner or another component higher up in the hierarchy should own the state.
* If you can't find a component where it makes sense to own the state, create a new component simply for holding the state and add it somewhere in the hierarchy above the common owner component.
Let's run through this strategy for our application:
*`ProductTable` needs to filter the product list based on state and `SearchBar` needs to display the search text and checked state.
* The common owner component is `FilterableProductTable`.
* It conceptually makes sense for the filter text and checked value to live in `FilterableProductTable`
Cool, so we've decided that our state lives in `FilterableProductTable`. First, add a `getInitialState()` method to `FilterableProductTable` that returns `{filterText: '', inStockOnly: false}` to reflect the initial state of your application. Then pass `filterText` and `inStockOnly` to `ProductTable` and `SearchBar` as a prop. Finally, use these props to filter the rows in `ProductTable` and set the values of the form fields in `SearchBar`.
You can start seeing how your application will behave: set `filterText` to `"ball"` and refresh your app. You'll see the data table is updated correctly.
So far we've built an app that renders correctly as a function of props and state flowing down the hierarchy. Now it's time to support data flowing the other way: the form components deep in the hierarchy need to update the state in `FilterableProductTable`.
React makes this data flow explicit to make it easy to understand how your program works, but it does require a little more typing than traditional two-way data binding. React provides an add-on called `ReactLink` to make this pattern as convenient as two-way binding, but for the purpose of this post we'll keep everything explicit.
If you try to type or check the box in the current version of the example you'll see that React ignores your input. This is intentional, as we've set the `value` prop of the `input` to always be equal to the `state` passed in from `FilterableProductTable`.
Let's think about what we want to happen. We want to make sure that whenever the user changes the form we update the state to reflect the user input. Since components should only update their own state, `FilterableProductTable` will pass a callback to `SearchBar` that will fire whenever the state should be updated. We can use the `onChange` event on the inputs to be notified of it. And the callback passed by `FilterableProductTable` will call `setState()` and the app will be updated.
Though this sounds like a lot it's really just a few lines of code. And it's really explicit how your data is flowing throughout the app.
## And that's it
Hopefully this gives you an idea of how to think about building components and applications with React. While it may be a little more typing than you're used to, remember that code is read far more than it's written, and it's extremely easy to read this modular, explicit code. As you start to build large libraries of components you'll appreciate this explicitness and modularity, and with code reuse your lines of code will start to shrink :)
This is the 10th round-up already and React has come quite far since it was open sourced. Almost all new web projects at Khan Academy, Facebook, and Instagram are being developed using React. React has been deployed in a variety of contexts: a Chrome extension, a Windows 8 application, mobile websites, and desktop websites supporting Internet Explorer 8! Language-wise, React is not only being used within JavaScript but also CoffeeScript and ClojureScript.
@@ -26,7 +26,7 @@ The best part is that no drastic changes have been required to support all those
[Pete Hunt](http://www.petehunt.net/)'s talk at JSConf EU 2013 is now available in video.
This round-up is the proof that React has taken off from its Facebook's root: it features three in-depth presentations of React done by external people. This is awesome, keep them coming!
@@ -9,25 +9,25 @@ This round-up is the proof that React has taken off from its Facebook's root: it
[Steve Luscher](https://github.com/steveluscher) working at [LeanPub](https://leanpub.com/) made a 30 min talk at [Super VanJS](https://twitter.com/vanjs). He does a remarkable job at explaining why React is so fast with very exciting demos using the HTML5 Audio API.
[Connor McSheffrey](http://connormcsheffrey.com/) and [Cheng Lou](https://github.com/chenglou) added a new section to the documentation. It's a list of small tips that you will probably find useful while working on React. Since each article is very small and focused, we [encourage you to contribute](http://facebook.github.io/react/tips/introduction.html)!
[Connor McSheffrey](http://connormcsheffrey.com/) and [Cheng Lou](https://github.com/chenglou) added a new section to the documentation. It's a list of small tips that you will probably find useful while working on React. Since each article is very small and focused, we [encourage you to contribute](/react/tips/introduction.html)!
- [Maximum Number of JSX Root Nodes](http://facebook.github.io/react/tips/maximum-number-of-jsx-root-nodes.html)
- [Shorthand for Specifying Pixel Values in style props](http://facebook.github.io/react/tips/style-props-value-px.html)
- [Type of the Children props](http://facebook.github.io/react/tips/children-props-type.html)
- [Value of null for Controlled Input](http://facebook.github.io/react/tips/controlled-input-null-value.html)
- [`componentWillReceiveProps` Not Triggered After Mounting](http://facebook.github.io/react/tips/componentWillReceiveProps-not-triggered-after-mounting.html)
- [Props in getInitialState Is an Anti-Pattern](http://facebook.github.io/react/tips/props-in-getInitialState-as-anti-pattern.html)
- [DOM Event Listeners in a Component](http://facebook.github.io/react/tips/dom-event-listeners.html)
- [Load Initial Data via AJAX](http://facebook.github.io/react/tips/initial-ajax.html)
- [False in JSX](http://facebook.github.io/react/tips/false-in-jsx.html)
- [Inline Styles](/react/tips/inline-styles.html)
- [If-Else in JSX](/react/tips/if-else-in-JSX.html)
- [Maximum Number of JSX Root Nodes](/react/tips/maximum-number-of-jsx-root-nodes.html)
- [Shorthand for Specifying Pixel Values in style props](/react/tips/style-props-value-px.html)
- [Type of the Children props](/react/tips/children-props-type.html)
- [Value of null for Controlled Input](/react/tips/controlled-input-null-value.html)
- [`componentWillReceiveProps` Not Triggered After Mounting](/react/tips/componentWillReceiveProps-not-triggered-after-mounting.html)
- [Props in getInitialState Is an Anti-Pattern](/react/tips/props-in-getInitialState-as-anti-pattern.html)
- [DOM Event Listeners in a Component](/react/tips/dom-event-listeners.html)
- [Load Initial Data via AJAX](/react/tips/initial-ajax.html)
- [False in JSX](/react/tips/false-in-jsx.html)
## Intro to the React Framework
@@ -50,7 +50,7 @@ This round-up is the proof that React has taken off from its Facebook's root: it
## Genesis Skeleton
[Eric Clemmons](http://ericclemmons.github.io/) is working on a "Modern, opinionated, full-stack starter kit for rapid, streamlined application development". The version 0.4.0 has just been released and has first-class support for React.
[Eric Clemmons](https://ericclemmons.github.io/) is working on a "Modern, opinionated, full-stack starter kit for rapid, streamlined application development". The version 0.4.0 has just been released and has first-class support for React.
Today we're releasing an update to address a potential XSS vulnerability that can arise when using user data as a `key`. Typically "safe" data is used for a `key`, for example, an id from your database, or a unique hash. However there are cases where it may be reasonable to use user generated content. A carefully crafted piece of content could result in arbitrary JS execution. While we make a very concerted effort to ensure all text is escaped before inserting it into the DOM, we missed one case. Immediately following the discovery of this vulnerability, we performed an audit to ensure we this was the only such vulnerability.
@@ -15,7 +15,7 @@ While we've encouraged responsible disclosure as part of [Facebook's whitehat bo
You can learn more about the vulnerability discussed here: [CVE-2013-7035][cve].
React got featured on the front-page of Hacker News thanks to the Om library. If you try it out for the first time, take a look at the [docs](/react/docs/getting-started.html) and do not hesitate to ask questions on the [Google Group](http://groups.google.com/group/reactjs), [IRC](irc://chat.freenode.net/reactjs) or [Stack Overflow](http://stackoverflow.com/questions/tagged/reactjs). We are trying our best to help you out!
React got featured on the front-page of Hacker News thanks to the Om library. If you try it out for the first time, take a look at the [docs](/react/docs/getting-started.html) and do not hesitate to ask questions on the [Google Group](https://groups.google.com/group/reactjs), [IRC](irc://chat.freenode.net/reactjs) or [Stack Overflow](http://stackoverflow.com/questions/tagged/reactjs). We are trying our best to help you out!
## The Future of Javascript MVC
[David Nolen](http://swannodette.github.io/) announced Om, a thin wrapper on-top of React in ClojureScript. It stands out by only using immutable data structures. This unlocks the ability to write a very efficient [shouldComponentUpdate](http://facebook.github.io/react/docs/component-specs.html#updating-shouldcomponentupdate) and get huge performance improvements on some tasks.
[David Nolen](https://swannodette.github.io/) announced Om, a thin wrapper on-top of React in ClojureScript. It stands out by only using immutable data structures. This unlocks the ability to write a very efficient [shouldComponentUpdate](/react/docs/component-specs.html#updating-shouldcomponentupdate) and get huge performance improvements on some tasks.
> We've known this for some time over here in the ClojureScript corner of the world - all of our collections are immutable and modeled directly on the original Clojure versions written in Java. Modern JavaScript engines have now been tuned to the point that it's no longer uncommon to see collection performance within 2.5X of the Java Virtual Machine.
>
> Wait, wait, wait. What does the performance of persistent data structures have to do with the future of JavaScript MVCs?
> [Read the full article...](http://swannodette.github.io/2013/12/17/the-future-of-javascript-mvcs/)
> [Read the full article...](https://swannodette.github.io/2013/12/17/the-future-of-javascript-mvcs/)
## Scroll Position with React
Managing the scroll position when new content is inserted is usually very tricky to get right. [Vjeux](http://blog.vjeux.com/) discovered that [componentWillUpdate](http://facebook.github.io/react/docs/component-specs.html#updating-componentwillupdate) and [componentDidUpdate](http://facebook.github.io/react/docs/component-specs.html#updating-componentdidupdate) were triggered exactly at the right time to manage the scroll position.
Managing the scroll position when new content is inserted is usually very tricky to get right. [Vjeux](http://blog.vjeux.com/) discovered that [componentWillUpdate](/react/docs/component-specs.html#updating-componentwillupdate) and [componentDidUpdate](/react/docs/component-specs.html#updating-componentdidupdate) were triggered exactly at the right time to manage the scroll position.
> We can check the scroll position before the component has updated with componentWillUpdate and scroll if necessary at componentDidUpdate
React declarative approach is well suited to write games. [Cheng Lou](https://github.com/chenglou) wrote the famous Lights Out game in React. It's a good example of use of [TransitionGroup](http://facebook.github.io/react/docs/animation.html) to implement animations.
React declarative approach is well suited to write games. [Cheng Lou](https://github.com/chenglou) wrote the famous Lights Out game in React. It's a good example of use of [TransitionGroup](/react/docs/animation.html) to implement animations.
[Try it out!](http://chenglou.github.io/react-lights-out/)
[Try it out!](https://chenglou.github.io/react-lights-out/)
## Reactive Table Bookmarklet
@@ -63,9 +63,7 @@ React declarative approach is well suited to write games. [Cheng Lou](https://gi
[Ross Allen](https://twitter.com/ssorallen) implemented [MontageJS](http://montagejs.org/)'s [Reddit tutorial](http://montagejs.org/docs/tutorial-reddit-client-with-montagejs.html) in React. This is a good opportunity to compare the philosophies of the two libraries.
Happy holidays! This blog post is a little-late Christmas present for all the React users. Hopefully it will inspire you to write awesome web apps in 2014!
@@ -12,14 +12,14 @@ Happy holidays! This blog post is a little-late Christmas present for all the Re
[Try out the demos!](http://petehunt.github.io/react-touch/)
[Try out the demos!](https://petehunt.github.io/react-touch/)
## Introduction to React
[Stoyan Stefanov](http://www.phpied.com/) talked at Joe Dev On Tech about React. He goes over all the features of the library and ends with a concrete example.
With the new year, we thought you'd enjoy some new tools for debugging React code. Today we're releasing the [React Developer Tools](https://chrome.google.com/webstore/detail/react-developer-tools/fmkadmapgofadopljbjfkapdkoienihi), an extension to the Chrome Developer Tools. [Download them from the Chrome Web Store](https://chrome.google.com/webstore/detail/react-developer-tools/fmkadmapgofadopljbjfkapdkoienihi).
You will get a new tab titled "React" in your Chrome DevTools. This tab shows you a list of the root React Components that are rendered on the page as well as the subcomponents that each root renders.
The theme of this first round-up of 2014 is integration. I've tried to assemble a list of articles and projects that use React in various environments.
@@ -28,7 +28,7 @@ React is only one-piece of your web application stack. [Mark Lussier](https://gi
## React Rails Tutorial
[Selem Delul](http://selem.im) bundled the [React Tutorial](http://facebook.github.io/react/docs/tutorial.html) into a rails app. This is a good example on how to get started with a rails project.
[Selem Delul](http://selem.im) bundled the [React Tutorial](/react/docs/tutorial.html) into a rails app. This is a good example on how to get started with a rails project.
[Eldar Djafarov](http://eldar.djafarov.com/) implemented a mixin to link Backbone models to React state and a small abstraction to write two-way binding on-top.
Interest in React seems to have surged ever since David Nolen ([@swannodette](https://twitter.com/swannodette))'s introduction of [Om](https://github.com/swannodette/om) in his post ["The Future of Javascript MVC Frameworks"](http://swannodette.github.io/2013/12/17/the-future-of-javascript-mvcs/).
Interest in React seems to have surged ever since David Nolen ([@swannodette](https://twitter.com/swannodette))'s introduction of [Om](https://github.com/swannodette/om) in his post ["The Future of Javascript MVC Frameworks"](https://swannodette.github.io/2013/12/17/the-future-of-javascript-mvcs/).
In this React Community Round-up, we are taking a closer look at React from a functional programming perspective.
@@ -15,13 +15,13 @@ To start things off, Eric Normand ([@ericnormand](https://twitter.com/ericnorman
> [Read the full post...](http://www.lispcast.com/react-another-level-of-indirection)
## Reagent: Minimalistic React for ClojureScript
Dan Holmsand ([@holmsand](https://twitter.com/holmsand)) created [Reagent](http://holmsand.github.io/reagent/), a simplistic ClojureScript API to React.
Dan Holmsand ([@holmsand](https://twitter.com/holmsand)) created [Reagent](https://holmsand.github.io/reagent/), a simplistic ClojureScript API to React.
> It allows you to define efficient React components using nothing but plain ClojureScript functions and data, that describe your UI using a Hiccup-like syntax.
>
> The goal of Reagent is to make it possible to define arbitrarily complex UIs using just a couple of basic concepts, and to be fast enough by default that you rarely have to care about performance.
>
> [Check it out on Github...](http://holmsand.github.io/reagent/)
> [Check it out on Github...](https://holmsand.github.io/reagent/)
## Functional DOM programming
@@ -34,7 +34,7 @@ React's one-way data-binding naturally lends itself to a functional programming
Pete also explains this in detail at his #MeteorDevShop talk (about 30 Minutes):
David Nolen shows how to leverage immutable data structures to [add global undo](http://swannodette.github.io/2013/12/31/time-travel/) functionality to an app – using just 13 lines of ClojureScript.
David Nolen shows how to leverage immutable data structures to [add global undo](https://swannodette.github.io/2013/12/31/time-travel/) functionality to an app – using just 13 lines of ClojureScript.
There have been many posts recently covering the <i>why</i> and <i>how</i> of React. This week's community round-up includes a collection of recent articles to help you get started with React, along with a few posts that explain some of the inner workings.
@@ -54,7 +54,7 @@ It's great to see the React community expand internationally. [This site](http:/
### Egghead.io video tutorials
Joe Maddalone ([@joemaddalone](https://twitter.com/joemaddalone)) of [egghead.io](https://egghead.io/) created a series of React video tutorials, such as [this](http://www.youtube.com/watch?v=rFvZydtmsxM&feature=youtu.be&a) introduction to React Components. [[part 1](http://www.youtube.com/watch?v=rFvZydtmsxM&feature=youtu.be&a)], [[part 2](http://www.youtube.com/watch?v=5yvFLrt7N8M)]
Joe Maddalone ([@joemaddalone](https://twitter.com/joemaddalone)) of [egghead.io](https://egghead.io/) created a series of React video tutorials, such as [this](http://www.youtube-nocookie.com/watch?v=rFvZydtmsxM&feature=youtu.be&a) introduction to React Components. [[part 1](http://www.youtube-nocookie.com/watch?v=rFvZydtmsxM&feature=youtu.be&a)], [[part 2](http://www.youtube-nocookie.com/watch?v=5yvFLrt7N8M)]
### "React: Finally, a great server/client web stack"
We're almost ready to release React v0.9! We're posting a release candidate so that you can test your apps on it; we'd much prefer to find show-stopping bugs now rather than after we release.
@@ -8,13 +8,13 @@ We're almost ready to release React v0.9! We're posting a release candidate so t
The release candidate is available for download from the CDN:
* **React**
Dev build with warnings: <http://fb.me/react-0.9.0-rc1.js>
Minified build for production: <http://fb.me/react-0.9.0-rc1.min.js>
Dev build with warnings: <https://fb.me/react-0.9.0-rc1.js>
Minified build for production: <https://fb.me/react-0.9.0-rc1.min.js>
***React with Add-Ons**
Dev build with warnings: <http://fb.me/react-with-addons-0.9.0-rc1.js>
Minified build for production: <http://fb.me/react-with-addons-0.9.0-rc1.min.js>
Dev build with warnings: <https://fb.me/react-with-addons-0.9.0-rc1.js>
Minified build for production: <https://fb.me/react-with-addons-0.9.0-rc1.min.js>
***In-Browser JSX transformer**
<http://fb.me/JSXTransformer-0.9.0-rc1.js>
<https://fb.me/JSXTransformer-0.9.0-rc1.js>
We've also published version `0.9.0-rc1` of the `react` and `react-tools` packages on npm and the `react` package on bower.
I'm excited to announce that today we're releasing React v0.9, which incorporates many bug fixes and several new features since the last release. This release contains almost four months of work, including over 800 commits from over 70 committers!
@@ -10,13 +10,13 @@ Thanks to everyone who tested the release candidate; we were able to find and fi
As always, the release is available for download from the CDN:
* **React**
Dev build with warnings: <http://fb.me/react-0.9.0.js>
Minified build for production: <http://fb.me/react-0.9.0.min.js>
Dev build with warnings: <https://fb.me/react-0.9.0.js>
Minified build for production: <https://fb.me/react-0.9.0.min.js>
***React with Add-Ons**
Dev build with warnings: <http://fb.me/react-with-addons-0.9.0.js>
Minified build for production: <http://fb.me/react-with-addons-0.9.0.min.js>
Dev build with warnings: <https://fb.me/react-with-addons-0.9.0.js>
Minified build for production: <https://fb.me/react-with-addons-0.9.0.min.js>
***In-Browser JSX Transformer**
<http://fb.me/JSXTransformer-0.9.0.js>
<https://fb.me/JSXTransformer-0.9.0.js>
We've also published version `0.9.0` of the `react` and `react-tools` packages on npm and the `react` package on bower.
@@ -15,12 +15,12 @@ Large parts of Facebook's web frontend are already powered by React. The recentl
Sberbank, Russia's largest bank, recently switched large parts of their site to use React, as detailed in [this post by Vyacheslav Slinko](https://groups.google.com/forum/#!topic/reactjs/Kj6WATX0atg).
### Relato
[Relato](http://bripkens.github.io/relato/) by [Ben Ripkens](https://github.com/bripkens) shows Open Source Statistics based on npm data. It features a filterable and sortable table built in React. Check it out – it's super fast!
[Relato](https://bripkens.github.io/relato/) by [Ben Ripkens](https://github.com/bripkens) shows Open Source Statistics based on npm data. It features a filterable and sortable table built in React. Check it out – it's super fast!
### Makona Editor
John Lynch ([@johnrlynch](https://twitter.com/johnrlynch)) created Makona, a block-style document editor for the web. Blocks of different content types comprise documents, authored using plain markup. At the switch of a toggle, block contents are then rendered on the page. While not quite a WYSIWYG editor, Makona uses plain textareas for input. This makes it compatible with a wider range of platforms than traditional rich text editors.
React is in no way limited to just web pages. Brandon Tilley ([@BinaryMuse](https://twitter.com/BinaryMuse)) just released a detailed walk-through of [how he built his Chrome extension "Fast Tab Switcher" using React](http://brandontilley.com/2014/02/24/creating-chrome-extensions-with-react.html).
@@ -40,12 +40,12 @@ Javier Aguirre ([@javaguirre](https://twitter.com/javaguirre)) put together a si
### SVG-based graphical node editor
[NoFlo](http://noflojs.org/) and [Meemoo](http://meemoo.org/) developer [Forresto Oliphant](http://www.forresto.com/) built an awesome SVG-based [node editor](http://forresto.github.io/prototyping/react/) in React.
[NoFlo](http://noflojs.org/) and [Meemoo](http://meemoo.org/) developer [Forresto Oliphant](http://www.forresto.com/) built an awesome SVG-based [node editor](https://forresto.github.io/prototyping/react/) in React.
Rafał Cieślak ([@Ravicious](https://twitter.com/Ravicious)) wrote a [React version](http://ravicious.github.io/ultimate-ttt/) of [Ultimate Tic Tac Toe](http://mathwithbaddrawings.com/2013/06/16/ultimate-tic-tac-toe/). Find the source [here](https://github.com/ravicious/ultimate-ttt).
Rafał Cieślak ([@Ravicious](https://twitter.com/Ravicious)) wrote a [React version](https://ravicious.github.io/ultimate-ttt/) of [Ultimate Tic Tac Toe](http://mathwithbaddrawings.com/2013/06/16/ultimate-tic-tac-toe/). Find the source [here](https://github.com/ravicious/ultimate-ttt).
@@ -55,7 +55,7 @@ Rafał Cieślak ([@Ravicious](https://twitter.com/Ravicious)) wrote a [React ver
@@ -63,7 +63,7 @@ Emanuele shared this awesome demo video with us:
### Table Sorter
[Table Sorter](http://bgerm.github.io/react-table-sorter-demo/) by [bgerm](https://github.com/bgerm) [[source](https://github.com/bgerm/react-table-sorter-demo)] is another helpful React component.
[Table Sorter](https://bgerm.github.io/react-table-sorter-demo/) by [bgerm](https://github.com/bgerm) [[source](https://github.com/bgerm/react-table-sorter-demo)] is another helpful React component.
### Static-search
@@ -83,7 +83,7 @@ Dmitry Chestnykh [@dchest](https://twitter.com/dchest) wrote a [static search in
## React server rendering
Ever wonder how to pre-render React components on the server? [react-server-example](https://github.com/mhart/react-server-example) by Michael Hart ([@hichaelmart](http://twitter.com/hichaelmart)) walks through the necessary steps.
Ever wonder how to pre-render React components on the server? [react-server-example](https://github.com/mhart/react-server-example) by Michael Hart ([@hichaelmart](https://twitter.com/hichaelmart)) walks through the necessary steps.
Similarly, Alan deLevie ([@adelevie](https://twitter.com/adelevie)) created [react-client-server-starter](https://github.com/adelevie/react-client-server-starter), another detailed walk-through of how to server-render your app.
In this Round-up, we are taking a few closer looks at React's interplay with different frameworks and architectures.
@@ -41,7 +41,7 @@ Thomas Boyt ([@thomasaboyt](https://twitter.com/thomasaboyt)) wrote [this detail
## React vs. Ember
Eric Berry ([@coderberry](https://twitter.com/coderberry)) developed Ember equivalents for some of the official React examples. Read his post for a side-by-side comparison of the respective implementations: ["Facebook React vs. Ember"](http://instructure.github.io/blog/2013/12/17/facebook-react-vs-ember/).
Eric Berry ([@coderberry](https://twitter.com/coderberry)) developed Ember equivalents for some of the official React examples. Read his post for a side-by-side comparison of the respective implementations: ["Facebook React vs. Ember"](https://instructure.github.io/blog/2013/12/17/facebook-react-vs-ember/).
## React and plain old HTML
@@ -75,7 +75,7 @@ Ian Bicking ([@ianbicking](https://twitter.com/ianbicking)) of Mozilla Labs [exp
React was also recently mentioned at ng-conf, where the Angular team commented on React's concept of the virtual DOM:
[v0.9 has only been out for a month](http://facebook.github.io/react/blog/2014/02/20/react-v0.9.html), but we’re getting ready to push out v0.10 already. Unlike v0.9 which took a long time, we don't have a long list of changes to talk about.
[v0.9 has only been out for a month](/react/blog/2014/02/20/react-v0.9.html), but we’re getting ready to push out v0.10 already. Unlike v0.9 which took a long time, we don't have a long list of changes to talk about.
The release candidate is available for download from the CDN:
* **React**
Dev build with warnings: <http://fb.me/react-0.10.0-rc1.js>
Minified build for production: <http://fb.me/react-0.10.0-rc1.min.js>
Dev build with warnings: <https://fb.me/react-0.10.0-rc1.js>
Minified build for production: <https://fb.me/react-0.10.0-rc1.min.js>
***React with Add-Ons**
Dev build with warnings: <http://fb.me/react-with-addons-0.10.0-rc1.js>
Minified build for production: <http://fb.me/react-with-addons-0.10.0-rc1.min.js>
Dev build with warnings: <https://fb.me/react-with-addons-0.10.0-rc1.js>
Minified build for production: <https://fb.me/react-with-addons-0.10.0-rc1.min.js>
***In-Browser JSX transformer**
<http://fb.me/JSXTransformer-0.10.0-rc1.js>
<https://fb.me/JSXTransformer-0.10.0-rc1.js>
We've also published version `0.10.0-rc1` of the `react` and `react-tools` packages on npm and the `react` package on bower.
@@ -24,7 +24,7 @@ Please try these builds out and [file an issue on GitHub](https://github.com/fac
The main purpose of this release is to provide a smooth upgrade path as we evolve some of the implementation of core. In v0.9 we started warning in cases where you called methods on unmounted components. This is part of an effort to enforce the idea that the return value of a component (`React.DOM.div()`, `MyComponent()`) is in fact not a reference to the component instance React uses in the virtual DOM. The return value is instead a light-weight object that React knows how to use. Since the return value currently is a reference to the same object React uses internally, we need to make this transition in stages as many people have come to depend on this implementation detail.
In 0.10, we’re adding more warnings to catch a similar set of patterns. When a component is mounted we clone it and use that object for our internal representation. This allows us to capture calls you think you’re making to a mounted component. We’ll forward them on to the right object, but also warn you that this is breaking. See “Access to the Mounted Instance” on [this page](http://fb.me/react-warning-descriptors). Most of the time you can solve your pattern by using refs.
In 0.10, we’re adding more warnings to catch a similar set of patterns. When a component is mounted we clone it and use that object for our internal representation. This allows us to capture calls you think you’re making to a mounted component. We’ll forward them on to the right object, but also warn you that this is breaking. See “Access to the Mounted Instance” on [this page](https://fb.me/react-warning-descriptors). Most of the time you can solve your pattern by using refs.
Storing a reference to your top level component is a pattern touched upon on that page, but another examples that demonstrates what we see a lot of:
Hot on the heels of the [release candidate earlier this week](/react/blog/2014/03/19/react-v0.10-rc1.html), we're ready to call v0.10 done. The only major issue we discovered had to do with the `react-tools` package, which has been updated. We've copied over the changelog from the RC with some small clarifying changes.
@@ -8,13 +8,13 @@ Hot on the heels of the [release candidate earlier this week](/react/blog/2014/0
The release is available for download from the CDN:
* **React**
Dev build with warnings: <http://fb.me/react-0.10.0.js>
Minified build for production: <http://fb.me/react-0.10.0.min.js>
Dev build with warnings: <https://fb.me/react-0.10.0.js>
Minified build for production: <https://fb.me/react-0.10.0.min.js>
***React with Add-Ons**
Dev build with warnings: <http://fb.me/react-with-addons-0.10.0.js>
Minified build for production: <http://fb.me/react-with-addons-0.10.0.min.js>
Dev build with warnings: <https://fb.me/react-with-addons-0.10.0.js>
Minified build for production: <https://fb.me/react-with-addons-0.10.0.min.js>
***In-Browser JSX transformer**
<http://fb.me/JSXTransformer-0.10.0.js>
<https://fb.me/JSXTransformer-0.10.0.js>
We've also published version `0.10.0` of the `react` and `react-tools` packages on npm and the `react` package on bower.
@@ -24,7 +24,7 @@ Please try these builds out and [file an issue on GitHub](https://github.com/fac
The main purpose of this release is to provide a smooth upgrade path as we evolve some of the implementation of core. In v0.9 we started warning in cases where you called methods on unmounted components. This is part of an effort to enforce the idea that the return value of a component (`React.DOM.div()`, `MyComponent()`) is in fact not a reference to the component instance React uses in the virtual DOM. The return value is instead a light-weight object that React knows how to use. Since the return value currently is a reference to the same object React uses internally, we need to make this transition in stages as many people have come to depend on this implementation detail.
In 0.10, we’re adding more warnings to catch a similar set of patterns. When a component is mounted we clone it and use that object for our internal representation. This allows us to capture calls you think you’re making to a mounted component. We’ll forward them on to the right object, but also warn you that this is breaking. See “Access to the Mounted Instance” on [this page](http://fb.me/react-warning-descriptors). Most of the time you can solve your pattern by using refs.
In 0.10, we’re adding more warnings to catch a similar set of patterns. When a component is mounted we clone it and use that object for our internal representation. This allows us to capture calls you think you’re making to a mounted component. We’ll forward them on to the right object, but also warn you that this is breaking. See “Access to the Mounted Instance” on [this page](https://fb.me/react-warning-descriptors). Most of the time you can solve your pattern by using refs.
Storing a reference to your top level component is a pattern touched upon on that page, but another examples that demonstrates what we see a lot of:
When we launched React last spring, we purposefully decided not to call it 1.0. It was production ready, but we had plans to evolve APIs and behavior as we saw how people were using React, both internally and externally. We've learned a lot over the past 9 months and we've thought a lot about what 1.0 will mean for React. A couple weeks ago, I outlined [several projects][projects] that we have planned to take us to 1.0 and beyond. Today I'm writing a bit more about them to give our users a better insight into our plans.
@@ -33,7 +33,7 @@ There are other features of ES6 we're already using in core. I'm sure we'll see
## Context
While we haven't documented `context`, it exists in some form in React already. It exists as a way to pass values through a tree without having to use props at every single point. We've seen this need crop up time and time again, so we want to make this as easy as possible. It's use has performance tradeoffs, and there are known weaknesses in our implementation, so we want to make sure this is a solid feature.
While we haven't documented `context`, it exists in some form in React already. It exists as a way to pass values through a tree without having to use props at every single point. We've seen this need crop up time and time again, so we want to make this as easy as possible. Its use has performance tradeoffs, and there are known weaknesses in our implementation, so we want to make sure this is a solid feature.
## Addons
@@ -51,6 +51,6 @@ Finding a way to define animations in a declarative way is a hard problem. We've
There are several other things I listed on [our projects page][projects] that we're tracking. Some of them are internals and have no obvious outward effect (improve tests, repo separation, updated test runner). I encourage you to take a look.
To summarize, Flux works well for us because the single directional data flow makes it easy to understand and modify an application as it becomes more complicated. We found that two-way data bindings lead to cascading updates, where changing one data model led to another data model updating, making it very difficult to predict what would change as the result of a single user interaction.
@@ -13,4 +13,4 @@ In Flux, the Dispatcher is a singleton that directs the flow of data and ensures
When a user interacts with a React view, the view sends an action (usually represented as a JavaScript object with some fields) through the dispatcher, which notifies the various stores that hold the application's data and business logic. When the stores change state, they notify the views that something has updated. This works especially well with React's declarative model, which allows the stores to send updates without specifying how to transition views between states.
Flux is more of a pattern than a formal framework, so you can start using Flux immediately without a lot of new code. An [example of this architecture](https://github.com/facebook/flux/tree/master/examples/flux-todomvc) is available, along with more [detailed documentation](http://facebook.github.io/flux/docs/overview.html) and a [tutorial](http://facebook.github.io/flux/docs/todo-list.html). Look for more examples to come in the future.
Flux is more of a pattern than a formal framework, so you can start using Flux immediately without a lot of new code. An [example of this architecture](https://github.com/facebook/flux/tree/master/examples/flux-todomvc) is available, along with more [detailed documentation](https://facebook.github.io/flux/docs/overview.html) and a [tutorial](https://facebook.github.io/flux/docs/todo-list.html). Look for more examples to come in the future.
Today marks the one-year open-source anniversary of React.
It’s been a crazy ride. 2.3k commits and 1.5k issues and pull requests later, we’re approaching version 1.0 and nearing 7k Github stars, with big names such as Khan Academy, New York Times, and Airbnb (and naturally, Facebook and Instagram) using React in production, and many more developers blogging their success stories with it. The [roadmap](http://facebook.github.io/react/blog/2014/03/28/the-road-to-1.0.html) gives a glimpse into the future of the library; exciting stuff lies ahead!
It’s been a crazy ride. 2.3k commits and 1.5k issues and pull requests later, we’re approaching version 1.0 and nearing 7k Github stars, with big names such as Khan Academy, New York Times, and Airbnb (and naturally, Facebook and Instagram) using React in production, and many more developers blogging their success stories with it. The [roadmap](/react/blog/2014/03/28/the-road-to-1.0.html) gives a glimpse into the future of the library; exciting stuff lies ahead!
Every success has its story. React was born out of our frustration at existing solutions for building UIs. When it was first suggested at Facebook, few people thought that functionally re-rendering everything and diffing the results could ever perform well. However, support grew after we built the first implementation and people wrote their first components. When we open-sourced React, the initial reception was [similarly skeptical](http://www.reddit.com/r/programming/comments/1fak87/react_facebooks_latest_javascript_client_library/). It challenges many pre-established conventions and received mostly disapproving first-impressions, intermingled with positive ones that often were votes of confidence in Facebook’s engineering capabilities. On an open, competitive platform such as the web, it's been hard to convince people to try React. [JSX](http://facebook.github.io/react/docs/jsx-in-depth.html), in particular, filtered out a huge chunk of potential early adopters.
Every success has its story. React was born out of our frustration at existing solutions for building UIs. When it was first suggested at Facebook, few people thought that functionally re-rendering everything and diffing the results could ever perform well. However, support grew after we built the first implementation and people wrote their first components. When we open-sourced React, the initial reception was [similarly skeptical](https://www.reddit.com/r/programming/comments/1fak87/react_facebooks_latest_javascript_client_library/). It challenges many pre-established conventions and received mostly disapproving first-impressions, intermingled with positive ones that often were votes of confidence in Facebook’s engineering capabilities. On an open, competitive platform such as the web, it's been hard to convince people to try React. [JSX](/react/docs/jsx-in-depth.html), in particular, filtered out a huge chunk of potential early adopters.
Fast forward one year, React has strongly [grown in popularity](https://news.ycombinator.com/item?id=7489959). Special acknowledgments go to Khan Academy, the ClojureScript community, and established frameworks such as Ember and Angular for contributing to and debating on our work. We'd also like to thank all the [individual contributors](https://github.com/facebook/react/graphs/contributors) who have taken the time to help out over the past year. React, as a library and as a new paradigm on the web, wouldn't have gained as much traction without them. In the future, we will continue to try to set an example of what's possible to achieve when we rethink about current “best practices”.
@@ -13,7 +13,7 @@ In case you haven't seen it, we've consolidated the tooling solution around Reac
- [Ryan Florence](https://github.com/rpflorence) and [Michael Jackson](https://github.com/mjackson)'s [react-nested-router](https://github.com/rpflorence/react-nested-router), which is a translation of the Ember router API to React.
- [Stephen J. Collings](https://github.com/stevoland)'s [react-bootstrap](https://github.com/react-bootstrap/react-bootstrap), which wraps the popular framework with a bit of React goodness. The [website](http://react-bootstrap.github.io/components.html) features live-editable demos.
- [Stephen J. Collings](https://github.com/stevoland)'s [react-bootstrap](https://github.com/react-bootstrap/react-bootstrap), which wraps the popular framework with a bit of React goodness. The [website](https://react-bootstrap.github.io/components.html) features live-editable demos.
- [Andrey Popp](https://github.com/andreypopp)'s [react-quickstart](https://github.com/andreypopp/react-quickstart), which gives you a quick template for server-side rendering and routing, among other features.
@@ -23,7 +23,7 @@ These are some of the links that often pop up on the #reactjs IRC channel. If yo
The core concepts React themselves is something very valuable that the community is exploring and pushing further. A year ago, we wouldn't have imagined something like [Bruce Hauman](http://rigsomelight.com)'s [Flappy Bird ClojureScript port](http://rigsomelight.com/2014/05/01/interactive-programming-flappy-bird-clojurescript.html), whose interactive programming has been made possible through React:
And don't forget [Pete Hunt](https://github.com/petehunt)'s Wolfenstein 3D rendering engine in React ([source code](https://github.com/petehunt/wolfenstein3D-react/blob/master/js/renderer.js#L183)). While it's nearly a year old, it's still a nice demo.
It's that time again… we're just about ready to ship a new React release! v0.11 includes a wide array of bug fixes and features. We highlighted some of the most important changes below, along with the full changelog.
@@ -8,13 +8,13 @@ It's that time again… we're just about ready to ship a new React release! v0.1
The release candidate is available for download from the CDN:
* **React**
Dev build with warnings: <http://fb.me/react-0.11.0-rc1.js>
Minified build for production: <http://fb.me/react-0.11.0-rc1.min.js>
Dev build with warnings: <https://fb.me/react-0.11.0-rc1.js>
Minified build for production: <https://fb.me/react-0.11.0-rc1.min.js>
***React with Add-Ons**
Dev build with warnings: <http://fb.me/react-with-addons-0.11.0-rc1.js>
Minified build for production: <http://fb.me/react-with-addons-0.11.0-rc1.min.js>
Dev build with warnings: <https://fb.me/react-with-addons-0.11.0-rc1.js>
Minified build for production: <https://fb.me/react-with-addons-0.11.0-rc1.min.js>
***In-Browser JSX transformer**
<http://fb.me/JSXTransformer-0.11.0-rc1.js>
<https://fb.me/JSXTransformer-0.11.0-rc1.js>
We've also published version `0.11.0-rc1` of the `react` and `react-tools` packages on npm and the `react` package on bower.
**Update:** We missed a few important changes in our initial post and changelog. We've updated this post with details about [Descriptors](#descriptors) and [Prop Type Validation](#prop-type-validation).
@@ -15,13 +15,13 @@ This version has been cooking for a couple months now and includes a wide array
The release is available for download from the CDN:
* **React**
Dev build with warnings: <http://fb.me/react-0.11.0.js>
Minified build for production: <http://fb.me/react-0.11.0.min.js>
Dev build with warnings: <https://fb.me/react-0.11.0.js>
Minified build for production: <https://fb.me/react-0.11.0.min.js>
***React with Add-Ons**
Dev build with warnings: <http://fb.me/react-with-addons-0.11.0.js>
Minified build for production: <http://fb.me/react-with-addons-0.11.0.min.js>
Dev build with warnings: <https://fb.me/react-with-addons-0.11.0.js>
Minified build for production: <https://fb.me/react-with-addons-0.11.0.min.js>
***In-Browser JSX transformer**
<http://fb.me/JSXTransformer-0.11.0.js>
<https://fb.me/JSXTransformer-0.11.0.js>
We've also published version `0.11.0` of the `react` and `react-tools` packages on npm and the `react` package on bower.
@@ -100,7 +100,7 @@ Keyboard and mouse events also now include a normalized `e.getModifierState()` t
## Descriptors
In our [v0.10 release notes](http://facebook.github.io/react/blog/2014/03/21/react-v0.10.html#clone-on-mount), we called out that we were deprecating the existing behavior of the component function call (eg `component = MyComponent(props, ...children)` or `component = <MyComponent prop={...}/>`). Previously that would create an instance and React would modify that internally. You could store that reference and then call functions on it (eg `component.setProps(...)`). This no longer works. `component` in the above examples will be a descriptor and not an instance that can be operated on. The v0.10 release notes provide a complete example along with a migration path. The development builds also provided warnings if you called functions on descriptors.
In our [v0.10 release notes](/react/blog/2014/03/21/react-v0.10.html#clone-on-mount), we called out that we were deprecating the existing behavior of the component function call (eg `component = MyComponent(props, ...children)` or `component = <MyComponent prop={...}/>`). Previously that would create an instance and React would modify that internally. You could store that reference and then call functions on it (eg `component.setProps(...)`). This no longer works. `component` in the above examples will be a descriptor and not an instance that can be operated on. The v0.10 release notes provide a complete example along with a migration path. The development builds also provided warnings if you called functions on descriptors.
Along with this change to descriptors, `React.isValidComponent` and `React.PropTypes.component` now actually validate that the value is a descriptor. Overwhelmingly, these functions are used to validate the value of `MyComponent()`, which as mentioned is now a descriptor, not a component instance. We opted to reduce code churn and make the migration to 0.11 as easy as possible. However, we realize this is has caused some confusion and we're working to make sure we are consistent with our terminology.
It's an exciting time for React as there are now more commits from open source contributors than from Facebook engineers! Keep up the good work :)
@@ -9,19 +9,19 @@ It's an exciting time for React as there are now more commits from open source c
[Atom, GitHub's code editor, is now using React](http://blog.atom.io/2014/07/02/moving-atom-to-react.html) to build the editing experience. They made the move in order to improve performance. By default, React helped them eliminate unnecessary reflows, enabling them to focus on architecting the rendering pipeline in order to minimize repaints by using hardware acceleration. This is a testament to the fact that React's architecture is perfect for high performant applications.
At the last [JSConf.us](http://2014.jsconf.us/), Vjeux talked about the design decisions made in the API that allows it to scale to a large number of developers. If you don't have 20 minutes, take a look at the [annotated slides](https://speakerdeck.com/vjeux/why-does-react-scale-jsconf-2014).
One of the best features of React is that it provides the foundations to implement concepts that were otherwise extremely difficult, like server-side rendering, undo-redo, rendering to non-DOM environments like canvas... [Dan Abramov](https://twitter.com/dan_abramov) got hot code reloading working with webpack in order to [live edit a React project](http://gaearon.github.io/react-hot-loader/)!
One of the best features of React is that it provides the foundations to implement concepts that were otherwise extremely difficult, like server-side rendering, undo-redo, rendering to non-DOM environments like canvas... [Dan Abramov](https://twitter.com/dan_abramov) got hot code reloading working with webpack in order to [live edit a React project](https://gaearon.github.io/react-hot-loader/)!
In related news, the next [React SF Meetup](http://www.meetup.com/ReactJS-San-Francisco/events/195518392/) will be from Prezi: [“Immediate Mode on the Web: How We Implemented the Prezi Viewer in JavaScript”](https://medium.com/prezi-engineering/how-and-why-prezi-turned-to-javascript-56e0ca57d135). While not in React, their tech is really awesome and shares a lot of React's design principles and perf optimizations.
@@ -112,4 +112,3 @@ var Foo = React.createClass({
## Random Tweet
<blockquote class="twitter-tweet" data-conversation="none" lang="en"><p>“<a href="https://twitter.com/apphacker">@apphacker</a>: I take back the mean things I said about <a href="https://twitter.com/reactjs">@reactjs</a> I actually like it.” Summarizing the life of ReactJS in a single tweet.</p>— Jordan (@jordwalke) <a href="https://twitter.com/jordwalke/statuses/490747339607265280">July 20, 2014</a></blockquote>
Flux is the application architecture Facebook uses to build JavaScript applications. It's based on a unidirectional data flow. We've built everything from small widgets to huge applications with Flux, and it's handled everything we've thrown at it. Because we've found it to be a great way to structure our code, we're excited to share it with the open source community. [Jing Chen presented Flux](http://youtu.be/nYkdrAPrdcw?t=10m20s) at the F8 conference, and since that time we've seen a lot of interest in it. We've also published an [overview of Flux](http://facebook.github.io/flux/docs/overview.html) and a [TodoMVC example](https://github.com/facebook/flux/tree/master/examples/flux-todomvc/), with an accompanying [tutorial](http://facebook.github.io/flux/docs/todo-list.html).
Flux is the application architecture Facebook uses to build JavaScript applications. It's based on a unidirectional data flow. We've built everything from small widgets to huge applications with Flux, and it's handled everything we've thrown at it. Because we've found it to be a great way to structure our code, we're excited to share it with the open source community. [Jing Chen presented Flux](http://youtu.be/nYkdrAPrdcw?t=10m20s) at the F8 conference, and since that time we've seen a lot of interest in it. We've also published an [overview of Flux](https://facebook.github.io/flux/docs/overview.html) and a [TodoMVC example](https://github.com/facebook/flux/tree/master/examples/flux-todomvc/), with an accompanying [tutorial](https://facebook.github.io/flux/docs/todo-list.html).
Flux is more of a pattern than a full-blown framework, and you can start using it without a lot of new code beyond React. Up until recently, however, we haven't released one crucial piece of our Flux software: the dispatcher. But along with the creation of the new [Flux code repository](https://github.com/facebook/flux) and [Flux website](http://facebook.github.io/flux/), we've now open sourced the same [dispatcher](http://facebook.github.io/flux/docs/dispatcher.html) we use in our production applications.
Flux is more of a pattern than a full-blown framework, and you can start using it without a lot of new code beyond React. Up until recently, however, we haven't released one crucial piece of our Flux software: the dispatcher. But along with the creation of the new [Flux code repository](https://github.com/facebook/flux) and [Flux website](https://facebook.github.io/flux/), we've now open sourced the same [dispatcher](https://facebook.github.io/flux/docs/dispatcher.html) we use in our production applications.
Where the Dispatcher Fits in the Flux Data Flow
@@ -21,7 +21,7 @@ When new data enters the system, whether through a person interacting with the a
Different actions are identified by a type attribute. When all of the stores receive the action, they typically use this attribute to determine if and how they should respond to it. In a Flux application, both stores and views control themselves; they are not acted upon by external objects. Actions flow into the stores through the callbacks they define and register, not through setter methods.
Letting the stores update themselves eliminates many entanglements typically found in MVC applications, where cascading updates between models can lead to unstable state and make accurate testing very difficult. The objects within a Flux application are highly decoupled, and adhere very strongly to the [Law of Demeter](http://en.wikipedia.org/wiki/Law_of_Demeter), the principle that each object within a system should know as little as possible about the other objects in the system. This results in software that is more maintainable, adaptable, testable, and easier for new engineering team members to understand.
Letting the stores update themselves eliminates many entanglements typically found in MVC applications, where cascading updates between models can lead to unstable state and make accurate testing very difficult. The objects within a Flux application are highly decoupled, and adhere very strongly to the [Law of Demeter](https://en.wikipedia.org/wiki/Law_of_Demeter), the principle that each object within a system should know as little as possible about the other objects in the system. This results in software that is more maintainable, adaptable, testable, and easier for new engineering team members to understand.
[Ryan Florence](http://ryanflorence.com/) and [Michael Jackson](http://twitter.com/mjackson) ported Ember's router to React in a project called [React Router](https://github.com/rackt/react-router). This is a very good example of both communities working together to make the web better!
[Ryan Florence](http://ryanflorence.com/) and [Michael Jackson](https://twitter.com/mjackson) ported Ember's router to React in a project called [React Router](https://github.com/rackt/react-router). This is a very good example of both communities working together to make the web better!
```javascript
React.renderComponent((
@@ -16,7 +16,7 @@ React.renderComponent((
</Route>
</Route>
</Routes>
),document.body);
),document.getElementById('example'));
```
## Going Big with React
@@ -49,7 +49,7 @@ Areeb Malik, from Facebook, talks about his experience using React. "On paper, a
## Referencing Dynamic Children
While Matt Zabriskie was working on [react-tabs](https://www.npmjs.org/package/react-tabs) he discovered how to use React.Children.map and React.addons.cloneWithProps in order to [reference dynamic children](http://www.mattzabriskie.com/blog/react-referencing-dynamic-children).
While Matt Zabriskie was working on [react-tabs](https://www.npmjs.com/package/react-tabs) he discovered how to use React.Children.map and React.addons.cloneWithProps in order to [reference dynamic children](http://www.mattzabriskie.com/blog/react-referencing-dynamic-children).
```javascript
varApp=React.createClass({
@@ -83,12 +83,12 @@ Have you ever wondered how JSX was implemented? James Long wrote a very instruct
[Matt Zabriskie](https://github.com/mzabriskie) released a [project](https://github.com/mzabriskie/react-draggable) to make your react components draggable.
[Jason Brown](http://browniefed.github.io/) adapted htmlparser2 to React: [htmlparser2-react](https://www.npmjs.org/package/htmlparser2-react). That allows you to convert raw HTML to the virtual DOM.
[Jason Brown](https://browniefed.github.io/) adapted htmlparser2 to React: [htmlparser2-react](https://www.npmjs.com/package/htmlparser2-react). That allows you to convert raw HTML to the virtual DOM.
This is not the intended way to use React but can be useful as last resort if you have an existing piece of HTML.
```javascript
@@ -104,7 +104,7 @@ var parsedComponent = reactParser(html, React);
If you haven't yet tried out React, Jacob Rios did a Hangout where he covers the most important aspects and thankfully he recorded it!
At Facebook we've been using JSX for a long time. We originally introduced it to the world last year alongside React, but we actually used it in another form before that to create native DOM nodes. We've also seen some similar efforts grow out of our work in order to be used with other libraries and in interesting ways. At this point React JSX is just one of many implementations.
In order to make it easier to implement new versions and to make sure that the syntax remains compatible, we're now formalizing the syntax of JSX in a stand-alone spec without any semantic meaning. It's completely stand-alone from React itself.
Read the spec now at <http://facebook.github.io/jsx/>.
Read the spec now at <https://facebook.github.io/jsx/>.
This is not a proposal to be standardized in ECMAScript. It's just a reference document that transpiler writers and syntax highlighters can agree on. It's currently in a draft stage and will probably continue to be a living document.
This has been an exciting summer as four big companies: Yahoo, Mozilla, Airbnb and Reddit announced that they were using React!
@@ -20,7 +20,7 @@ This has been an exciting summer as four big companies: Yahoo, Mozilla, Airbnb a
[Vjeux](http://blog.vjeux.com/), from the React team, gave a talk at OSCON on the history of React and the various optimizations strategies that are implemented. You can also check out the [annotated slides](https://speakerdeck.com/vjeux/oscon-react-architecture) or [Chris Dawson](http://thenewstack.io/author/chrisdawson/)'s notes titled [JavaScript’s History and How it Led To React](http://thenewstack.io/javascripts-history-and-how-it-led-to-reactjs/).
@@ -30,7 +30,7 @@ Jakob Kummerow landed [two optimizations to V8](http://www.chromium.org/develope
## Reusable Components by Khan Academy
[Khan Academy](https://www.khanacademy.org/) released [many high quality standalone components](http://khan.github.io/react-components/) they are using. This is a good opportunity to see what React code used in production look like.
[Khan Academy](https://www.khanacademy.org/) released [many high quality standalone components](https://khan.github.io/react-components/) they are using. This is a good opportunity to see what React code used in production look like.
```javascript
varTeX=require('react-components/js/tex.jsx');
@@ -89,7 +89,7 @@ var Button = React.createClass({
If you are getting started with React, [Joe Maddalone](http://www.joemaddalone.com/) made a good tutorial on how to build your first component.
[Flux](http://facebook.github.io/flux/) is the application architecture that Facebook uses to build web applications with [React](http://facebook.github.io/react/). It's based on a unidirectional data flow. In previous blog posts and documentation articles, we've shown the [basic structure and data flow](http://facebook.github.io/flux/docs/overview.html), more closely examined the [dispatcher and action creators](http://facebook.github.io/react/blog/2014/07/30/flux-actions-and-the-dispatcher.html), and shown how to put it all together with a [tutorial](http://facebook.github.io/flux/docs/todo-list.html). Now let's look at how to do formal unit testing of Fluxapplications with [Jest](http://facebook.github.io/jest/), Facebook's auto-mocking testing framework.
**A more up-to-date version of this post is available as part of the [Flux documentation](https://facebook.github.io/flux/docs/testing-flux-applications.html).**
[Flux](https://facebook.github.io/flux/) is the application architecture that Facebook uses to build web applications with [React](/react/). It's based on a unidirectional data flow. In previous blog posts and documentation articles, we've shown the [basic structure and data flow](https://facebook.github.io/flux/docs/overview.html), more closely examined the [dispatcher and action creators](/react/blog/2014/07/30/flux-actions-and-the-dispatcher.html), and shown how to put it all together with a [tutorial](https://facebook.github.io/flux/docs/todo-list.html). Now let's look at how to do formal unit testing of Flux applications with [Jest](https://facebook.github.io/jest/), Facebook's auto-mocking testing framework.
Testing with Jest
@@ -178,7 +180,7 @@ Now we have a collection of objects that will come back from MyOtherStore whenev
A brief example of this technique is up on GitHub within the Flux Chat example's [UnreadThreadStore-test.js](https://github.com/facebook/flux/tree/master/examples/flux-chat/js/stores/__tests__/UnreadThreadStore-test.js).
For more information about the `mock` property of mocked methods or Jest's ability to provide custom mock values, see Jest's documentation on [mock functions](http://facebook.github.io/jest/docs/mock-functions.html).
For more information about the `mock` property of mocked methods or Jest's ability to provide custom mock values, see Jest's documentation on [mock functions](https://facebook.github.io/jest/docs/mock-functions.html).
Moving Logic from React to Stores
@@ -313,11 +315,11 @@ render: function() {
},
```
To learn how to test React components themselves, check out the [Jest tutorial for React](http://facebook.github.io/jest/docs/tutorial-react.html) and the [ReactTestUtils documentation](http://facebook.github.io/react/docs/test-utils.html).
To learn how to test React components themselves, check out the [Jest tutorial for React](https://facebook.github.io/jest/docs/tutorial-react.html) and the [ReactTestUtils documentation](/react/docs/test-utils.html).
Further Reading
---------------
- [Mocks Aren't Stubs](http://martinfowler.com/articles/mocksArentStubs.html) by Martin Fowler
- [Jest API Reference](http://facebook.github.io/jest/docs/api.html)
- [Jest API Reference](https://facebook.github.io/jest/docs/api.html)
The upcoming React 0.12 tweaks some APIs to get us close to the final 1.0 API. This release is all about setting us up for making the `ReactElement` type really FAST, [jest unit testing](http://facebook.github.io/jest/) easier, making classes simpler (in preparation for ES6 classes) and better integration with third-party languages!
The upcoming React 0.12 tweaks some APIs to get us close to the final 1.0 API. This release is all about setting us up for making the `ReactElement` type really FAST, [jest unit testing](https://facebook.github.io/jest/) easier, making classes simpler (in preparation for ES6 classes) and better integration with third-party languages!
If you currently use JSX everywhere, you don't really have to do anything to get these benefits! The updated transformer will do it for you.
@@ -72,7 +72,7 @@ This is the biggest change to 0.12. Don't worry though. This functionality conti
### React With JSX
If you use the React specific [JSX](http://facebook.github.io/jsx/) transform, the upgrade path is simple. Just make sure you have React in scope.
If you use the React specific [JSX](https://facebook.github.io/jsx/) transform, the upgrade path is simple. Just make sure you have React in scope.
```javascript
// If you use node/browserify modules make sure
@@ -92,7 +92,7 @@ var MyOtherComponent = React.createClass({
});
```
*NOTE: React's JSX will not call arbitrary functions in future releases. This restriction is introduced so that it's easier to reason about the output of JSX by both the reader of your code and optimizing compilers. The JSX syntax is not tied to React. Just the transpiler. You can still use [the JSX spec](http://facebook.github.io/jsx/) with a different transpiler for custom purposes.*
*NOTE: React's JSX will not call arbitrary functions in future releases. This restriction is introduced so that it's easier to reason about the output of JSX by both the reader of your code and optimizing compilers. The JSX syntax is not tied to React. Just the transpiler. You can still use [the JSX spec](https://facebook.github.io/jsx/) with a different transpiler for custom purposes.*
We are finally ready to share the work we've been doing over the past couple months. A lot has gone into this and we want to make sure we iron out any potential issues before we make this final. So, we're shipping a Release Candidate for React v0.12 today. If you get a chance, please give it a try and report any issues you find! A full changelog will accompany the final release but we've highlighted the interesting and breaking changes below.
@@ -9,13 +9,13 @@ We are finally ready to share the work we've been doing over the past couple mon
The release candidate is available for download:
* **React**
Dev build with warnings: <http://fb.me/react-0.12.0-rc1.js>
Minified build for production: <http://fb.me/react-0.12.0-rc1.min.js>
Dev build with warnings: <https://fb.me/react-0.12.0-rc1.js>
Minified build for production: <https://fb.me/react-0.12.0-rc1.min.js>
***React with Add-Ons**
Dev build with warnings: <http://fb.me/react-with-addons-0.12.0-rc1.js>
Minified build for production: <http://fb.me/react-with-addons-0.12.0-rc1.min.js>
Dev build with warnings: <https://fb.me/react-with-addons-0.12.0-rc1.js>
Minified build for production: <https://fb.me/react-with-addons-0.12.0-rc1.min.js>
***In-Browser JSX transformer**
<http://fb.me/JSXTransformer-0.12.0-rc1.js>
<https://fb.me/JSXTransformer-0.12.0-rc1.js>
We've also published version `0.12.0-rc1` of the `react` and `react-tools` packages on npm and the `react` package on bower.
@@ -27,7 +27,7 @@ The biggest conceptual change we made in v0.12 is the move to React Elements. [W
## JSX Changes
Earlier this year we decided to write [a specification for JSX](http://facebook.github.io/jsx/). This has allowed us to make some changes focused on the React specific JSX and still allow others to innovate in the same space.
Earlier this year we decided to write [a specification for JSX](https://facebook.github.io/jsx/). This has allowed us to make some changes focused on the React specific JSX and still allow others to innovate in the same space.
This round-up is a special edition on [Flux](http://facebook.github.io/flux/). If you expect to see diagrams showing arrows that all point in the same direction, you won't be disappointed!
This round-up is a special edition on [Flux](https://facebook.github.io/flux/). If you expect to see diagrams showing arrows that all point in the same direction, you won't be disappointed!
## React And Flux at ForwardJS
Facebook engineers [Jing Chen](https://github.com/jingc) and [Bill Fisher](https://github.com/fisherwebdev) gave a talk about Flux and React at [ForwardJS](http://forwardjs.com/), and how using an application architecture with a unidirectional data flow helped solve recurring bugs.
@@ -24,10 +24,10 @@ Yahoo is converting Yahoo Mail to React and Flux and in the process, they open s
## Reflux
[Mikael Brassman](http://spoike.ghost.io/) wrote [Reflux](https://github.com/spoike/refluxjs), a library that implements Flux concepts. Note that it diverges significantly from the way we use Flux at Facebook. He explains [the reasons why in a blog post](http://spoike.ghost.io/deconstructing-reactjss-flux/).
[Mikael Brassman](https://spoike.ghost.io/) wrote [Reflux](https://github.com/spoike/refluxjs), a library that implements Flux concepts. Note that it diverges significantly from the way we use Flux at Facebook. He explains [the reasons why in a blog post](https://spoike.ghost.io/deconstructing-reactjss-flux/).
@@ -61,7 +61,7 @@ Yahoo is converting Yahoo Mail to React and Flux and in the process, they open s
>
> - There should be only one channel for all state changes: The Dispatcher. This makes debugging easy because it just requires a single console.log in the dispatcher to observe every single state change trigger.
>
> - Asynchronously executed callbacks should not leak into Stores. The consequences of it are just to hard to fully foresee. This leads to elusive bugs. Stores should only execute synchronous code. Otherwise they are too hard to understand.
> - Asynchronously executed callbacks should not leak into Stores. The consequences of it are just too hard to fully foresee. This leads to elusive bugs. Stores should only execute synchronous code. Otherwise they are too hard to understand.
>
> - Avoiding actions firing other actions makes your app simple. We use the newest Dispatcher implementation from Facebook that does not allow a new dispatch while dispatching. It forces you to do things right.
>
@@ -107,22 +107,22 @@ undo: function() {
## React and Flux
[Christian Alfoni](https://github.com/christianalfoni) wrote an article where [he compares Backbone, Angular and Flux](http://christianalfoni.github.io/javascript/2014/08/20/react-js-and-flux.html) on a simple example that's representative of a real project he worked on.
[Christian Alfoni](https://github.com/christianalfoni) wrote an article where [he compares Backbone, Angular and Flux](https://christianalfoni.github.io/javascript/2014/08/20/react-js-and-flux.html) on a simple example that's representative of a real project he worked on.
> Wow, that was a bit more code! Well, try to think of it like this. In the above examples, if we were to do any changes to the application we would probably have to move things around. In the FLUX example we have considered that from the start.
>
> Any changes to the application is adding, not moving things around. If you need a new store, just add it and make components dependant of it. If you need more views, create a component and use it inside any other component without affecting their current "parent controller or models".
>
> [Read the full article...](http://christianalfoni.github.io/javascript/2014/08/20/react-js-and-flux.html)
> [Read the full article...](https://christianalfoni.github.io/javascript/2014/08/20/react-js-and-flux.html)
## Flux: Step by Step approach
[Nicola Paolucci](https://github.com/durdn) from Atlassian wrote a great guide to help your getting understand [Flux step by step](http://blogs.atlassian.com/2014/08/flux-architecture-step-by-step/).
[Nicola Paolucci](https://github.com/durdn) from Atlassian wrote a great guide to help your getting understand [Flux step by step](https://blogs.atlassian.com/2014/08/flux-architecture-step-by-step/).
Last but not least, Flux and React ideas are not limited to JavaScript inside of the browser. The iOS team at Facebook re-implemented Newsfeed using very similar patterns.
Every few weeks someone asks us when we are going to organize a conference for React. Our answer has always been "some day". In the mean time, people have been talking about React at other JavaScript conferences around the world. But now the time has finally come for us to have a conference of our own.
We're happy to announce the availability of React v0.12! After over a week of baking as the release candidate, we uncovered and fixed a few small issues. Thanks to all of you who upgraded and gave us feedback!
@@ -11,13 +11,13 @@ We have talked a lot about some of the bigger changes in this release. [We intro
The release is available for download:
* **React**
Dev build with warnings: <http://fb.me/react-0.12.0.js>
Minified build for production: <http://fb.me/react-0.12.0.min.js>
Dev build with warnings: <https://fb.me/react-0.12.0.js>
Minified build for production: <https://fb.me/react-0.12.0.min.js>
***React with Add-Ons**
Dev build with warnings: <http://fb.me/react-with-addons-0.12.0.js>
Minified build for production: <http://fb.me/react-with-addons-0.12.0.min.js>
Dev build with warnings: <https://fb.me/react-with-addons-0.12.0.js>
Minified build for production: <https://fb.me/react-with-addons-0.12.0.min.js>
***In-Browser JSX transformer**
<http://fb.me/JSXTransformer-0.12.0.js>
<https://fb.me/JSXTransformer-0.12.0.js>
We've also published version `0.12.0` of the `react` and `react-tools` packages on npm and the `react` package on bower.
Pedro Nauck ([pedronauck](https://github.com/pedronauck)) delivered an impeccably illustrated deck at Brazil's _Front in Floripa_ conference. Watch him talk about how to keep delivering value as your app scales, by keeping your development process simple.
Murilo Pereira ([mpereira](https://github.com/mpereira)) tussles with the topic of complexity in this blog post about [coping with scaling up](http://www.techsonian.net/2014/09/from-backbone-to-react-our-experience-scaling-a-web-application/), where he describes how his team used React to make possible the “nearly impossible.”
I ([steveluscher](https://github.com/steveluscher)) spoke at Manning Publications' “Powered By JavaScript” Strangeloop pre-conf in St. Louis. There, I proposed a new notation to talk about development complexity – Big-Coffee Notation ☕(n) – and spoke about the features of React that help keep our Big-Coffee from going quadratic, as our user interfaces get more complex.
James Pearce ([jamesgpearce](https://github.com/jamesgpearce)) carried Big-Coffee all the way to Raleigh, NC. At the _All Things Open_ conference, he spoke about some of the design decisions that went into React, particularly those that lend themselves to simpler, more reliable code.
Michael Ridgway ([mridgway](https://github.com/mridgway)) shows us how Yahoo! (who recently [moved Yahoo! Mail to React](http://www.slideshare.net/rmsguhan/react-meetup-mailonreact)) renders their React+Flux application, server-side.
Péter Márton ([hekike](https://github.com/hekike)) helps us brew a cold one (literally) using an application that's server-client [isomorphic and indexable](http://blog.risingstack.com/from-angularjs-to-react-the-isomorphic-way/). Demo and sample code included – cold ones sold separately.
And, lest you think that client-server isomorphism exists in pursuit of crawalable, indexable HTML alone, watch as Nate Hunzaker ([nhunzaker](https://github.com/nhunzaker)) [server renders data visualizations as SVG](http://viget.com/extend/visualization-is-for-sharing-using-react-for-portable-data-visualization) with React.
## React Router Mows the Lawn
Ryan Florence ([rpflorence](https://github.com/rpflorence])) and Michael Jackson ([mjackson](https://github.com/mjackson)) unveiled a new API for [React Router](https://github.com/rackt/react-router) that solves some of its user's problems by eliminating the problems themselves. Read all about what React Router learned from its community of users, and how they've [rolled your ideas into their latest release](https://github.com/rackt/react-router/wiki/Announcements).
## React in Practice
Jonathan Beebe ([somethingkindawierd](https://github.com/somethingkindawierd)) spoke about how he uses React to build tools that deliver hope to those trying to make the best of a bad situation. Watch his talk from this year's _Nodevember_ conference in Nashville
If you take a peek under the covers, you'll find that React powers [Carousel](https://blog.carousel.com/2014/11/introducing-carousel-for-web-ipad-and-android-tablet/), Dropbox's new photo and video gallery app.
We enjoyed a cinematic/narrative experience with this React-powered, interactive story by British author William Boyd. Dive into “[The Vanishing Game](https://thevanishinggame.wellstoried.com)” and see for yourself.
## Be Kind, Rewind
Spend the next 60 seconds watching Daniel Woelfel ([dwwoelfel](https://github.com/dwwoelfel)) serialize a React app's state as a string, then deserialize it to produce a working UI. Read about how he uses this technique to [reproduce bugs](http://blog.circleci.com/local-state-global-concerns/) reported to him by his users.
Tom Chen ([tomchentw](https://github.com/tomchentw)) brings us a [react-google-maps](https://tomchentw.github.io/react-google-maps/) component, and a way to syntax highlight source code using Prism and the [react-prism](https://tomchentw.github.io/react-prism/) component, for good measure.
Jed Watson ([jedwatson](https://github.com/JedWatson)) helps you manage touch, tap, and press events using the [react-tappable](https://github.com/JedWatson/react-tappable) component.
To find these, and more community-built components, consult the [React Components](http://react-components.com/) and [React Rocks](http://react.rocks) component directories. React Rocks recently exceeded one-hundred listed components and counting. See one missing? Add the keyword `react-component` to your `package.json` to get listed on React Components, and [submit a link to React Rocks](https://docs.google.com/forms/d/1TpnwJmLcmmGj-_TI68upu_bKBViYeiKx7Aj9uKmV6wY/viewform).
## Waiter, There's a CSS In My JavaScript
The internet is abuzz with talk of styling React components using JavaScript instead of CSS. Christopher Chedeau ([vjeux](https://github.com/vjeux)) talks about some of the [fundamental style management challenges](https://speakerdeck.com/vjeux/react-css-in-js) we grapple with, at Facebook scale. A number of implementations of JavaScript centric style management solutions have appeared in the wild, including the React-focused [react-style](https://github.com/js-next/react-style).
## Test Isolation
Yahoo! shows us how they make use of `iframe` elements to [unit test React components in isolation](http://yahooeng.tumblr.com/post/102274727496/to-testutil-or-not-to-testutil).
## You've Got The Hang of Flux, Now Let's Flow
Facebook Open Source released [Flow](https://code.facebook.com/posts/1505962329687926/flow-a-new-static-type-checker-for-javascript/) this month – a static type checker for JavaScript. Naturally, Flow supports JSX, and you can use it to [type check React applications](https://code.facebook.com/posts/1505962329687926/flow-a-new-static-type-checker-for-javascript/#compatibility). There's never been a better reason to start making use of `propTypes` in your component specifications!
## Countdown to React.js Conf 2014
We're counting down the days until [React.js Conf](http://conf.reactjs.com) at Facebook's headquarters in Menlo Park, California, on January 28th & 29th, 2015. Thank you, to everyone who responded to the Call for Presenters. Mark the dates; tickets go on sale in three waves: at noon PST on November 28th, December 5th, and December 12th, 2014.
## React Meetups Around the World
<blockquote class="twitter-tweet" lang="en"><p>React JS meetup having pretty good turn up rate today <a href="https://twitter.com/hashtag/londonreact?src=hash">#londonreact</a> <a href="http://t.co/c360dlVVAe">pic.twitter.com/c360dlVVAe</a></p>— Alexander Savin (@karismafilms) <a href="https://twitter.com/karismafilms/status/535152580377468928">November 19, 2014</a></blockquote>
<div class="skinny-row">
<div class="skinny-col">
<blockquote class="twitter-tweet" lang="en"><p>60+ attendees at the second React.js Utah meetup. <a href="https://twitter.com/ryanflorence">@ryanflorence</a> doing a great job, even without the internet. <a href="http://t.co/fV59AQTOyu">pic.twitter.com/fV59AQTOyu</a></p>— ReactJS Utah (@reactjsutah) <a href="https://twitter.com/reactjsutah/status/527259410020573184">October 29, 2014</a></blockquote>
</div>
<div class="skinny-col">
<blockquote class="twitter-tweet" lang="en"><p><a href="https://twitter.com/hashtag/ReactJS?src=hash">#ReactJS</a> meetup at <a href="https://twitter.com/Yahoo">@Yahoo</a> ! History of <a href="https://twitter.com/yahoomail">@yahoomail</a> and why we chose react and NodeJS <a href="http://t.co/Nm4EdTv45G">pic.twitter.com/Nm4EdTv45G</a></p>— rmsguhan (@rmsguhan) <a href="https://twitter.com/rmsguhan/status/515370950427029504">September 26, 2014</a></blockquote>
</div>
</div>
<div class="skinny-row">
<div class="skinny-col">
<blockquote class="twitter-tweet" data-cards="hidden" lang="en"><p>The very first ReactJS meetup in NYC tonight, I'll be speaking about the big ideas behind Om <a href="http://t.co/dvPrFqE9eP">http://t.co/dvPrFqE9eP</a></p>— David Nolen (@swannodette) <a href="https://twitter.com/swannodette/status/532190993463128064">November 11, 2014</a></blockquote>
</div>
<div class="skinny-col">
<blockquote class="twitter-tweet" lang="en"><p>If anyone in Sydney is curious about <a href="https://twitter.com/reactjs">@reactjs</a>, I'm presenting at <a href="https://twitter.com/sydjs">@sydjs</a> tonight on how to use it and why it is the future. <a href="https://twitter.com/hashtag/javascript?src=hash">#javascript</a></p>— Jed Watson (@JedWatson) <a href="https://twitter.com/JedWatson/status/534943557568565248">November 19, 2014</a></blockquote>
We just shipped React v0.12.2, bringing the 0.12 branch up to date with a few small fixes that landed in master over the past 2 months.
You may have noticed that we did not do an announcement for v0.12.1. That release was snuck out in anticipation of [Flow](http://flowtype.org/), with only transform-related changes. Namely we added a flag to the `jsx` executable which allowed you to safely transform Flow-based code to vanilla JS. If you didn't update for that release, you can safely skip it and move directly to v0.12.2.
The release is available for download from the CDN:
* **React**
Dev build with warnings: <https://fb.me/react-0.12.2.js>
Minified build for production: <https://fb.me/react-0.12.2.min.js>
***React with Add-Ons**
Dev build with warnings: <https://fb.me/react-with-addons-0.12.2.js>
Minified build for production: <https://fb.me/react-with-addons-0.12.2.min.js>
***In-Browser JSX transformer**
<https://fb.me/JSXTransformer-0.12.2.js>
We've also published version `0.12.2` of the `react` and `react-tools` packages on npm and the `react` package on bower. `0.12.1` is also available in the same locations if need those.
Please try these builds out and [file an issue on GitHub](https://github.com/facebook/react/issues/new) if you see anything awry.
## Changelog
### React Core
* Added support for more HTML attributes: `formAction`, `formEncType`, `formMethod`, `formTarget`, `marginHeight`, `marginWidth`
* Added `strokeOpacity` to the list of unitless CSS properties
* Removed trailing commas (allows npm module to be bundled and used in IE8)
* Fixed bug resulting in error when passing `undefined` to `React.createElement` - now there is a useful warning
### React Tools
* JSX-related transforms now always use double quotes for props and `displayName`
Today I'm really happy to announce the React.js Conf Diversity Scholarship! We believe that a diverse set of viewpoints and opinions is really important to build a thriving community. In an ideal world, every part of the tech community would be made up of people from all walks of life. However the reality is that we must be proactive and make an effort to make sure everybody has a voice. As conference organizers we worked closely with the Diversity Team here at Facebook to set aside 10 tickets and provide a scholarship. 10 tickets may not be many in the grand scheme but we really believe that this will have a positive impact on the discussions we have at the conference.
I'm really excited about this and I hope you are too! The full announcement is below:
- - -
The Diversity Team at Facebook is excited to announce that we are now accepting applications for the React.js Conf scholarship!
Beginning today, those studying or working in computer science or a related field can apply for an all-expense paid scholarship to attend the React.js Conf at Facebook’s Headquarters in Menlo Park, CA on January 28 & 29, 2015. React opens a world of new possibilities such as server-side rendering, real-time updates, different rendering targets like SVG and canvas. Join us at React.js Conf to shape the future of client-side applications! For more information about the React.js conference, please see the [website](http://conf.reactjs.com/) and [previous](/react/blog/2014/10/27/react-js-conf.html) [updates](/react/blog/2014/11/24/react-js-conf-updates.html) on our blog.
At Facebook, we believe that anyone anywhere can make a positive impact by developing products to make the world more open and connected to the people and things they care about. Given the current realities of the tech industry and the lack of representation of communities we seek to serve, applicants currently under-represented in Computer Science and related fields are strongly encouraged to apply.
Facebook will make determinations on scholarship recipients in its sole discretion. Facebook complies with all equal opportunity laws.
To apply for the scholarship, please visit the Application Page: <https://www.surveymonkey.com/s/XVJGK6R>
## Award Includes
* Paid registration fee for the React.js Conf January 28 & 29th at Facebook’s Headquarters in Menlo Park, CA
* Paid travel and lodging expenses
* Additional $200 meal stipend
## Important Dates
* Monday, January 5, 2015: Applications for the React.js Conf Scholarship must be submitted in full
* Friday, January 9, 2015: Award recipients will be notified by email of their acceptance
React 0.13 has a lot of nice features but there is one particular feature that I'm really excited about. I couldn't wait for React.js Conf to start tomorrow morning.
Maybe you're like me and staying up late excited about the conference, or maybe you weren't one of the lucky ones to get a ticket. Either way I figured I'd give you all something to play with until then.
We just published a beta version of React v0.13.0 to [npm](https://www.npmjs.com/package/react)! You can install it with `npm install react@0.13.0-beta.1`. Since this is a pre-release, we don't have proper release notes ready.
So what is that one feature I'm so excited about that I just couldn't wait to share?
## Plain JavaScript Classes!!
JavaScript originally didn't have a built-in class system. Every popular framework built their own, and so did we. This means that you have a learn slightly different semantics for each framework.
We figured that we're not in the business of designing a class system. We just want to use whatever is the idiomatic JavaScript way of creating classes.
In React 0.13.0 you no longer need to use `React.createClass` to create React components. If you have a transpiler you can use ES6 classes today. You can use the transpiler we ship with `react-tools` by making use of the harmony option: `jsx --harmony`.
The API is mostly what you would expect, with the exception of `getInitialState`. We figured that the idiomatic way to specify class state is to just use a simple instance property. Likewise `getDefaultProps` and `propTypes` are really just properties on the constructor.
Wait, assigning to properties seems like a very imperative way of defining classes! You're right, however, we designed it this way because it's idiomatic. We fully expect a more declarative syntax for property initialization to arrive in future version of JavaScript. It might look something like this:
This was inspired by TypeScript's property initializers.
### Autobinding
`React.createClass` has a built-in magic feature that bound all methods to `this` automatically for you. This can be a little confusing for JavaScript developers that are not used to this feature in other classes, or it can be confusing when they move from React to other classes.
Therefore we decided not to have this built-in into React's class model. You can still explicitly prebind methods in your constructor if you want.
```javascript
classCounterextendsReact.Component{
constructor(){
super();
this.tick=this.tick.bind(this);
}
tick(){
...
}
...
}
```
However, when we have the future property initializers, there is a neat trick that you can use to accomplish this syntactically:
```javascript
classCounterextendsReact.Component{
tick=()=>{
...
}
...
}
```
### Mixins
Unfortunately, we will not launch any mixin support for ES6 classes in React. That would defeat the purpose of only using idiomatic JavaScript concepts.
There is no standard and universal way to define mixins in JavaScript. In fact, several features to support mixins were dropped from ES6 today. There are a lot of libraries with different semantics. We think that there should be one way of defining mixins that you can use for any JavaScript class. React just making another doesn't help that effort.
Therefore, we will keep working with the larger JS community to create a standard for mixins. We will also start designing a new compositional API that will help make common tasks easier to do without mixins. E.g. first-class subscriptions to any kind of Flux store.
Luckily, if you want to keep using mixins, you can just keep using `React.createClass`.
> **Note:**
>
> The classic `React.createClass` style of creating classes will continue to work just fine.
## Other Languages!
Since these classes are just plain old JavaScript classes, you can use other languages that compile to JavaScript classes, such as TypeScript.
You can also use CoffeeScript classes:
```coffeescript
div = React.createFactory'div'
classCounterextendsReact.Component
@propTypes = initialCount: React.PropTypes.number
@defaultProps = initialCount: 0
constructor: (props) ->
superprops
@state = count: props.initialCount
tick: =>
@setStatecount: @state.count+1
render: ->
divonClick: @tick,
'Clicks: '
@state.count
```
You can even use the old ES3 module pattern if you want:
It was a privilege to welcome the React community to Facebook HQ on January 28–29 for the first-ever React.js Conf, and a pleasure to be be able to unveil three new technologies that we've been using internally at Facebook for some time: GraphQL, Relay, and React Native.
<strong>Tom Occhino</strong> opened with a history of how React came to be, before announcing Facebook’s answer to a long-looming what-if question: what if we could use React to target something other than the DOM?
<h3 style="margin-top:0"><a class="anchor" name="talk-tweak"></a>Tweaking in real time <a class="hash-link" href="#talk-tweak">#</a></h3>
<p>
<strong>Brenton Simpson</strong> showed us how eBay brings Bret Victor’s feedback loop to your favorite editor using Webpack, react-hot-loader, and <a href="https://github.com/appsforartists/ambidex">Ambidex</a>.
<h3 style="margin-top:0"><a class="anchor" name="talk-ast"></a>Abstract Syntax Trees <a class="hash-link" href="#talk-ast">#</a></h3>
<p>
<strong>Gurdas Nijor</strong> showed us how we can leverage some conventions of React to perform source code transformations that unlock an inspirational set of use cases.
<h3 style="margin-top:0"><a class="anchor" name="talk-relay-graphql"></a>Relay and GraphQL <a class="hash-link" href="#talk-relay-graphql">#</a></h3>
<p>
<strong>Daniel Schafer</strong> and <strong>Jing Chen</strong> showed us how Facebook approaches data fetching with React, giving us an early peek at the forthcoming duo of Relay and GraphQL.
<strong>Michael Jackson</strong> reminded us that URLs should be part of our design process, and showed us how <a href="https://github.com/rackt/react-router">react-router</a> can help to manage the transitions between them.
<strong>Jason Bonta</strong> showed us how complex user interfaces can get, and how his team keeps them performant as they scale. He also had the pleasure of open-sourcing his team’s work on <a href="https://facebook.github.io/fixed-data-table/">FixedDataTable</a>.
<strong>Ryan Florence</strong> showed us how easy it is to transition from a career selling life insurance, to a burgeoning one as a software developer. All you have to do is to learn how to say “yes.”
<strong>Christopher Chedeau</strong> showed us how to bring the developer experience of working with React on the web to native app development, using React Native.
<strong>Lee Byron</strong> led a master-class on persistent immutable data structures, showing us the world of possibility that they can unlock for your software, and perhaps Javascript in general.
The conference is over, but the conversation has just begun.
**Mihai Parparita** detailed his efforts to [hack his way to a React.js Conf ticket](http://blog.persistent.info/2014/12/html-munging-my-way-to-reactjs-conf.html); **James Long** blogged about [his first encounter with React Native](http://jlongster.com/First-Impressions-using-React-Native); **Eric Florenzano** talked about how he perceives the [impact of Relay, GraphQL, and React Native](https://medium.com/@ericflo/facebook-just-taught-us-all-how-to-build-websites-51f1e7e996f2) on software development; **Margaret Staples** blogged about her experience of [being on-campus at Facebook HQ](http://deadlugosi.blogspot.com/2015/02/facebook-gave-me-ice-cream.html); **Jeff Barczewski** tied his experience of attending the conference up with a bow in this [blog post filled with photos, videos, and links](http://codewinds.com/blog/2015-02-04-reactjs-conf.html); **Kevin Old** left us with [his takeaways](http://kevinold.com/2015/01/31/takeaways-from-reactjs-conf-2015.html); **Paul Wittmann** found React Native [freshly on his radar](http://www.railslove.com/stories/fresh-on-our-radar-react-native); and finally, undeterred by not being able to attend the conference in person, **Justin Ball** [summarized it from afar](http://www.justinball.com/2015/02/03/i-didn't-attend-react.js-conf/).
And, in case you missed a session, you can borrow **Michael Chan’s** [drawings](http://chantastic.io/2015-reactjs-conf/), **Mihai Parparita’s** [summary](https://quip.com/uJQeABv7nkFN), or **Shaohua Zhou’s** [day 1](http://getshao.com/2015/01/29/react-js-conf-notes-day1/) / [day 2](http://getshao.com/2015/01/29/react-js-conf-notes-day-2/) notes.
<div class="skinny-row">
<div class="skinny-col">
<blockquote class="twitter-tweet" lang="en"><p>Notes from <a href="https://twitter.com/dlschafer">@dlschafer</a> and <a href="https://twitter.com/jingc">@jingc</a>'s <a href="https://twitter.com/hashtag/reactjsconf?src=hash">#reactjsconf</a> talk "Data fetching for React applications at Facebook" <a href="http://t.co/IUZUbDCDMQ">pic.twitter.com/IUZUbDCDMQ</a></p>— Michael Chan (@chantastic) <a href="https://twitter.com/chantastic/status/560538533161472000">January 28, 2015</a></blockquote>
<blockquote class="twitter-tweet" lang="en"><p>This is just magical (in the good way)… GraphQL + Relay is amazing. <a href="https://twitter.com/hashtag/reactjsconf?src=hash">#reactjsconf</a></p>— Chris Williams (@voodootikigod) <a href="https://twitter.com/voodootikigod/status/560533225395589120">January 28, 2015</a></blockquote>
<blockquote class="twitter-tweet" lang="en"><p>These… these are my people. :) <a href="https://twitter.com/hashtag/reactjsconf?src=hash">#reactjsconf</a></p>— Thomas Beirne (@Beirnet) <a href="https://twitter.com/Beirnet/status/560317879501848576">January 28, 2015</a></blockquote>
</div>
<div class="skinny-col">
<blockquote class="twitter-tweet" lang="en"><p>Humbled by the React team and community. Found <a href="https://twitter.com/hashtag/reactjsconf?src=hash">#reactjsconf</a> very mindful, practical and just real.</p>— xnoɹǝʃ uɐıɹq (@brianleroux) <a href="https://twitter.com/brianleroux/status/560972130112655360">January 30, 2015</a></blockquote>
<blockquote class="twitter-tweet" lang="en"><p>I say with confidence as a former UIKit author: React's model for the UI layer is vastly better than UIKit's. React Native is a *huge* deal.</p>— Andy Matuschak (@andy_matuschak) <a href="https://twitter.com/andy_matuschak/status/560511204867575808">January 28, 2015</a></blockquote>
<blockquote class="twitter-tweet" lang="en"><p><a href="https://twitter.com/hashtag/reactjsconf?src=hash">#reactjsconf</a> was incredible. Amazing project stewardship and community. Boring prediction, React Native sends adoption vertical in 2015.</p>— David Nolen (@swannodette) <a href="https://twitter.com/swannodette/status/561232290273980416">January 30, 2015</a></blockquote>
<blockquote class="twitter-tweet" lang="en"><p>I really love the community shout outs by <a href="https://twitter.com/Vjeux">@vjeux</a> between talks at <a href="https://twitter.com/hashtag/reactjsconf?src=hash">#reactjsconf</a>!</p>— Andrew Rota (@AndrewRota) <a href="https://twitter.com/AndrewRota/status/560927339522297856">January 29, 2015</a></blockquote>
**All proceeds from React.js Conf 2015 were donated to the wonderful programs at [code.org](http://code.org)**. These programs aim to increase access to the field of computer science by underrepresented members of our community. Watch this video to learn more.
There's more to building an application than creating a user interface. Data fetching is still a tricky problem, especially as applications become more complicated. At [React.js Conf](http://conf.reactjs.com/) we announced two projects we've created at Facebook to make data fetching simple for developers, even as a product grows to include dozens of contributors and the application becomes as complex as Facebook itself.
The two projects — Relay and GraphQL — have been in use in production at Facebook for some time, and we're excited to be bringing them to the world as open source in the future. In the meantime, we wanted to share some additional information about the projects here.
Relay is a new framework from Facebook that provides data-fetching functionality for React applications. It was announced at React.js Conf (January 2015).
Each component specifies its own data dependencies declaratively using a query language called GraphQL. The data is made available to the component via properties on `this.props`.
Developers compose these React components naturally, and Relay takes care of composing the data queries into efficient batches, providing each component with exactly the data that it requested (and no more), updating those components when the data changes, and maintaining a client-side store (cache) of all data.
## What is GraphQL?
GraphQL is a data querying language designed to describe the complex, nested data dependencies of modern applications. It's been in production use in Facebook's native apps for several years.
On the server, we configure the GraphQL system to map queries to underlying data-fetching code. This configuration layer allows GraphQL to work with arbitrary underlying storage mechanisms. Relay uses GraphQL as its query language, but it is not tied to a specific implementation of GraphQL.
## The value proposition
Relay was born out of our experiences building large applications at Facebook. Our overarching goal is to enable developers to create correct, high-performance applications in a straightforward and obvious way. The design enables even large teams to make changes with a high degree of isolation and confidence. Fetching data is hard, dealing with ever-changing data is hard, and performance is hard. Relay aims to reduce these problems to simple ones, moving the tricky bits into the framework and freeing you to concentrate on building your application.
By co-locating the queries with the view code, the developer can reason about what a component is doing by looking at it in isolation; it's not necessary to consider the context where the component was rendered in order to understand it. Components can be moved anywhere in a render hierarchy without having to apply a cascade of modifications to parent components or to the server code which prepares the data payload.
Co-location leads developers to fall into the "pit of success", because they get exactly the data they asked for and the data they asked for is explicitly defined right next to where it is used. This means that performance becomes the default (it becomes much harder to accidentally over-fetch), and components are more robust (under-fetching is also less likely for the same reason, so components won't try to render missing data and blow up at runtime).
Relay provides a predictable environment for developers by maintaining an invariant: a component won't be rendered until all the data it requested is available. Additionally, queries are defined statically (ie. we can extract queries from a component tree before rendering) and the GraphQL schema provides an authoritative description of what queries are valid, so we can validate queries early and fail fast when the developer makes a mistake.
Only the fields of an object that a component explicitly asks for will be accessible to that component, even if other fields are known and cached in the store (because another component requested them). This makes it impossible for implicit data dependency bugs to exist latently in the system.
By handling all data-fetching via a single abstraction, we're able to handle a bunch of things that would otherwise have to be dealt with repeatedly and pervasively across the application:
- **Performance:** All queries flow through the framework code, where things that would otherwise be inefficient, repeated query patterns get automatically collapsed and batched into efficient, minimal queries. Likewise, the framework knows which data have been previously requested, or for which requests are currently "in flight", so queries can be automatically de-duplicated and the minimal queries can be produced.
- **Subscriptions:** All data flows into a single store, and all reads from the store are via the framework. This means the framework knows which components care about which data and which should be re-rendered when data changes; components never have to set up individual subscriptions.
- **Common patterns:** We can make common patterns easy. Pagination is the example that [Jing](https://twitter.com/jingc) gave at the conference: if you have 10 records initially, getting the next page just means declaring you want 15 records in total, and the framework automatically constructs the minimal query to grab the delta between what you have and what you need, requests it, and re-renders your view when the data become available.
- **Simplified server implementation:** Rather than having a proliferation of end-points (per action, per route), a single GraphQL endpoint can serve as a facade for any number of underlying resources.
- **Uniform mutations:** There is one consistent pattern for performing mutations (writes), and it is conceptually baked into the data querying model itself. You can think of a mutation as a query with side-effects: you provide some parameters that describe the change to be made (eg. attaching a comment to a record) and a query that specifies the data you'll need to update your view of the world after the mutation completes (eg. the comment count on the record), and the data flows through the system using the normal flow. We can do an immediate "optimistic" update on the client (ie. update the view under the assumption that the write will succeed), and finally commit it, retry it or roll it back in the event of an error when the server payload comes back.
## How does it relate to Flux?
In some ways Relay is inspired by Flux, but the mental model is much simpler. Instead of multiple stores, there is one central store that caches all GraphQL data. Instead of explicit subscriptions, the framework itself can track which data each component requests, and which components should be updated whenever the data change. Instead of actions, modifications take the form of mutations.
At Facebook, we have apps built entirely using Flux, entirely using Relay, or with both. One pattern we see emerging is letting Relay manage the bulk of the data flow for an application, but using Flux stores on the side to handle a subset of application state.
## Open source plans
We're working very hard right now on getting both GraphQL (a spec, and a reference implementation) and Relay ready for public release (no specific dates yet, but we are super excited about getting these out there).
In the meantime, we'll be providing more and more information in the form of blog posts (and in [other channels](https://gist.github.com/wincent/598fa75e22bdfa44cf47)). As we get closer to the open source release, you can expect more concrete details, syntax and API descriptions and more.
Over the weekend we pushed out our first (and hopefully only) release candidate for React v0.13!
We've talked a little bit about the changes that are coming. The splashiest of these changes is support for ES6 Classes. You can read more about this in [our beta announcement](/react/blog/2015/01/27/react-v0.13.0-beta-1.html). We're really excited about this! Sebastian also posted earlier this morning about [some of the other changes coming focused around ReactElement](/react/blog/2015/02/24/streamlining-react-elements.html). The changes we've been working on there will hopefully enable lots of improvements to performance and developer experience.
The release candidate is available for download:
* **React**
Dev build with warnings: <https://fb.me/react-0.13.0-rc1.js>
Minified build for production: <https://fb.me/react-0.13.0-rc1.min.js>
***React with Add-Ons**
Dev build with warnings: <https://fb.me/react-with-addons-0.13.0-rc1.js>
Minified build for production: <https://fb.me/react-with-addons-0.13.0-rc1.min.js>
***In-Browser JSX transformer**
<https://fb.me/JSXTransformer-0.13.0-rc1.js>
We've also published version `0.13.0-rc1` of the `react` and `react-tools` packages on npm and the `react` package on bower.
- - -
## Changelog
### React Core
#### Breaking Changes
* Mutating `props` after an element is created is deprecated and will cause warnings in development mode; future versions of React will incorporate performance optimizations assuming that props aren't mutated
* Static methods (defined in `statics`) are no longer autobound to the component class
*`ref` resolution order has changed slightly such that a ref to a component is available immediately after its `componentDidMount` method is called; this change should be observable only if your component calls a parent component's callback within your `componentDidMount`, which is an anti-pattern and should be avoided regardless
* Calls to `setState` in life-cycle methods are now always batched and therefore asynchronous. Previously the first call on the first mount was synchronous.
*`setState` and `forceUpdate` on an unmounted component now warns instead of throwing. That avoids a possible race condition with Promises.
* Access to most internal properties has been completely removed, including `this._pendingState` and `this._rootNodeID`.
#### New Features
* Support for using ES6 classes to build React components; see the [v0.13.0 beta 1 notes](/react/blog/2015/01/27/react-v0.13.0-beta-1.html) for details
* Added new top-level API `React.findDOMNode(component)`, which should be used in place of `component.getDOMNode()`. The base class for ES6-based components will not have `getDOMNode`. This change will enable some more patterns moving forward.
* New `ref` style, allowing a callback to be used in place of a name: `<Photo ref={(c) => this._photo = c} />` allows you to reference the component with `this._photo` (as opposed to `ref="photo"` which gives `this.refs.photo`)
*`this.setState()` can now take a function as the first argument for transactional state updates, such as `this.setState((state, props) => ({count: state.count + 1}));` -- this means that you no longer need to use `this._pendingState`, which is now gone.
* Support for iterators and immutable-js sequences as children
#### Deprecations
*`ComponentClass.type` is deprecated. Just use `ComponentClass` (usually as `element.type === ComponentClass`)
* Some methods that are available on `createClass`-based components are removed or deprecated from ES6 classes (for example, `getDOMNode`, `setProps`, `replaceState`).
### React with Add-Ons
#### Deprecations
*`React.addons.classSet` is now deprecated. This functionality can be replaced with several freely available modules. [classnames](https://www.npmjs.com/package/classnames) is one such module.
### React Tools
#### Breaking Changes
* When transforming ES6 syntax, `class` methods are no longer enumerable by default, which requires `Object.defineProperty`; if you support browsers such as IE8, you can pass `--target es3` to mirror the old behavior
#### New Features
*`--target` option is available on the jsx command, allowing users to specify and ECMAScript version to target.
*`es5` is the default.
*`es3` restored the previous default behavior. An additional transform is added here to ensure the use of reserved words as properties is safe (eg `this.static` will become `this['static']` for IE8 compatibility).
* The transform for the call spread operator has also been enabled.
### JSX
#### Breaking Changes
* A change was made to how some JSX was parsed, specifically around the use of `>` or `}` when inside an element. Previously it would be treated as a string but now it will be treated as a parse error. We will be releasing a standalone executable to find and fix potential issues in your JSX code.
React v0.13 is right around the corner and so we wanted to discuss some upcoming changes to ReactElement. In particular, we added several warnings to some esoteric use cases of ReactElement. There are no runtime behavior changes for ReactElement - we're adding these warnings in the hope that we can change some behavior in v0.14 if the changes are valuable to the community.
If you use React in an idiomatic way, chances are, you’ll never see any of these warnings. In that case, you can skip this blog post. You can just enjoy the benefits! These changes will unlock simplified semantics, better error messages, stack traces and compiler optimizations!
## Immutable Props
In React 0.12, the props object was mutable. It allows you to do patterns like this:
```js
varelement=<Foobar={false}/>;
if(shouldUseFoo){
element.props.foo=10;
element.props.bar=true;
}
```
The problem is that we don’t have a convenient way to tell when you’re done mutating.
### Problem: Mutating Props You Don’t Own
If you mutate something, you destroy the original value. Therefore, there is nothing to diff against. Imagine something like this:
```js
varelement=this.props.child;
element.props.count=this.state.count;
returnelement;
```
You take a ReactElement through `props.child` and mutate its property before rendering it. If this component's state updates, this render function won't actually get a new ReactElement in `props.child`. It will be the same one. You're mutating the same props.
You could imagine that this would work. However, this disables the ability for any component to use `shouldComponentUpdate`. It looks like the component never changed because the previous value is always the same as the next one. Since the DOM layer does diffing, this pattern doesn't even work in this case. The change will never propagate down to the DOM except the first time.
Additionally, if this element is reused in other places or used to switch back and forth between two modes, then you have all kinds of weird race conditions.
It has always been broken to mutate the props of something passed into you. The problem is that we can’t warn you about this special case if you accidentally do this.
### Problem: Too Late Validation
In React 0.12, we do PropType validation very deep inside React during mounting. This means that by the time you get an error, the debugger stack is long gone. This makes it difficult to find complex issues during debugging. We have to do this since it is fairly common for extra props to be added between the call to React.createElement and the mount time. So the type is incomplete until then.
The static analysis in Flow is also impaired by this. There is no convenient place in the code where Flow can determine that the props are finalized.
### Solution: Immutable Props
Therefore, we would like to be able to freeze the element.props object so that it is immediately immutable at the JSX callsite (or createElement). In React 0.13 we will start warning you if you mutate `element.props` after this point.
You can generally refactor these pattern to simply use two different JSX calls:
```js
if(shouldUseFoo){
return<Foofoo={10}bar={true}/>;
}else{
return<Foobar={false}/>;
}
```
However, if you really need to dynamically build up your props you can just use a temporary object and spread it into JSX:
```js
varprops={bar:false};
if(shouldUseFoo){
props.foo=10;
props.bar=true;
}
return<Foo{...props}/>;
```
It is still OK to do deep mutations of objects. E.g:
```js
return<FoonestedObject={this.state.myModel}/>;
```
In this case it's still ok to mutate the myModel object in state. We recommend that you use fully immutable models. E.g. by using immutable-js. However, we realize that mutable models are still convenient in many cases. Therefore we're only considering shallow freezing the props object that belongs to the ReactElement itself. Not nested objects.
### Solution: Early PropType Warnings
We will also start warning you for PropTypes at the JSX or createElement callsite. This will help debugging as you’ll have the stack trace right there. Similarly, Flow also validates PropTypes at this callsite.
Note: There are valid patterns that clones a ReactElement and adds additional props to it. In that case these additional props needs to be optional.
In React each child has both a "parent" and an “owner”. The owner is the component that created a ReactElement. I.e. the render method which contains the JSX or createElement callsite.
```js
classFoo{
render(){
return<div><span/></div>;
}
}
```
In this example, the owner of the `span` is `Foo` but the parent is the `div`.
There is also an undocumented feature called "context" that also relies on the concept of an “owner” to pass hidden props down the tree.
### Problem: The Semantics are Opaque and Confusing
The problem is that these are hidden artifacts attached to the ReactElement. In fact, you probably didn’t even know about it. It silently changes semantics. Take this for example:
```js
varfoo=<inputclassName="foo"/>;
classComponent{
render(){
returnbar?<inputclassName="bar"/>:foo;
}
}
```
These two inputs have different owners, therefore React will not keep its state when the conditional switches. There is nothing in the code to indicate that. Similarly, if you use `React.addons.cloneWithProps`, the owner changes.
### Problem: Timing Matters
The owner is tracked by the currently executing stack. This means that the semantics of a ReactElement varies depending on when it is executed. Take this example:
```js
classA{
render(){
return<Brenderer={text=><span>{text}</span>} />;
}
}
classB{
render(){
returnthis.props.renderer('foo');
}
}
```
The owner of the `span` is actually `B`, not `A` because of the timing of the callback. This all adds complexity and suffers from similar problems as mutation.
### Problem: It Couples JSX to React
Have you wondered why JSX depends on React? Couldn’t the transpiler have that built-in to its runtime? The reason you need to have `React.createElement` in scope is because we depend on internal state of React to capture the current "owner". Without this, you wouldn’t need to have React in scope.
### Solution: Make Context Parent-Based Instead of Owner-Based
The first thing we’re doing is warning you if you’re using the "owner" feature in a way that relies on it propagating through owners. Instead, we’re planning on propagating it through parents to its children. In almost all cases, this shouldn’t matter. In fact, parent-based contexts is simply a superset.
### Solution: Remove the Semantic Implications of Owner
It turns out that there are very few cases where owners are actually important part of state-semantics. As a precaution, we’ll warn you if it turns out that the owner is important to determine state. In almost every case this shouldn’t matter. Unless you’re doing some weird optimizations, you shouldn’t see this warning.
### Pending: Change the refs Semantics
Refs are still based on "owner". We haven’t fully solved this special case just yet.
In 0.13 we introduced a new callback-refs API that doesn’t suffer from these problems but we’ll keep on a nice declarative alternative to the current semantics for refs. As always, we won’t deprecate something until we’re sure that you’ll have a nice upgrade path.
## Keyed Objects as Maps
In React 0.12, and earlier, you could use keyed objects to provide an external key to an element or a set. This pattern isn’t actually widely used. It shouldn’t be an issue for most of you.
```js
<div>{{a:<span/>,b:<span/>}}</div>
```
### Problem: Relies on Enumeration Order
The problem with this pattern is that it relies on enumeration order of objects. This is technically unspecified, even though implementations now agree to use insertion order. Except for the special case when numeric keys are used.
### Problem: Using Objects as Maps is Bad
It is generally accepted that using objects as maps screw up type systems, VM optimizations, compilers etc. It is much better to use a dedicated data structure like ES6 Maps.
More importantly, this can have important security implications. For example this has a potential security problem:
Imagine if `item.title === '__proto__'` for example.
### Problem: Can’t be Differentiated from Arbitrary Objects
Since these objects can have any keys with almost any value, we can’t differentiate them from a mistake. If you put some random object, we will try our best to traverse it and render it, instead of failing with a helpful warning. In fact, this is one of the few places where you can accidentally get an infinite loop in React.
To differentiate ReactElements from one of these objects, we have to tag them with `_isReactElement`. This is another issue preventing us from inlining ReactElements as simple object literals.
### Solution: Just use an Array and key={…}
Most of the time you can just use an array with keyed ReactElements.
However, this is not always possible if you’re trying to add a prefix key to an unknown set (e.g. this.props.children). It is also not always the easiest upgrade path. Therefore, we are adding a helper to `React.addons` called `createFragment()`. This accepts a keyed object and returns an opaque type.
The exact signature of this kind of fragment will be determined later. It will likely be some kind of immutable sequence.
Note: This will still not be valid as the direct return value of `render()`. Unfortunately, they still need to be wrapped in a `<div />` or some other element.
## Compiler Optimizations: Unlocked!
These changes also unlock several possible compiler optimizations for static content in React 0.14. These optimizations were previously only available to template-based frameworks. They will now also be possible for React code! Both for JSX and `React.createElement/Factory`*!
See these GitHub Issues for a deep dive into compiler optimizations:
- [Reuse Constant Value Types](https://github.com/facebook/react/issues/3226)
\* If you use the recommended pattern of explicit React.createFactory calls on the consumer side - since they are easily statically analyzed.
## Rationale
I thought that these changes were particularly important because the mere existence of these patterns means that even components that DON’T use these patterns have to pay the price. There are other problematic patterns such as mutating state, but they’re at least localized to a component subtree so they don’t harm the ecosystem.
As always, we’d love to hear your feedback and if you have any trouble upgrading, please let us know.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
