It lives at https://github.com/facebook/flux/tree/master/examples/flux-todomvc now.
(cherry picked from commit 1033c4805f)
Conflicts:
examples/todomvc-flux/js/components/Footer.react.js
examples/todomvc-flux/js/components/MainSection.react.js
examples/todomvc-flux/js/stores/TodoStore.js
examples/todomvc-flux/package.json
When I first read these docs, it was not immediately clear to me that I could
use `React.addons.CSSTransitionGroup` to animate a single item coming into view,
or an item replacing an item already there. This was partly due to the example
which rendered a list of items.
This PR adds a blurb about being able to use
`React.addons.CSSTransitionGroup` with one or zero items, provides a code
example, and adds a note blockquote that a `key` attribute must always be
provided on each child of `React.addons.CSSTransitionGroup`. The latter point
was not immediately obvious from the original `TodoList` code example, since it
renders a list which would normally require `key` attributes anyway.
Test Plan:
- Refreshed `http://localhost:4000/react/docs/animation.html`, saw that the
docs additions rendered correctly.
- Example code not tested (it was extracted from working code).
(cherry picked from commit 721f397303)
Add PureRenderMixin and Perf to this page. Also, I think it's better if the link titles reflect the name used by these addons.
(cherry picked from commit d95a4ef983)
This order should make more sense; it moves important functions like React.renderComponent up and deprecated/discouraged ones like transferPropsTo and setProps down. No content changes.
In a world where this component was server-rendered, we wouldn't want to call the data-fetching code there so it makes more sense to have it in componentDidMount.
If we don't error here, we end up with a confusing error later on in this.getDOMNode() where ReactMount doesn't have the proper container registered in its object.
This change adds an additional function to the exported object to support getting access to the transformed result as an object rather than just a string result - the separate function designed to maintain backwards compatibility.
This facilitates tools that want the code separate from the sourcemap or anything else as time goes by.
See modification to the test-file: Basically we add a small hint at the end
of the error warning for propType errors to help identify which instantiation
of the component at hand is faulty.
This isn't actually enabled yet for public projects, but this will help
us speed up builds when it does get enabled.
http://docs.travis-ci.com/user/caching/
Error should be thrown in the previous condition is "not" meet. And the href propType is described as optional in the comment, but the null check was missing.
This copies the propType and contextType validation to a wrapper around the
descriptor factory. By doing the validation early, we make it easier to track
down bugs. It also prepares for static type checking which should be done at the
usage site.
This validation is not yet active and is just logged using monitorCodeUse. This
will allow us to clean up callsites which would fail this new type of
validation.
I chose to copy the validation of abstracting it out since this is just an
intermediate step to avoid spamming consoles. This makes more a much cleaner
diff review/history. The original validation in the instance will be deleted as
soon as we can turn on the warnings.
Additionally, getDefaultProps are moved to become a static function which is
only executed once. It should be moved to statics but we don't have a
convenient way to merge mixins in statics right now. Deferring to ES6 classes.
This is still a breaking change since you can return an object or array from
getDefaultProps, which later gets mutated and now the shared instance is
mutated. Mutating an object that is passed into you from props is highly
discouraged and likely to lead to subtle bugs anyway. So I'm not too worried.
The defaultProps will later be resolved in the descriptor factory. This will
enable a perf optimizations where we don't create an unnecessary object
allocation when you use default props. It also means that ReactChildren.map
has access to resolved properties which gives them consistent behavior whether
or not the default prop is specified.
Add support for spread attributes. Transforms into an Object.assign just
like jstransform does for spread properties in object literals.
Depends on https://github.com/facebook/esprima/pull/22
Github doesn't let us handle 404s within a project repository, so we
handle them at the organization level. In order to handle graceully for
specific projects, we're setting up redirects to projects' own 404.html.
The patternUnits attribute defines how a pattern's coordinate system is
defined (x, y, width, height). This is particularly important when using
repeatable patterns in SVG. This commit adds this attribute to the lists
of known properties.
Closes#1548
Add harmony transform support in browser
Fixes#1420. Moved some code around in the merge to account for more
changes in the transform code.
Conflicts:
vendor/browser-transforms.js
binds static methods on the descriptor to the component's actual constructor, so that `foo.constructor.bar()` and `Foo.bar()` run with the same `this`.
The Ballmer Peak XKCD suggests that it's a graph of ability, rather than bug frequency, which should be inversely correlated with ability. A simple change of the wording fixes this terrible mishandling of Ballmer Peak data.
This one was an actual behavioral bug rather than a bug with the tests; our intention was that the first element from the `defaultValue` array would remain selected but IE seemed to be choosing the last one instead. Now we set the value for uncontrolled components in componentDidUpdate when switching from multiple to non-multiple to ensure that a consistent option gets selected.
Test Plan: Ran the ReactDOMSelect tests in jest, phantomjs, IE10, Chrome, and Firefox. Also tested an uncontrolled select manually to make sure that nothing crazy happened when switching between options.
Previously this was failing because iframeDocument.body wasn't properly initialized. Creating the document this way seems to work in all environments
Test Plan: Ran the test in jest, phantomjs, IE10, Chrome, and Firefox.
Fixes bug introduced in c62c2c5.
Test Plan: Tested that the onLoad event was properly triggered on an image. Didn't test onError but I can only assume that it works equally well.
Currently, an `onBlur` creates a new todo on `TodoTextInput`. This makes sense for existing items but not for new items. I.e consider the following:
1. cursor on new item ("What needs to be done?")
2. click 'x' on the first item.
This results in two actions being fired:
1. TODO_CREATE, with an empty string as 'text'
2. TODO_DESTROY
The proposed fix doesn't send a TODO_CREATE if `text.trim() === "")`
I ran into a really difficult-to-debug issue with a React app with SVG
elements. Christopher sat down with me for a while and we finally figured out
that the browser was moving non-SVG elements out of a parent `<svg>` node which
triggered the `processUpdates()` invariant. This updates the error message
thrown from there to include this scenario in the possible issues list.
Fixes#1169.
This is a more robust way of fixing what MobileSafariClickPlugin previously tried to. Now even if you don't want anything to do with touch events, click events still work properly.
Test Plan: Added a click handler to an `<img />` element and triggered it in the iOS simulator -- it didn't execute before.
Not removing them resulted in leaks as we would hold on to removed nodes forever.
This really showed up with images and the load event where we would unmount and create a new img with the same react id as the old one. We properly cleared and primed the caches but we would handle the load event for both nodes. We would eventually hit an invariant in that path as we tried to handle the event for the removed node, which no longer matched the node we had in the cache.
By forcefully removing the listener, we'll avoid this problem entirely and we should leak fewer DOM nodes.
This strategy avoids a runtime check for every set (as opposed to using a mutation method).
Test Plan: Verify that changing className works on a div and a rect in latest Chrome, latest Firefox, IE9. Verify that the div works in IE8.
If the event is on the window object, topScroll, for instance, the topLevelTarget will not have getAttribute defined. Restore the previous `|| !topLevelTarget.attributes` check to avoid an error on every scroll.
I find myself often using (modified) examples to test in IE and it's a pain to have to add the shims in every time. Might as well just add them in always.
Can be run with `node_modules/.bin/jest` for now; didn't want to disturb the grunt setup.
Right now one test fails with:
```
FAIL browser/ui/__tests__/ReactDOMComponent-test.js (1.423s)
● ReactDOMComponent › updateDOM › it should update styles when mutating style object
- Expected: '0' toEqual: '0.5'
at Spec.<anonymous> (src/browser/ui/__tests__/ReactDOMComponent-test.js:99:33)
```
which I can only assume is a jsdom problem -- no other asserts fail.
cf. #1376.
This is useful for SVG. Dynamically adding and removing `<title>` elements in SVG still won't work properly because of getMarkupWrap but this at least lets you include it in initial render and then unmount the entire `<svg>` without problems.
Allow tools like grunt-react to include inline source maps in the
generated JavaScript. Browserify can then combine these source maps when
bundling everything together.
Usage:
```
var transform = require('react-tools').transform;
var output = transform(jsxContent, {
sourceMap: true,
sourceFilename: 'source.jsx'
});
```
The `output` will have an inline source map comment appended.
The previous examples didn't properly work when 1) a Store callback does
waitFor on Stores that haven't been reached yet and 2) a Store callback
waits on another Store that is already waiting.
The updated example uses constructs Promises up front and then
asynchronously resolves them.
For boolean-like objects, I've added hasOwnProperty checks in addition to the existing truthiness check even though for most of these dicts, we leave out false keys instead of setting them explicitly to false.
In DOMPropertyOperations, we don't need to check hasOwnProperty if the property is in isStandardName because (with the exception of getPossibleStandardName) the dicts on DOMProperty will now be consistently populated with every valid attribute.
I implemented this by checking for `type="text/jsx;harmony"`, since this
has a bit of a cleaner implementation rather than parsing a JSON object
out of a data attribute. If in the future there are other options to
pass, it would make sense to move to a system like that.
Along with adding support, there is also a new example added that's
the basic-jsx example with Harmony syntax.
With this, multiple setState calls triggered by a componentDidUpdate handler (or similar) will be batched together, regardless of if the original setState call was in a batching context.
I also cleaned up some inconsistencies with the order of component updates and callbacks in situations where one component's update directly causes another to update.
Fixes#1147. Helps with #1353 and #1245 as well, though doesn't completely fix them yet.
Test Plan:
grunt test
Currently require('ReactDefaultPerf').printExclusive() shows render
time and aggregate componentMount time.
This makes it show exclusive mount time by tracking a stack.
Fixes#1505.
Confusingly, the uglify-js package provides the `uglifyjs` binary and `npm run-script build` didn't work if uglify-js wasn't installed globally; now it does.
This copies the propType and contextType validation to a wrapper around the
descriptor factory. By doing the validation early, we make it easier to track
down bugs. It also prepares for static type checking which should be done at the
usage site.
This validation is not yet active and is just logged using monitorCodeUse. This
will allow us to clean up callsites which would fail this new type of
validation.
I chose to copy the validation instead of abstracting it out to a common abstraction. This is just an
intermediate step to avoid spamming consoles. The original validation in the instance will be deleted as soon as we can turn on the warnings at the callsite. Copy+Delete makes this a more a much cleaner diff review/history.
Additionally, getDefaultProps are moved to become a static function which is
only executed once. It should be moved to statics but we don't have a
convenient way to merge mixins in statics right now. Deferring to ES6 classes.
This is still a breaking change since you can return an object or array from
getDefaultProps, which later gets mutated and now the shared instance is
mutated. Mutating an object that is passed into you from props is highly
discouraged and likely to lead to subtle bugs anyway. So I'm not too worried.
The defaultProps are now resolved in the descriptor factory. This will enable
a perf optimizations where we don't create an unnecessary object allocation
when you use default props. It also means that ReactChildren.map has access to
resolved properties which gives them consistent behavior whether or not the
default prop is specified.
This is a breaking change since it can affect how mapping over children and
transferPropsTo works together with defaultProps.
KeyboardEvent now normalizes "charCode", "keyCode", "which" across all browsers
KeyboardEvent has partial "key"-support for KeyDown/KeyUp and full "key"-support for KeyPress.
KeyboardEvent, MouseEvent and TouchEvent now has "getModifierState", polyfill when not implemented.
Previously we were escaping both in createMarkupForStyles and then in createMarkupForProperty; now we escape only in the latter (otherwise the hypothetical style name `b&ckground` would become `b&amp;ckground`).
Test Plan: grunt fasttest
Some Android versions have the "transition" and "animation" properties
set on element style objects despite not supporting un-prefxied animations
and transitions. This change adds an additional sanity check to make sure
the correct event handlers are added for transition groups.
In IE10/11, it is apparently possible to have a Selection or Range object that has the following properties:
- `anchorNode` === `focusNode` (Selection) or `startContainer` === `endContainer` (Range)
- `anchorOffset` === `focusOffset` (Selection) or `startOffset` === `endOffset` (Range)
- `isCollapsed` === `false` (Selection) or `collapsed` === `false` (Range)
As defined in http://www.w3.org/TR/DOM-Level-2-Traversal-Range/ranges.html, this doesn't really make sense. Since the nodes and offsets are the same, the "collapsed" value should be `true`.
Moreover, when calling `selection.toString()` in this case, it appears that the entire text contents of `body` -- including `<script>` tag contents -- are considered within the selection. I thought maybe the selected nodes were missing from the DOM or something, but no, they're there.
Sidestep all of this in `ReactDOMSelection` by calculating the `collapsed` property manually and setting the selection length directly to zero if it is actually collapsed.
Side note: I think that for selection restoration on contenteditables, we shouldn't try to do this offset calculation. We should just use the structure provided natively (nodes and offsets) since we can restore using that structure as well.
Previous behavior: `transferPropsTo(<div style={{color: 'red'}} />)` would get `color` overriden if we transfer in a `style={{color: 'blue'}}`. This is inconsistent with how other props are transfered.
This simply reverses the order of arguments.
closes#1435
This makes it a little easier to add SVG properties. It also makes use of that injection that we claim is easy to use and will likely start playing a bigger part soon.
Closes#1009
We're now trying to access document directly at require time. Wrapping in a function prevented that before. But we can simply check what environment we're in first.
React components have _mountIndex, that looks like it is their order in DOM.
If you swap 2 elements in DOM, their order in children array isn't changed, but their _mountIndex is
There is no point in doing the feature detection on every call, unless there is an IE bug where it is not sure about which support for selection it has (totally plausible).
Adds a PropType that checks for proper use of the ReactLink API and optionally validates the type of value passed in via the link. Basically, it's a wrapper around PropTypes.shape that hides the implementation of ReactLink.
The `updatedChildren[j].parentNode.removeChild(updatedChildren[j]);` line below can fail if (1) we're moving/moving the same node twice or (2) the node we're looking for is gone completely. This makes it easier to distinguish between the two cases.
Perf shouldn't be a concern here because this is DOM code and invariants are fast in comparison.
Test Plan: grunt test
The report itself is more or less useful because it detects stuff like
big objects (e.g. CSSProperty) as being too complicated. Furthermore, afaik
nobody refactors the code based on what the report says =).
Fixes#1408.
Test Plan: Copy each code snippet into jsbin; type in the text box successfully; click the button and see the input clear (and in the second example, get focused).
In the future we could consider wrapping the entire public API (renderComponent, setProps, setState, etc) in this check but this should do for now.
Test Plan: grunt test
8855d6153e gave more accurate error messages for date and regexp by returning 'date' and 'regexp' respectively from `getPropType`.
However, for the object primitive check, which compares the instance passed with `getPropType's` return string, `object` !== 'date'.
This adds special hanlding for those.
This uses the return value (an Error or nothing) to indicate whether a prop passes validation or not. It used to be done through calling `console.warn` as a side-effect, except this didn't work well with and `oneOfType`, which calls each validator.
The solution was to insert a `.weak` prop to each validator to suppress the warning message. This is overkill and also doesn't work well in because it increases the potential API surface. Plus, letting the validators warn it can't be easily used for logging, especially for custom validators.
So `.weak` is no longer needed: fixes https://github.com/facebook/react/issues/863.
Backward compatibility for custom validators: since they didn't return anything and directly call `console.warn` or something, this doesn't break them.
Improvements:
- `arrayOf`, `oneOfType` and `oneOf` got better message now, since they can get hold of their validator's message and output that instead of a generic `warning: bla`.
- More complete tests, including testing custom types and `isRequired` on everything.
Bug fixes:
- oneOfType(...).isRequired didn't work. The workaround was to use `oneOfType(a.isRequired, b.isRequired, ...)`. This means `oneOfType(a.isRequired, b)` doesn't make sense. The new version simply makes `oneOfType(...).isRequired` possible.
- `oneOf([true])` worked for 'true' boolean because it converted everything to string before comparing. It no longer does.
- `oneOf([true]).isRequired` didn't work.
(see #1294)
The following steps also have an ajax function, but the 'error:' param
is gone after #13:
#14#17#19#20
This may be superfluous, but it helped me find an error with something I
was doing - Namely, in my .json file, I had single line javascript
comments ("//") that I copied from the tutorial. I couldn't find the
issue on later steps, but was able to see my issue when the error
handler complained about an unexpected "/" in my file in step #13.
Fixes#1227.
It seems rare that event handlers in two roots nested in the DOM will update the same component in the same tick, but if that happens, the updates should be batched together.
This was temporarily needed since clone on mount introduced a cyclic reference
in __DEV__. This reverts that change since we now have descriptors.
To avoid a problem where toJSON may collide.
Previously, this threw (in `__DEV__` only) in `ReactCurrentOwner.current.constructor.displayName` because `ReactCurrentOwner.current` is null:
```
React.renderComponent(<div>{{1: <div />, 2: <div />}}</div>, document.body);
```
Looks like while rewriting @petehunt forgot to remove this block.
See: 9ac27cb551
This block used to contain the only `runNextTick` ocurrences in the whole project.
No tests broken after removal, no documentation affected.
The other dispatch utils clear these out and I found a bug where they weren't being cleared out.
I'm thinking this should probably be done in the `SyntheticEvent` constructor but at least this way it's consistent. Also, I know no one else uses `executeDispatchesInOrderStopAtTrue` except the `ResponderEventPlugin`.
This mirrors the react-tools API; it doesn't include support (yet) for transforming `<script type="text/jsx">` blocks with the ES6 transforms, mostly because I don't have a good API in mind there.
Test Plan:
Ran
JSXTransformer.transform("var two = () => 2;", {harmony: true}).code
in Chrome's dev console and got back some ES5 code.
Add support for Opera <= 12 (Presto) in `BeforeInputEventPlugin`.
It turns out that Opera 12 has a `TextEvent` in `window`, but doesn't actually fire any input events. Even `input` apparently doesn't fire. Fall back to keypress handling in this case.
Browsers that natively support the `textInput` event appear to have a bug: when preventing default behavior for a `textInput` event occurring for a spacebar keypress, the character is prevented from being inserted **but the browser scrolls down**.
Minimal repro example: http://jsfiddle.net/salier/bX4fw/
This is ridiculous, since scrolling makes no sense when the user is focused in a textinput or contenteditable. Preventing default at the `textInput` stage should mean to prevent the character from being inserted, and should have no impact at all on scrolling behavior. I have filed this as a Chromium bug (https://code.google.com/p/chromium/issues/detail?id=355103) but I'm not going to hold out much hope that they'll fix it.
To resolve this, I'm special-casing the spacebar character at the plugin level, in `BeforeInputEventPlugin`. I looked for ways to do this at the component level, but it seems to me that this is simply a browser bug and it's cleaner to handle it there.
In browsers that can use the native `textInput` event, I'm checking the code of the pressed key. If it's the spacebar, we dispatch the synthetic event as if there were no native `textInput` event -- as if we were running Firefox. Then, if the synthetic event is not canceled and we make it through to the native `textInput` event, bail if the character data is a space character.
`renderComponent(<div style={invalidType}/>, container)` throws correctly,
but not when it's called a second time (i.e. updating rather than mounting).
It goes through `ReactDOMComponent.updateComponent` but there wasn't a
props assertion there.
(Removed the assertion in `receiveComponent`)
This diff introduces `TextInputEventPlugin` and `SyntheticTextInputEvent`, which are based on Webkit's native `textInput` event.
In Chrome, Safari, and Opera, the `textInput` event fires prior to the insertion of character data into the document. For normal typing, for example, thevent sequence is: `keydown`, `keypress`, `textInput`, `input`, `keyup`. The `textInput` event contains a `data` field corresponding to the character data that will actually be inserted.
There is also a `beforeinput` event described by http://www.w3.org/TR/DOM-Level-3-Events/#event-type-beforeinput, and this is essentially that event, so it may make sense to rename the plugin.
This event is especially useful because it solves a number of issues we can't currently handle with only keypress and composition events:
- **Windows Chrome: Trailing characters discarded in Korean IME.** For instance, `안녕하세요` becomes `안녕하세` with the final character discarded by the final `compositionend` event. The `textInput` event fires correctly with the final character.
- **Windows Chrome: Special characters discarded in IME.** Certain ideographs are discarded in IME mode. In Japanese, typing the ideographic space character is not represented by keypress but //is// represented by the subsequent `textInput`. This issue also applies to punctuation characters in Chinese.
- **OSX Chrome: Characters from palette discarded.** Inserting characters from the OSX character palette fails, since no keypress is fired.
The plugin is useful for Firefox and IE. For these, we record inserted characters via keypress and compositionend events and dispatch the synthetic event with these characters as the `data` field to match the native `textInput` event.
- Firefox has no corresponding `textInput` event and has not yet implemented `beforeinput`.
- IE has a native `textinput` event, but it fires after the DOM mutation has already occurred, so it isn't very useful as an analog to the Webkit version. I'm just not going to bother with it.
mapObject fits better with other module names ("flattenChildren", "traverseAllChildren" etc.) and highlights that it only works with objects - which is going to be more important once we'll have an ES6 Map polyfill.
These tests can still be run in the browser using `grunt test --debug`.
This is a repeat of 42f8d155f8. For posterity, we
do this because Phantom has a problem with Object.freeze and the test runner
can't do __DEV__ right (because we get rid of that in the build step).
Let's start logging objects as maps for children. We may want to deprecate this
and replace it with ImmutableMap and Map data structures instead.
This should ideally be logged in the recursive function but since that loses the
scope of where these children are passed it's easier to start tracking them
here to get an idea of how frequently and where it's used.
While looking up a detail of how `transferPropsTo()` works I noticed that we never check `TransferStrategies.hasOwnProperty(thisKey)` when merging props, just `newProps.hasOwnProperty(thisKey)` and a truthy test for `TransferStrategies[thisKey]`. This means that if our `newProps` has keys like `toString`, `valueOf`, or `constructor` etc. set, we will pull these functions off `TransferStrategies` and invoke them when merging props. In most cases this will just result in a failure to merge and some code without side effects being run but in the case of `valueOf` it will actually generate an exception.
I'm thinking that setting up `this.refs` in `mountComponent` is better than `construct`. Followed the same pattern as `ReactComponent.Mixin` and nulling out
the value in `construct` and setting it to its initial value in `mountComponent`.
This bites people all of the time. Until we have a better solution, let's just make the error message more actionable (most people don't know how the DOM
gets unexpectedly mutated).
The component that gets passed into renderComponent isn't guaranteed to be the
instance that gets mounted. We want to clone the instance.
Unit tests need to reason about the mounted instance. The first code mod changes:
ReactTestUtils.renderIntoDocument(<identifier>)
into
<identifier> = ReactTestUtils.renderIntoDocument(<identifier>)
Using this scripts:
scripts/bin/codemod -m -d ~/www --extensions js \
'^(\s*)ReactTestUtils\.renderIntoDocument\(\s*([$a-zA-Z0-9_]+)\s*\)' \
'\1\2 = ReactTestUtils.renderIntoDocument(\2)'
In the second case I do the same for React.renderComponent. However, there are
alot more unnecessary matches so I only codemod if the same identifier occurs
later in the file.
scripts/bin/codemod -m -d ~/www --extensions js \
'^(\s*)React.renderComponent\(\s*([$a-zA-Z0-9_]+)\s*?,(.*?\n?.*?\s\2\b)' \
'\1\2 = React.renderComponent(\2,\3'
And one more for ReactMount.renderComponent used by internals.
scripts/bin/codemod -m -d ~/www --extensions js \
'^(\s*)ReactMount.renderComponent\(\s*([$a-zA-Z0-9_]+)\s*?,(.*?\n?.*?\s\2\b)' \
'\1\2 = ReactMount.renderComponent(\2,\3'
This still matches many unnecessary cases where the second occurance of the
identifier is a redeclaration or comment. But this code mod doesn't hurt in
those cases.
Finally I have to do the same for:
this.<identifier> = React.renderComponent(this.<identifier>,
This is a common pattern for production code but not tests. Some of these call
sites will likely break when we move to true descriptors.
scripts/bin/codemod -m -d ~/www --extensions js \
'^(\s*)React.renderComponent\((\s*)this\.([$a-zA-Z0-9\_\.]+)\s*?,' \
'\1this.\3 = React.renderComponent(\2this.\3,'
We have unexpectedly had to shut Shirtstarter down, so it won't serve as a good React.js example any more unfortunately -- sorry for the documentation churn.
This is the first step towards descriptors. This will start cloning the
component when it's mounted instead of mounting the first instance.
This avoids an issue where a reference to the first instance can hang around
in props. Since a mounted component gets mutated, the descriptor changes.
We don't need to clone the props object itself. Mutating the shallow props
object of a child that's passed into you is already flawed. Those cases need to
use cloneWithProps. A props object is considered shallow frozen after it leaves
the render it was created in.
Optimizations and fix for JSXTransformer build.
Dropped dependency on emulation of Node.js native modules.
Added deamdify step for JSXTransformer build.
We found that the component would break if we set any statics with the
value 0. It turns out @chenglou already ran into this with
d71736b3ed but the statics code was copied
earlier, and still has this falsy check. Made the same change, updated
the unittest.
After we run `require('mock-modules').dumpCache()`, the object exported by
the `emptyObject` module will no longer be identical to previously
exported objects, so tests like `expect(component.refs).toBe(emptyObject)`
will fail.
Note that this behavior only manifests itself in tests, because of course
we do not call `dumpCache` in production code.
We could consider storing the `emptyObject` globally to thwart the effects
of `dumpCache`, but it's more idiomatic simply to re-`require` the latest
version of `emptyObject`.
I don't think this particular codepath was exercised at all (because all the callers call deleteValueForProperty) but this fixes a bug here nonetheless.
If no refs are rendered, `this.refs` is undefined. This is bad since it deopts & is hard to look for. Instead we should make `this.refs` an immutable empty object.
This adds an instrumentation hook for logging so that we can monitor invalid API
usage before we're ready to issue a warning.
I took the opportunity to update some console.warns to use the warning module
instead. The remaining console.warns
will be replaced by the warning module after we've cleaned up the callsites.
When IE8 focuses a disabled item, it throws
This makes sure the we're not focusing the item during selection restoration/autofocus when the element's disabled.
There were these two lists of JSX tools at Complimentary Tools
and Tooling Integration, that were a bit out of sync with each other.
Bring them together and add a link to the former from the latter.
Dealing with immutable data is hard. This provides a simple helper (ported from the IG codebase) that makes dealing with immutable JSON data easier. Designed to be familiar for people who use MongoDB.
This is part of what Sebastian suggested. We require it into every component that explicitly needs it and inject it as a default mixin for composite components in
the browser environment. This change frees us up to inject everything in ReactComponent.
Most of the time this is what you want to do, so I've renamed what was Simulate to be SimulateNative.
Now Simulate.change does what you expect, so this fixes#517 and fixes#519.
grep -rl 'Copyright 2013 Facebook' static_upstream | xargs perl -pi -w -e s/Copyright 2013 Facebook/Copyright 2013-2014 Facebook/g;'
Not going to check in a script to do this since it will just change every year.
Closes#1006
Fixes#1124.
I didn't add `volume` because it requires more complicated logic to control properly and I didn't add `paused` because to set it we need to call play() or pause() -- perhaps a mutation method is appropriate.
Two improvements: make sure we set `done = true` when an error message is
received, so that the test output contains the error message instead of
eventually timing out and displaying nothing useful; and increase the
timeout for this particular test from 5000ms (the default) to 20000ms.
reverts 23ab30ff87 because the issue it fixed doesn't seem to be a problem
anymore. textContent should be better for more things anyway, as the
original 309a88bcf6 indicates. It should be faster because innerText
requires layout.
This also allows us to use strings with newlines in our rendered output
and have confidence that they will render the same on subsequent
re-renders. This is especially useful for es6-style backtick multi-line
strings. This will be more consistent as textContent is supported almost
everwhere so we won't have differing behavior between webkit and
firefox.
see https://github.com/facebook/react/issues/1080
ReactDefaultPerf:
* Show times as float instead of string. This means they're sortable.
* Add count columns to all types and average to exclusive time.
* Include mountComponent where updateComponent time is measured.
* Increment count on _renderValidatedComponent instead of update.
ReactDefaultPerfAnalysis:
* Return counts with all summaries.
Split the summary functions into a separate module, and add the ability to view a lot of all DOM operations. Removed DOM timing since it was incorrect. Will potentially replace with a
dropped frame counter in the future.
This logs DOM ops for a given reconcile. Based on which components rendered and which ones *actually* caused DOM updates we can find
opportunities to add shouldComponentUpdate() methods.
Inclusive time is still not that helpful w/o looking at what actually resulted in DOM ops. However, this is better than what we have today and will serve as a building block.
I blacklisted everything but composite components -- hopefully that's OK.
The key idea here is that you're always rendering `this.state.children`, not
`this.props.children`. When combined with `cloneWithProps()` this means we can
keep them in the DOM as long as we want. We add new children and reactively
update existing ones using `setState()` inside of `componentWillReceiveProps()`
so `this.state.children` always has the latest versions of components. Since we
may be keeping old components around that are no longer in
`this.props.children` we need a way to figure out where they should be inside
of the combined `this.state.children` list. `ReactTransitionChildMapping` does
this for us.
Based on that infrastructure we can build the interface we always wanted: enter
and leave lifecycle hooks.
When a component is added to the DOM, `componentWillEnter(callback)` gets
called. Call the callback when you're done animating and `componentDidEnter()`
will be called.
When a component is about to be removed from the DOM,
`componentWillLeave(callback)` gets called. Call the callback when you're done
animating and `componentDidLeave()` will be called and the component will
*actually* be removed from the DOM. It won't be removed until you call the
callback.
These also handle "concurrent" changes. If you "stack" enter/leaves of a single
component before the animation has completed, it will block out all of those
animations until the current animation completes, and then finally it will
animate 0 or 1 times to get itself into the desired current state. This is what
differentiates `componentWillEnter()` from `componentDidMount()`.
The next step would be to build `componentDidReorder()`.
I've built `ReactCSSTransitionGroup` which is identical to the old
`ReactTransitionGroup` and codemodded the callsites.
With #1021 and #1022, I believe this makes it so React never wraps user code in a try/catch. I left in the calls to ReactErrorUtils.guard because it sounds like FB code finds them useful.
This creates a membrane around the React component prototype. It warns if you
try to access properties on the component before it's unmounted. Before it's
mounted, it should be considered a descriptor and not an actual instance.
The workaround, for unknown types, is to access the constructor using
component.type which has static methods on it.
All of this is provided by the react package now, so there's no point in having
it available in multiple places. We *may* go back on that in the future for
shipping test utils, but for the time being, this is better for all.
Also added tests for PooledClass.
Noticed that some places use `ReactReconcileTransaction.release(transaction)`, when `transaction` might be of another class, say `ReactServerRenderingTransaction` (still a Github PR). This catches that.
If a transaction wrapper's closer throws (such as flushBatchedUpdates in ReactDefaultBatchingStrategy) then we still want to properly deinitialize the transaction by setting isInTransaction to false. Without this, we can't reuse the transaction object (in this case, all future batched updates would fail because nested transactions aren't allowed).
Removed uglification for separate files since it significantly slowed down build (browserify:min became 26 sec instead of 110, same for :addonsMin) while gave economy in ~70 bytes for min+gz version.
The documentation states that React.renderComponentToString
'uses a callback API to keep the API async', but the
implementation is actually synchronous. In order to maintain
this contract the callback should always be called
asynchronously or be change to a synchronous API.
As per the discussion of pull request 982, the API should
be changed to a synchronous one.
Recently learned that components passed into `React.renderComponent` may not be the ones actually mounted. Also learned that it returns the mounted component. Added some documentation describing this.
Number('.1') === 0.1, and react uses dot-prefixed keys
for children. Whoops. Nuke the non-numeric requirement, and just
check a regex. This seems performant enough in micro-benchmarks:
http://jsperf.com/numericlike
We've been able to use `querySelectorAll` in all the browsers that we
support for some time now, but we haven't been able to test code that uses
it in the older version of `jsdom` that we were using, until recently.
Besides the general goal of modernizing our code, the impetus for this
specific change is that I'm trying to support testing without having to
render nodes into an actual document. The `.getElementsByName` method is
only defined on `document` and only works if the nodes you care about are
contained by the document.
On the other hand, `querySelectorAll` works on any DOM node, and allows a
more precise selection of just the `<input type="radio">` elements that
have the appropriate name.
IE8's implementation of `querySelectorAll` supports attribute-based
selectors, which is all we need here.
Little-known fact: instead of writing copies of compiled module files to
build/modules/, the bin/jsx-internal script actually just makes hard links
to the master versions of files in the .module-cache/, so re-populating
build/modules/ is very inexpensive.
Closes#856.
Rethrowing errors makes debugging harder. This makes it so that an exception in a render method can be caught using the purple stop sign (or the blue one, of course) in Chrome.
This codemods to shim any old-style JSX whitespace so that it renders the same as before.
Basically it sticks explicit `{' '}` spaces in where spaces are no longer implicit.
`cloneWithProps` uses `ReactPropTransferer`, which ignores the `key`
prop. See https://github.com/facebook/react/pull/713
However, this is not the case with `cloneWithProps` because when someone
is cloning a component and provides a key, they mean for the clone to
take it.
We've talked about this perf optimization for a while now. This prevents us from re-reconciling components that are above the component being
reconciled in the owner hierarchy.
See [Commoner's README.md](
https://github.com/benjamn/commoner#generating-multiple-files-from-one-source-module)
for further explanation of the new functionality.
Among other potential benefits, this upgrade allows us to generate source
maps as standalone files rather than appending them inline to every
compiled module file under `build/modules/` (see #833).
When React moved to attaching top-level event listeners on-demand, not all of the dependencies for `ChangeEventPlugin` were set. This led to `onChange` events not firing under certain circumstances. For example, listening to `onChange` on a checkbox will not work because it relies on `onClick` (unless something else on the page was listening to `onClick`).
The intention of the `npm-react/**/*` rule was to copy recursively but it would have flattened any nested directory structure. I changed the `build/modules` rule to copy recursively as well, which is necessary for `ReactTestUtils` to be able to require `test/mock-modules.js` successfully. (`ReactTestUtils` isn't included in a clean `npm-react` build currently but it will be in the future.)
This also makes running ART tests more practical.
It's only used here, so let's just inline this and get rid of the additional module.
Also it will make people like this guy happy: https://github.com/facebook/react/issues/900
(of course he might be even more happy if he wasn't using MS TFS....but that's a much bigger diff, and not one I can write...)
This diff introduces PropType.shape which lets you type an object. PropType.object was already defined and since it isn't a function I couldn't really overload the meaning to also accept a type list. Instead of doing hackery, I decided to name it `shape`.
An example where this could be used is style:
```
propTypes: {
style: PropTypes.shape({
color: PropStyle.string,
fontSize: PropTypes.number
})
}
```
Fixes#208. If you attempt a state update with a bad state then the render will fail (and the DOM won't change) but if you switch back to a valid state later then it'll rerender properly.
This is an alternative, less-invasive, fix for #891.
Test Plan:
On http://jsbin.com/OqOJidIQ/2/edit, got timings like
[75, 56, 30, 36, 27, 27, 28, 32, 27, 27, 28, 31]
instead of the old
[75, 729, 46, 32, 28, 34, 26, 27, 27, 30, 26, 26].
I also added a counter to getID and saw it was called 3014 times instead of the old 636264. (3014 is the number of nodes (3000) plus 3 calls that happen for the initial render and 1 for each of the 11 renders after that.)
add the ability for React propTypes to accept an `any` type: `someProp: React.PropTypes.any`.
This is more useful when combined with `.isRequired`, to enforce that _something_ is passed:
`someProp: React.PropTypes.any.isRequired`
Input elements of type `checkbox`, `hidden`, or `radio` can have a `value` without `onChange`. Also, if the input is `disabled`, who cares that it doesn't have an `onChange`?
This is a follow-up to #803.
In jsdom (used for internal testing), `<iframe>` does not properly create a default document. This makes the `EnterLeaveEventPlugin` tests work for jsdom, too.
Open source does not need this because it uses PhantomJS.
In b0431a5 I added the check in the wrong place which could cause the warning to be shown because of key changes rather than owner changes like the warning suggests.
This test is expected to throw but because of ReactErrorUtils.guard
which uses console.error in __DEV__ it also logged the invariant error
to the console. This change fixes it by temporarily stubbing out
console.error.
Fixes#531
Final part of server rendering cleanup. We should only support full-page rendering when server rendering is involved since
otherwise it's slow and can crash browsers when you start adding and removing document roots. This diff removes the magic
innerHTML code (since that will be handled by the server rendering piece) and adds the right assertions and errors.
Because there's no longer a dangerous of accidentally nuking the whole page, I removed allowFullPageRender which is yet another
internal we no longer need to expose.
These are dangerous from a cross-browser perspective. I think supporting efficient reactive updates will be prohibitively
expensive and we'll never prioritize it. Instead of killing this capability entirely, let's just throw on the dangerous cases.
There will be a few follow-up diffs
This ensures we don't add displayName in the transform if it's already been
defined. This is especially important when in strict mode, where duplicate
properties in an object is an exception.
Use the `clipboardData` object available on `window`, if it's not available on the event object. This allows us to support including the `clipboardData` in cut/copy/paste events in IE.
If you're writing a test that involves a mocked component that normally
returns a `<li>` tag from its `render` method as the root element, mocking
it with a dummy `<div>` probably won't work, so you'll want to set
MyListItemComponent.mockTagName = 'li';
The change to the `.mockImplementation` line makes sense because
`ConvenienceConstructor` is more or less synonymous (for these purposes)
with the wrapper that was previously used:
function() {
// This `this` used to be `null`, technically, but
// ConvenienceConstructor doesn't pay attention to `this` anyway.
return ConvenienceConstructor.apply(this, arguments);
}
This had a higher probability of collision than originally thought (bad math). This makes the strategy injectable and provies a
no-collision version on the client and an unlikely-to-collide version on the server.
what if you want to change the props of a child? This is my first attempt which lets you clone a child and transfer some custom props to it.
There is a fundamental issue with refs here. Since the component is cloned the ref will be broken. And since we can clone multiple times, it might not make sense to support repairing refs.
Fixes#767. This essentially reverts 738de8c.
We could store some sort of flag to silence the console error here but since we've made significant improvements in markup wrapping, this error is fairly rare now. We'll also have validation of node structure soon in #735.
- Add html5shiv so that HTML5 elements like header, footer, etc can be styled
- Remove a couple uses of :first-child/:last-child which IE8 doesn't support
Fixes#708.
Test Plan:
In IE9, tested a controlled text input with the event handler on a containing element, as in the fiddle linked in the original issue. Also tested a controlled radio button as the logic there differs within ReactDOMInput. In both cases, I was able to interact with the controls.
Now when a `key` prop appears, its value is always honored. This means that in the root component or as an only child, changing key will cause remounting; in a `children` object, the `key` prop will be joined with the object key to form a two-part key.
Fixes#590.
It changed React Playground to add a required props but unfortunately didn't update the call sites of the front-page. I don't think it should be required so I'm just making it optional and providing the correct default value.
Test Plan:
- Open the front page and make sure examples are working
- Open /react/jsx-compiler.html and make sure it is working
- Open /react/html-jsx.html and make sure it is working
Since we can use props to pass React Components, we should have a better way of validating these props than just `object`. Having a prop type `component` will allow us to safely assume that the passed prop IS a component.
This is a follow-up the to previous commit and does two things:
- Moves `ReactMount.ATTR_NAME` to `DOMProperty.ID_ATTRIBUTE_NAME`.
- Adds `DOMPropertyOperations.createMarkupForID` and uses it.
We have this really nice method for safely creating markup for an HTML
attribute, `DOMPropertyOperations.createMarkupForProperty(...)`. Let's
use it to create the ID attribute markup, too.
These should be included so that anybody can build and update the docs
with as little confusion as possible.
I've left the directory in .gitignore so additions need to be
intentional as part of a release.
This reduces the time taken by `grunt populist:test` from 7s to 550ms,
which should make @spicyj especially happy.
Relevant commits from the `populist` and `ast-types` repositories:
9863ad16c0dabef2a4ac
This fixes merging of `propTypes`, `contextTypes`, and `childContextTypes` so that we actually merge (instead of only taking the component or last mixin).
Using props to initialize state is completely fine; the issue is using state as a "cache" for values calculated based off of props. This title makes it more clear.
Chrome gives the warnings
```
body.scrollLeft is deprecated in strict mode. Please use 'documentElement.scrollLeft' if in strict mode and 'body.scrollLeft' only if in quirks mode.
body.scrollTop is deprecated in strict mode. Please use 'documentElement.scrollTop' if in strict mode and 'body.scrollTop' only if in quirks mode.
```
the first time getUnboundedScrollPosition is invoked. This fixes it. (All modern browsers support `pageYOffset`; IE 8 doesn't but works properly with `document.documentElement.scrollTop` except in quirks mode which React doesn't support.)
In the case of having an animated node which is, after the leave-transition has been activated, then re-added in a render call causes React to 'break'. This is especially noticeable if you spam to removal and re-addition of an item in a ReactTransitionGroup.
This fix simply stops the leave transition and restarts the enter transition.
This reverts https://github.com/facebook/react/pull/576
This approach mutates the default props for the instance on each update,
which causes incorrect behavior. discussed with @balpert. can look into
cloning but this unbreaks.
This leaves statics as a way to define static methods and properties
that will be accessible on the return value of `React.createClass`
without changing the current spec.
It is valuable to know when the number of children in a TransitionGroup is going
to increase or decrease, since we might want to apply extra animations.
For instance, when used with overflow:auto, we might want to apply different css
based on it overflowing or not - to do this we need to calculate this after new
nodes has entered and after nodes has been removed.
This moves the static properties off of the root object and into
a 'statics' property. Then they are made available on the constructor so
they can be used directly and in mixins.
Pull request #526 updated the behavior of vendor/constants.js without
changing any source files or the bin/jsx-internal script, so files that
should have been rebuilt (like utils/__tests__/ImmutableObject-test.js)
were not automatically rebuilt (unless you knew to do `grunt clean` or
`rm -rf .module-cache` manually).
This commit allows us to bump a version number when we know the transform
toolchain has been altered in a way that will not be visible to
commoner/jsx.
With this convention, if we reset to an older revision (e.g. during a git
bisect) and the appropriate cached module files are still in the
.module-cache/, they can be used without rebuilding. That's why I prefer
this approach to just deleting the .module-cache/.
Closes#104.
Closes#496.
Closes#530.
Summary:
e.g.
propTypes: {
foo: React.PropTypes.oneOfType([
React.PropTypes.string,
React.PropTypes.number
]);
}
to do this, I exposed a `.weak` chainable validator that returns instead of throws, e.g.
React.PropTypes.string.isRequired.weak
React.PropTypes.string.weak
which returns true or false. Technically, `React.PropTypes.string.weak.isRequired` also exists, but `oneOfType` will never call it. Might be useful to people creating custom validators though.
Since we use keyMirror() and invariant() messages are only shown in __DEV__, we don't have to do manual constant->string translation. Also fixes a few
undefined keys that just happened to work before.
It doesn’t make much sense to generate a random key for each todo render, because it will re-draw all todo’s DOM nodes on each model change. I changed it to the unique identifier ``todo.cid`` already supplied by the backbone model.
benjamn/commoner#44 fixed commoner to work on Windows when module path relativization isn't used; with this, the `jsx` binary should work properly on Windows (though `jsx-internal` still won't).
Fixes#316, fixes#391, fixes#567.
As an added bonus, the jasmine web interface now groups tests by file.
Test Plan:
grunt test passes on b2507066, the parent of 566f8b2e (which committed a workaround for buggy module mocking).
We can already access the DOM node using `this.getDOMNode()`. Passing it as an argument was a bad decision.
Previous API:
```
componentDidMount(DOMElement rootNode)
componentDidUpdate(object prevProps, object prevState, object prevContext, DOMElement rootNode)
```
Next API:
```
componentDidMount()
componentDidUpdate(object prevProps, object prevState, object prevContext)
```
callbacks like shouldComponentUpdate, componentDidUpdate, etc. were getting the full, unsanitized context, instead of the one that's been filtered down to only the fields allowed to be visible by contextTypes.
Context is adding another argument that shifts all of them by one. Since we can already use this.getDOMNode(), it doesn't really make sense to pass it as an argument to that function.
Depends on #575; fixes#570. Now we'll be in trouble if someone tries to share objects between calls to getDefaultProps but that was already true of getInitialState and I haven't heard any complaints there.
This is the same number of allocations as before; we're just copying props in the other direction. (In any case, the copy happens only on mount and there are a couple dozen costlier things we're doing already at that time.)
This module-level mock() seems to have been interfering with other tests (26 specs failing). We don't have any other tests that do a module-level mock() so I'm going to assume it isn't supported in the open-source test runner right now. I changed it so only ReactEventEmitter.handleTopLevel is mocked; doing so made ReactEventEmitter complain that TopLevelCallbackCreator wasn't defined so I switched the ReactMount references to use React directly so that ReactDefaultInjection would kick in properly.
With this, all the tests pass.
...without preventing clicks on other things.
Just use an `<a name="...">` tag that doesn't take up any space to make sure that we're not covering up something else.
For whatever reason, doing `position: relative; top: -$navHeight;` doesn't work and causes the anchor target not to be moved up. This solution works in both Chrome and Firefox.
When events are captured, the nearest React-rendered ancestor is found and events are propagated to its tree. This causes issues when components are nested as only the innermost component receives the events.
This change modifies this behaviour so events propagate all the way up the DOM hierarchy. To reduce the performance cost, this DOM traversal is only done if the component is actually nested (determined by the `containerIsNested` map which is lazily initialised).
Summary:
adds `this.context` which you can think of as implicit props, which are passed automatically down the //ownership// hierarchy.
Contexts should be used sparingly, since they essentially allow components to communicate with descendants (in the ownership sense, not parenthood sense), which is not usually a good idea. You probably would only use contexts in places where you'd normally use a global, but contexts allow you to override them for certain view subtrees which you can't do with globals.
The context starts out `null`:
var RootComponent = React.createClass({
render: function() {
// this.context === null
}
});
You should **never** mutate the context directly, just like props and state.
You can change the context of your children (the ones you own, not `this.props.children` or via other props) using the new `withContext` method on `React`:
var RootComponent = React.createClass({
render: function() {
// this.context === null
var children = React.withContext({foo: 'a', bar: 'b'}, () => (
// In ChildComponent#render, this.context === {foo: 'a', bar: 'b'}
<ChildComponent />
));
// this.context === null
}
});
Contexts are merged, so a component can override its owner's context **for its children**:
var ChildComponent = React.createClass({
render: function() {
// this.context === {foo: 'a', bar: 'b'} (for the caller above)
var children = React.withContext({foo: 'c'},() => (
// In GrandchildComponent#render,
// this.context === {foo: 'c', bar: 'b'}
<GrandchildComponent />
));
// this.context === {foo: 'a', bar: 'b'}
}
});
Reported on Twitter by AirBnb (who are integrating React into their open-source JS framework). They made a mistake and passed a string in as the
component. We should have a better error message for that.
This renames receiveProps and changes it to take the next component to copy props from instead of just the props. That is,
component.receiveComponent(nextComponent, transaction)
instead of
component.receiveProps(nextComponent.props, transaction)
This is a precursor to adding contexts, which will also need to get propagated just like props. This change allows ReactCompositeComponent to override `receiveProps` and do something like
this._pendingContext = nextComponent.context;
Most notably, this new style of transformation gives us access to
this.parent.node, which allows us to avoid replacing identifiers that are
not actually free variables, such as member expression properties.
Closes#496.
Two of your tests were failing because of commit
1e71df5399
I fixed them by:
1) Using jasmine's spyOn in ReactCompositeComponentError-test.js
2) Inverting the function wrapping in the above commit.
Godspeed.
- Overview of add-ons for the add-ons page.
- Better title for `ReactLink`.
- Nicer code format for classSet example.
- Better explanation for `classSet`.
When we determine whether a React component should be updated (as opposed to destroyed or replaced), we currently only look at whether they share the same constructor. This adds a check for whether they share the same owner component.
I've also consolidated this logic (I cannot believe this was not already done).
dataType was unnecessary; mimeType was both unnecessary and wrong in this case. Also removed an unnecessary bind and changed pollInterval to 2000 ms for consistency with https://github.com/petehunt/react-tutorial (faster is nicer if you actually try it out!).
IE 11 no longer supports the legacy document.selection API.
Their implementation of window.getSelection() doesn't support
the extend() method, which we were relying on.
If the selection is RTL and selection extend is missing, then just
flip the selection.
The initial thought was that an opacity animation from 0.01 to 1 causes trouble on some browser. But after testing on opera 12.15, ff 23, ie 10, chrome 30, desktop/mobile safari 7 and chrome android I confirm this works.
Newer versions of WebKit and Blink will support both `document.body.scrollTop` and `document.documentElement.scrollTop`. Therefore, implementing cross-browser compatibility by summing the two will no longer work.
This changes React to use `getUnboundedScrollPosition` so we get the fix and consistency in one change!
See: https://rniwa.com/2013-10-29/web-compatibility-story-of-scrolltop-and-scrollleft/
- No need to mention React, you know you're working with it =).
- Wrap code elements in back ticks, so that they get the "box" styling for md.
- You'd want the snippet to work inside the live editor, so you need to `renderComponent`. As per wiki specification, the DOM element on which to mount is `mountNode`, just like on the front page.
- Don't forget the JSX pragma, or else your `render` fails.
- Nitpick: empty line after the end of md.
- No need for jQuery reference since
1. The general mood around React is that you don't need jQuery.
2. The syntax' still clear without jQuery.
3. We're doing a jQuery integration entry =).
- `getInitialState` was absent.
- You don't need `componentWillMount` here. fetch them in `getInitialState`.
- The non-spoken convention seems to call the event handler `"handle" + eventName`. So `handleResize` clearly indicates it's a `resize` handler while `updateDimensions` might do something else. This latter name might actually be better under circumstances where you use call the method directly somewhere, but since we removed the only direct usage in `componentWillMount` this is fine.
- Went OCD again and tried to keep the code short. `width` is enough of a demo. Removed `height`.
- Distinguish between DOM events and React events. Wish we go full React events in a near future.
When a ReactDOMComponent is created with the property `disabled: true` subsequently setting the property to `disabled: false` the HTML attribute `disabled="true"` was being left in the DOM.
If we are to unmount a component mounted into a document element we should
unmount it from document.documentElement and not from document.firstChild which
is a doctype element in this specific case.
Fixes#447.
We do this by moving the actual anchored element up in the page without moving the actual text. (Apple uses a similar trick in their framed docs.) Now this looks a bit sillier on smaller screens but it's better overall.
Currently, default props as defined by `getDefaultProps` are only used if a prop is not specified (using `X in Y` check).
However, this makes it difficult for composing components to pass along the state of not being defined, for example:
render: function() {
// If `this.props.someProp` is not set, `InnerThing` should use the default value.
return <InnerThing someProp={this.props.someProp} />;
}
This changes the requirement for falling back to the default value to an undefined check (using `typeof X === 'undefined'`).
Remember that one time I wrote release notes and said:
> This is a breaking change - if you were using class, you must change
> this to className or your components will be visually broken.
Good thing I didn't listen to myself!
We had something that did the same sort of protection. The module
differs slightly (returns document.body instead of undefined) but
looking at the callers, that should be ok.
Allow more than strings and numbers to be used as attributes for DOM
nodes. This removes the special casing for `0` and `false` that was
being used in ReactDOMInput and ReactDOMTextarea.
Now we will just `toString` any object we try to insert into a DOM.
Closes#422, #372, #302
`jsdom` behavers differently than browsers here and we should ensure
that we are consistent. Browsers should be (and are) converting to
a string first, while `jsdom` doesn't.
Forcing wrapping seems necessary here: I compared a <circle> created within a <div> with a <circle> created inside an <svg> and they appear to have exactly the same properties with the exception of .parentNode (and .parentElement), yet the former refuses to show up when appended to an <svg> element. As such, I can't find any useful way to write a unit test (testing getMarkupWrap's output doesn't seem particularly useful to me).
Fixes#311.
Test Plan:
With a component that adds a <circle> after mounting (such as http://jsfiddle.net/spicyj/hxFVe/), verify that the circle appears in both Chrome and IE9.
The injection was only evaluated when ReactCompositeComponent was first loaded.
This made it impossible to inject a custom measure and the injection pointless.
Test that React loads properly in a web worker.
Most of this code is open source-only, so I think it's safe to merge without figuring out how to translate it upstream first.
This creates a new standalone build which should have everything the
default build has, plus a little extra. This is not a sustainable long
term solution (we shouldn't make people choose like this) but it fixes
the problem we have in the short term.
This also removes the terrible react-transitions build. This is better
anway.
Fixes#369
There were 2 issues:
I was reusing event outside the original event handler (activeNativeEvent).
This is a bad idea. I've changed deferred dispatch to have an empty object
as the nativeEvent.
I didn't handle inputs without .selectionStart (e.g. file inputs). I extracted
a input type check from ChangeEventPlugin and reuse it here.
This is dangerous because it means that data is flowing into the component from two components, only one of which is the actual "owner". While we may be able to figure out how to
support this someday, let's be strict and prevent it for now.
Polyfill 'onSelect' behavior for React.
Use non-standard 'selectionchange' event rather than 'select' event.
This allows us to fire the event when user moves the cursor via arrow
keys, and not just when they select multiple chars.
Add methods to ReactDOMSelection to make getting current selection
easier, so we can do a fast check for change without having to
calculate char offsets for selection start and end.
Exposing the _renderedChildren property before all the children are fully
mounted. This allows us to debug a partially mounted tree when the debugger
has a breakpoint in the one of the mounting children.
This only has a functional difference in the case where mounting throws. This
will end up not mounting the component anyway. Any remounting shouldn't be
affected by this change.
Setting the `eventName` attribute of an element to the empty string is not
enough to cause `typeof element[eventName] === 'function'` in jsdom. The
attribute value actually has to look like a function body.
If we reconcile components higher in the hierarchy they will likely reconcile components lower in the
hierarchy. If we sort by depth then when we reach those components there will be no more pending state or
props and it will no op.
The spec for eval (http://es5.github.io/x15.1.html#x15.1.2.1) says "If Type(x) is not String, return x." and that's exactly what's happening here -- it gets {code: ...} and does nothing.
This introduces `ReactLink` which is a super lightweight way to do two-way binding for React.
If you want to use a controlled form input today, it's a lot of lines of code:
http://jsfiddle.net/T3z3v/
Look how many times `name` is repeated in there. And you have to remember to wire up event handles and pass the right state and
right event handler for *each* form field. It's really annoying.
With ReactLink, you can "link" a form value to a state field. It's just some simple sugar around the value prop/onChange
convention:
https://gist.github.com/petehunt/6689857
Ah, much nicer! And requires very little core changes or extra bytes. `ReactLink` just wraps the current value and "request
change" handler into a little object and provides some sugar to create some from composite component state.
Move compositionstart/compositionend to a new event plugin.
Add a polyfill that listens to key and mouse events and uses selection to
determine which text has changed.
Add a DOM based selection module. This can both be used on its own and
in ReactInputSelection where our current implementation is lacking.
There is still some inconsistency with how IE and modern browsers
handle block nodes. Should be OK if we are just getting and setting
and not trying to set selection based on character offsets.
This gives markdown headers an id so that we can link directly to
sections of our docs. This is better than the alternative of adding them
all ourselves.
In the IE code path the method assumed that the input.value property
was non-null. A quick fix is to use either value or innerText; which means
the same code can be shared for textarea and contentEditable components.
The code is slightly buggy because the range.parentElement() !== input check
will fail for contentEditable components when the focus within a deep DOM tree.
The selection object doesn't always have ranges. In Chrome the
selection is not updated before 'focus' event handlers are fired. See
http://jsfiddle.net/t4DYA/ for example.
The selection will have rangeCount of 0 and calling getRangeAt(0) will
throw error "Uncaught IndexSizeError: Index or size was negative, or greater
than the allowed value."
This isn't really ideal, but it makes it so that people managing to
build with @providesModule still get a consistent experience (since this
is what gets packed client-side with react-page-middleware anyway).
I am unsure how this was ever supposed to work, as testDocument is guaranteed to be undefined at that point since beforeEach doesn't run synchronously. (I don't think there's any way to have beforeEach halt the tests.)
Previously, setting textarea `value` to number 0 is treated as if `value` wasn't set at all (thus the textarea is cleared from 0 to '' upon `onChange`). `false` also renders as `"false"` instead of `""` for both `defaultValue` and `value`, on textarea _and_ input.
Created a .mailmap file with all of the associations, then used
git + perl to create the AUTHORS file. In theory these should all get
picked up by npm.
I used ABC order so it would remain unbiased and automatable. I wish we
could go back and fill out the history or at least fix the commits we
have from CommitSyncScript, but oh well.
This also includes the script I used to automate this process in the
future.
It seems like the `form="pluto"` was throwing it off and making the input live outside the form it should have been contained in, causing it to uncheck A. I added it intending to test the form attribute but ended up not needing it so removing it should be fine. (The tests were passing in phantomjs since it doesn't support the `form` attribute and simply ignored it.)
Test Plan:
grunt test; grunt test --debug
Add clipboard events to React.
For forms, these shouldn't really be necessary -- the onChange event should handle deletions and insertions. For contenteditables, however, we need to be able to access clipboard data.
getConfig needs to be a function because grunt.config.data.pkg.version isn't available at the time that grunt/config/jsx/jsx.js is required.
Test Plan:
grunt build, grunt lint, grunt test all work. After building, both react.js and react.min.js contain the version number.
Closes#271.
All three of these files are DOM-specific so it should be fine to use window. (ReactEventTopLevelCallback isn't obviously DOM-specific but it calls getEventTarget which is so I think we're fine here.)
Test Plan:
grunt test, tried events in a real browser and they seemed to work still.
Jordan warned (and StackOverflow confirmed) that IE8 doesn't respect HTML
comment nodes when setting `.innerHTML`:
http://stackoverflow.com/questions/15006001/inserting-a-comment-in-innerhtml
The virtue of the comment strategy was that the parser did all the work of
maintaining the boundaries between markup chunks, using comments as the
boundary markers. The new strategy (of tagging the first node with a
special attribute) has a similar virtue, since the parser should preserve
that attribute only for the nodes we care about, and any rendered nodes
that do not have the attribute can be ignored (and complained about by
`console.error`).
Logging every unknown property got very noisy when combined with use of `transferPropsTo`. I knew this would be a potential issue initially but decided it was worth it. Others disagreed and it's resulting in some confusion.
This changes the logging to ensure that we have a potential correction, so only DOMish properties should result in warnings.
Sencha says that separating big components into their own iframes was important for performance:
http://www.sencha.com/blog/the-making-of-fastbook-an-html5-love-story.
Today the only thing stopping us is that events don't bubble to our events system from an iframe. This diff
looks at the owning document of the container and adds top-level listeners to it. It should not change
existing behavior and should improve our support for this.
This builds `ReactTransitionGroup` with it's own copy of `React`, which
it total clownshoes. This should be technically usable, but definitely
should not be used in any production environment.
Fixed:
- New todo not submitting correctly (page refreshes. `preventDefault`
wasn't there.
- Old checked todo being removed will leave the checkmark on the next
todo replacing its position.
- Cannot change todo (`value`'s now a controlled field).
- `autofocus` (should be `autoFocus`, how ironic given the current
situation) on new todo input isn't working. Switched to manual
`focus()` in `componentDidMount` for now.
- More consistent breathing space between lines.
- Gutter at 80.
Added:
- Use todomvc-common base.css. The old one had to change ids to
classes. No longer necessary.
- Give `cx` a better name and move it in `Utils`.
- Trim input upon finishing edit.
- Remove todo if the new edited value is empty.
- Submit edited todo value on input blur.
- README to explain the existence of this example. Being able to
maintain a non-compilant version allows nice deviations from the
todomvc specs, such as animations, in the future.
We will continue using `bin/jsx-internal`, well, internally.
Note that this version no longer respects `@providesModule`, and it
doesn't do anything special with constants like `__DEV__`, so we can no
longer get to claim that `bin/jsx` can be used to build the core.
I'm happy about this, personally, because it demonstrates the flexibility
of Commoner.
This was apparently only partially supported. We had issues initially mounting if there was no HTML present and
also had issues if we had to update HTML that was already there. This diff fixes all of these cases and has
tests to prove it. NOTE: I removed a test that was actually erroneous. My bad.
HTML comment nodes are now interspersed in the original markup list so
that we can tell which chunks of markup rendered as more or less than one
node, and give a more helpful error message in that case.
Regardless of how many nodes were rendered, we only take the first one. If
zero nodes were rendered, then `resultList` will contain `null` at the
corresponding position.
If we decide to revisit the idea of using document fragments, it will be
very easy to handle the `!== 1` case by returning a document fragment.
This introduces <ReactTransitionGroup>, a component that works a lot
like Angular's ng-animate.
The problem we're currently facing is twofold:
1. We don't really have a great convention surrounding CSS transitions
in React
2. (harder) we can't animate nodes that are leaving the DOM, as their
nodes are instantly destroyed.
To solve the first issue I've adopted Angular's convention. It's
implemented in ReactTransitionableChild.
The second part is what's tricky. To do this I've implemented three modules:
- ReactTransitionableChild, which can keep its old children around if they
change to null
- ReactTransitionKeySet, which can look at a prev and next set of child
keys and merge them in a reasonable way
- ReactTransitionGroup, which combines ReactTransitionableChild and
ReactTransitionKeySet to keep nodes that are leaving the DOM in the
DOM until their animations are complete
Summary:
- Weren't pooling the Transaction in the batching strategy
- Creating a new closure for every event tick due to batchedUpdates()
- EnterLeaveEventPlugin creates a new array on each event.
I wonder if there is more optimization opportunity in accumulate(). Squinting at the fps graph this seems to be faster and waste less memory but it's hard to conclusively tell. I did verify that these were all hotspots though.
I've hit this a few times where I want to get to docs so I take whatever
my urlbar gives me and strip out the actual page so I can get to the
root, however that's a 404.
This introduces a super easy way to redirect, which could be handy in
the future as docs get rewritten.
I would much rather do this with a real htaccess file or even just
handle 404s gracefully, but that's not currently an option with GitHub
pages (since we generate our own and don't use a custom domain).
We need access to the instance cache for debugging tools. Ideally we want to
expose a more stable and supported interface but this seems like a quick win,
for now.
Sometimes you may need to detect if a value is a valid React class constructor. This enables that and prevents future consumers from getting caught in the trap of depending on an internal implementation detail we might change.
Currently this works for classes created with `React.createClass` as well as `React.DOM.*`.
This adds a `ReactDOMButton` module that shims the native `<button>` React component so it doesn't receive mouseup, mousemove, mousedown, click, or double-click events when its disabled property is truthy.
Today mixins can't easily be stateful because they can't provide getInitialState(). This allows multiple getInitialState() methods as long as they don't return objects that have conflicting keys. In that case, we throw.
`content`, `httpEquiv`, `charSet` are all needed. We're currently
working around this in `react-page`.
`content` is the risky one here since we previously supporting using
`content` to set the text content. We removed support for that in
e998041229 so the risk is minimal, there
just might be some lingering old code.
Fixes#292
Test Plan: Visit `data:text/html,<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8" charset="utf-8"></head>`
```
var m = document.querySelector('meta');
m.httpEquiv; // Content-Type
m.httpEquiv = 'foo';
m.httpEquiv; // foo
m.charset; // undefined
m.charSet; // undefined
m.getAttribute('charset'); // utf-8
m.setAttribute('charset', 'bar');
m.getAttribute('charset'); // bar
m.content; // text/html; charset=utf-8
m.content = 'baz';
m.content; // baz
```
- Add pagination
- Display full content in /blog
- Truncate Recent posts
- Add permalink that lists all the blog posts
- Add spacing and bullet around recent posts to make it more readable
There are certain cases where you can end up with a collision with an implicit
key (array index) if your explicit key prop is a number. They should use
different namespaces. Therefore I wrap explicit keys in curlies and implicit
array indices in brackets.
I added a simple test case, but another case came up on the mailing list. Where
undefined entries in an array actually results in an entry and therefore an
implicit key.
Summary: Allows rendering of React into the "document" as opposed to into a
particular node. To recap some basics:
document: One level above the <html> tag - like the browser.
document.documentElement: <body>
To support full-page server side rendering, we need to be able to render
*everything* including the HTML/BODY tags. This allows that.
Closes#250.
Test Plan:
With multiple and not, verified: With defaultValue, the correct option is picked initially, user changes change the selection, and changes to defaultValue have no effect. With value, the correct option is picked initially, user changes do nothing, and changes to value change the selection.
Also ran the tests.
Many of React's util functions are non-redundant with Facebook's core
libraries, so move them out of React into a central location (out of
this repo).
These files were not getting used by any part of React core, so didn't
actually belong here anyway.
Instead of changing `traverseAllChildren`, keep that around for perf
reasons (for the hot code path `flattenChildren`)
Introduce `ReactChildren.map` and `ReactChildren.forEach`
which mirrors `Array.prototype.map` and `Array.prototype.forEach`. This
involves a rename of `mapAllChildren`
This fixes a reconciliation bug introduced by adffa9b0f4.
The new unit test case exhibits the bug. When a component that has rendered child components is updated to render inline text, we usually:
# Unmount and remove all child components.
# Set the new inline text content.
However, with batched child operations, we do not **remove all child components** until later. The current implementation will set the inline text content and blow away those nodes, causing a fatal when `ReactMultiChild` later tries to find and remove those nodes.
This fixes the bug by ensuring that text content changes are also enqueued.
The original tests were flawed because the `Danger` module exploits the fact that all React-generated markup has at least one attribute. This allows the module to extract node names from markup strings faster.
However, the tests were passing in strings of markup with no attributes.
Also, this fixes a test failure due to the test trying to set text content into a `<tr>` which is typically disallowed by browsers (and PhantomJS). This changes it to use `<td>` instead.
Not all testing environments will support setting the `innerHTML` descriptor. For example, PhantomJS initializes the `innerHTML` property as not configurable.
Setting `innerHTML` is slow: http://jsperf.com/react-child-creation/2
This reduces the number of times we set `innerHTML` by batching markup generation in a component tree.
As usual, I cleaned up the `ReactMultiChild` module significantly.
== Children Reconciliation ==
When a `ReactNativeComponent` reconciles, it compares currently rendered children, `prevChildren`, with the new children, `nextChildren`. It figures out the shortest series of updates required to render `nextChildren` where each update is one of:
- Create nodes for a new child and insert it at an index.
- Update an existing node and, if necessary, move it to an index.
- Remove an existing node.
This serializable series of updates is sent to `ReactDOMIDOperations` where the actions are actually acted on.
== Problem ==
There are two problems:
# When a `ReactNativeComponent` renders new children, it sets `innerHTML` once for each contiguous set of children.
# Each `ReactNativeComponent` renders its children in isolation, so two components that both render new children will do so separately.
For example, consider the following update:
React.renderComponent(<div><p><span /></p><p><span /></p></div>, ...);
React.renderComponent(<div><p><img /><span /><img /></p><p><img /><span /><img /></p></div>, ...);
This will trigger setting `innerHTML` four times.
== Solution ==
Instead of enqueuing the series of updates per component, this diff changes `ReactMultiChild` to enqueue updates per component tree (which works by counting recursive calls to `updateChildren`). Once all updates in the tree are accounted for, we render all markup using a single `innerHTML` set.
There is a circular dependency between `ReactID`, `ReactMount` and
`ReactInstanceHandles`. Ben and I talked about this today. It seems like the
simplest solution is to consolidate a lot of the code that Ben recently wrote
into `ReactMount`. We can later find ways to trim code out of this module
without causing circular deps.
As @leebyron and balpert pointed out, if the markup on the server is differnet than what the client expects undefined behavior and chaos may ensue. A good fallback
is for us to just inject the client-side markup (as it is the source of truth) and warn the user in __DEV__ that something is wrong. In order to do a fast
browser-independent check of the DOM I use an adler32 checksum of the generated markup. I believe this is better than a simple innerHTML compare because different
browsers massage innerHTML differently.
This works around a bug with listening to clicks using event delegation on Mobile Safari using an event plugin.
NOTE: We don't enable touch events by default, so I don't know if would want to inject this plugin by default. In fact, I'm not sure what our strategy is at all for when to invoke `React.useTouchEvents(true)`.
We already skip `null` and `undefined` when building up the stringified html on first render, but if you update a component to the *exact same* conditions, React will leave the DOM in a different state. We shouldn't do that.
This was not necessary when we were running each test in its own
`<iframe>`, and it doesn't seem to affect any test behavior currently, but
it seems wise for the sake of test isolation and hygiene.
We don't sync upstream polyfills (because we don't have a story for how
they would be used), so this needs to be updated manually.
Sacrificed some negligible performance optimizations to reduce the number
of different cases from four to one.
It's important to test this implementation in PhantomJS, since that's the
only browser that I know of where built-in functions sometimes do not have
a `.prototype`.
This cuts the running time of `grunt phantom:run` from 4.4s to 3.1s on my
machine, because we no longer have to load/execute a separate instance of
`react-test.js` in a separate `<iframe>` for each test.
getConfig needs to be a function because grunt.config.data.pkg.version isn't available at the time that grunt/config/jsx/jsx.js is required.
Test Plan:
grunt build, grunt lint, grunt test all work. After building, both react.js and react.min.js contain the version number.
Here are some ideas that I think work better:
- 15 repetitions of "React". Removed a few.
- The "two main ideas" weren't clearly separated. I put them under different headers and simplified the wording.
- The "Give it Five Minutes section didn't sound as reassuring. Made it sound more certain.
This is still the same amount of duplication, except way easier to
parse. Docs nav now lives in `_config.yml` and you must restart jekyll
to see changes to that list (since config is only read at jekyll launch)
This will let us keep docs in order on the filesystem but have
reasonable permalinks. If we add something at 02- it doesn't result in
lots of broken links.
A silent upgrade from graceful-fs v1.2.2 to v1.2.3 (a dependency for both
Commoner and Populist) broke the build process, even though tests were
still passing. The 2.0.0 version fixes whatever was broken, though I won't
pretend to know exactly what the root cause was.
We're using populist for building the bundle of test modules and their
dependencies, so it seems worthwhile for consistency to do the same for
the test harness.
It's not always possible to update `rootElementsByReactRootID` when the
contents of the container are re-rendered; for instance, when we call
`dangerouslyReplaceNodeWithMarkup` or `dangerouslySetInnerHTML`. Since
this bookkeeping is just trying to warn about potentially problematic
manipulations of the root element, and we can be relatively sure that a
new element with the same ID is logically the same element, this diff
avoids warning in such cases.
This fixes known browser bugs with rendering markup using `innerHTML` in IE ([[http://support.microsoft.com/kb/276228 | here is an example of one]]).
This is a subset of what `HTML` (and jQuery) does, and we should eventually consider pulling it out into a separate module to reduce code duplication. For now, this is the minimal set of changes needed to unbreak React in production.
We can afford to use a subset of what `HTML` does because we have the luxury of knowing that the markup is generated sanely with proper closing tags, etc.
This implements a `<select>` component that supports `value` and `defaultValue`. It also changes `<option>` to warn when the `selected` prop is supplied.
Use the new `traverseChildren` utility to perform `mapChildren`.
The goal is to get as close to the bavior of the semantics of
`Array.prototype.map`, but also in a way that understands deeply nested arrays
and objects.
Biggest win here is that we'll strip out the console.error from
EventListener and we won't need to suggest people use a console
polyfill with the minified build.
No longer injecting __MOCK__ as a global constant (it's just a config
property now).
Turns out the `grunt jsx:debug` task was never necessary for tests.
When require("mock-modules").dumpCache() is called, all mock functions
previously created continue to refer to the old dirtyMocks array.
If we replace that array with a new one, those mock functions will never
have their .mockClear() methods called again.
The upstream version of mocks.js pulls a similar global trick, and I never
understood why until now.
We don't currently attempt to mock modules automatically, but we do
respect require("mock-modules").mock, .dontMock, and .dumpCache.
I'm going to keep investigating auto-mocking, since that would move us
much closer to the behavior used within Facebook.
Closes#154.
Closes#155.
This reverts commit dd1d49b360.
The license is actually supposed to look like that. That section is
boilerplate for others to apply the license to their own work. See
immediately above...
> To apply the Apache License to your work, attach the following
> boilerplate notice, with the fields enclosed by brackets "[]"
> replaced with your own identifying information. (Don't include
> the brackets!)
This fixes two bugs related to string-casting in React:
# Setting `<input value={0} />` would use an empty `value` because `0` is falsey.
# Using `onChange` and `setState` with non-strings could lead to an infinite loop.
The latter is possible with controlled inputs when:
- User changes input value.
- `onpropertychange` fires.
- `ChangeEventPlugin` dispatches `onChange`.
- A handler responds via `this.setState` with a non-string value (e.g. a number).
- The input re-renders and re-sets `value`.
- The new `value` is not a string, but the current `value` (read from the element) is cast to a string automatically by the browser.
- This triggers another `onpropertychange`.
- `ChangeEventPlugin` dispatches another `onChange`.
- ...
This is a bit unfortunate, but it'll shut lint up for the time being. We
can't just change the modules to use `module.exports = { ... }` due to
how we handle circular dependencies internally (`ReactMount` require
`ReactID` and vice versa).
When each component unmounts, it already cleans up its respective entry in the node cache. Let's stop blowing away the entire node cache unnecessarily.
This should improve performance because a React component's root will never need to be searched for more than once.
This is a micro-optimization that reduces the lookup time for missing lifecycle methods. The extra amount of memory is linear to the number of components that exist on a page which I think is a worthwile trade-off.
When `ReactNativeComponent` updates, it calls `updatePropertyByID` in `ReactDOMIDOperations` which calls `DOMPropertyOperations`. However, in `ReactDOMIDOperations`, we will lookup the node for an ID using `ReactID.getNode`. This wastes time looking for nodes when we may not need to ever update it (e.g. `children`).
This changes `ReactNativeComponent` to bail out sooner.
This adds two new warnings and one new invariant:
- Warn when using React.autoBind() that it is deprecated.
- Throw when calling bind() on an autobound method with the wrong value of "this". Today we'll silently ignore the provided value, which is confusing.
- Warn when calling bind() on an autobound method with the *right* value of "this" and no other arguments. This is already done for you by React.
There are other changes I'm sure but the most important is that module
sorting results in deterministic builds.
The biggest win here comes for releases. Previously we had to jump
through hoops to make sure the files we put in bower were the same files
we put on the CDN, were the same files packaged in the Ruby gem, were
the same files we packaged into a zip file, were the same file we used
when create PRs to CDNJS. Rebuilding docs also resulted in conflicting
versions so we had to be careful when committing. This takes away all of
that pain. We can build from the same revision and get the same files.
We're missing a bunch of elements. So I scraped them from https://developer.mozilla.org/en-US/docs/Web/HTML/Element. Here's the script I used (run from Firefox scratchpad):
```
Array.prototype.slice.call(document.querySelectorAll('div.index.widgeted li'))
.filter(function(li) {
return !/deprecatedElement|obsoleteElement|nonStdElement/.test(li.firstChild.className)
})
.map(function(li) {
// <tag> -> tag
return li.querySelector('code').textContent.replace(/<(.+)>/,'$1');
})
.join(': false,\n ');
```
I had to filter a couple more out (because there's some malformed content), but then it was simply merge with what we had and check to see if the new ones needed to omit the close tag.
This fixes our perf test by coping with edge cases like the
injection of `<tbody>` between `<table>` and `<tr>` nodes, which occurs
automatically in some browsers when we set `.innerHTML`.
Introducing more search branches would be risky if not for my previous
commit that made `findComponentRoot` breadth-first instead of depth-first.
This function needs to be as fast as possible for those cases when
`ReactID.getNode` can't rely on the `nodeCache`.
Breadth-first search prevents us from diving too deeply down the wrong
branches when the sought-after node can be found at a shallower level.
The queue required for breadth-first search is implemented by a single
array indexed by `childIndex`. To save space, only the `.firstChild` nodes
are stored, and we use `.nextSibling` to iterate over the other siblings
in a `while` loop.
When we render a new component into a container, we now record a reference to the rendered DOM node as `rootElementsByReactRootID[reactRootID]`, so that we can determine the actual container later on, in case `containersByReactRootID[reactRootID]` is no longer the true container.
If any component throws during reconciliation any subsequent reconciliation will break badly because ReactUpdates will be in an inconsistent state.
Add a finally block to prevent this.
Whenever a component is unmounted, we delete all listeners that might have been attached. This sucks because most applications, Facebook included, do not use every listener. There's a lot of wasted computation, especially if many components are mounted and unmounted.
This changes `deleteAllListeners` to more delete listeners more efficiently.
This fixes a bug with `ChangeEventPlugin` in IE8 and IE9. The extend of this bug includes:
- On IE8, not firing `onChange` immediately after `value` of an input is changed.
- On IE9, not firing `onChange` when backspacing.
Introduces a counterpart to mapChildren. It excludes empty children just as
mapChildren for compatibility. With might introduce something like
sliceChildrenIncludingEmptyValues at some point.
This behavior is new in Commoner v0.8.3, following the incorporation of
@jeffreylin's `DirWatcher` implementation:
https://github.com/jeffreylin/jsx_transformer_fun/blob/master/dirWatcher.js
Watching directories instead of files reduces the total number of open
files, and copes better with editors that save files by deleting and then
immediately recreating them.
Closes#60.
Closes#71.
If you are using bin/jsx independently, you may need to pass
--follow-requires to it if you rely on its dependency scanning.
Dependency scanning is still a good idea, but it's difficult to make it
work perfectly for everyone the first time they try bin/jsx.
Closes#131.
I still think the semantics of flattening children is valid but we'll
want to revert the flattening implementation while we solidify the
semantics and try another approach.
This reverts flattening so that this.props.children can once again be
either a single child, flat array or nested array.
mapChildren calls flattenChildren before doing anything else. This is
not the most efficient approach but I wanted to keep this inital diff
simple. It also ignores empty values for backwards compatibility.
We may want to try another approach where empty values are included
in the map.
Validation of keys is still done inside ReactComponent. Ideally I'd
like to extract that into a separate module but to avoid cyclic
dependencies, I'm keeping it in ReactComponent for now.
This fixes a race condition if the `onClick` tries to update the input or textarea (e.g. by calling `setState`):
<input
onClick={function(event) {
this.setState({somethingElse: true}); // Triggers an update.
// event.target.value is now equal to the old value, fail...
this.props.onChange(event);
})
/>
A dynamic value can be provided as a key to a child. Either as part of an object
or key property. This becomes part of the component's ID.
We have to be careful to escape this key before inserting it into the DOM since
it could become a vulnerability. We fixed this by escaping just the keys.
However, the current implementation breaks when you used escaped keys. The
internal value is escaped and the value used by getAttributeNode and
getElementById are both unescaped.
This fixes that by keeping the unescaped value internally but escaping it right
before the HTML is generated (like any other attribute).
This is important since business logic IDs (that should be used as keys)
contains characters that need to be escaped.
This changes `ReactDOMTextarea` to accept `defaultValue` and `value`. It will warn people about using children (but allow it and treat it as `defaultValue`, which is the current behavior).
Instead of simply logging the React ID of the `ancestorNode` when `findComponentRoot` fails, use a `try ... finally` to `console.error` the `ancestorNode`. This allows modern web inspectors to actually log a reference to the node (which may not have a React ID).
This means when people run into the problem, they will not have to execute:
require('ReactID').getNode(<copy+paste>);
NOTE: Admittedly, this will not log anything in IE8. That's fine, since IE8 has shitty console logging anyway.
Just a bit of byte savings for server rendering. Props to @benjamn for the base36 idea (and for making this diff easy).
With a little work we could probably get rid of the .r as well.
This changes React to throw when `ReactID.getNode()` fails to find a node. This method is used by two call sites:
- Implements `ReactComponent#getDOMNode`. This method already throws if a component is not mounted, and //all mounted components should be able to find their rendered root nodes//.
- Used by `ReactDOMIDOperations`. These call sites aleady assume that `getNode` returns a non-null. Currently, if the node is not found, this is the site that fatals (and the stack trace is much harder to debug).
The error message should make it //a lot// easier to debug unexpected DOM trees. In particular, this will help track down all the places where the browser inserts `<tbody>` unexpectedly.
This fixes a bug with components constructed with no owners, for example:
// Both the <div> and <span> have no owners.
React.renderComponent(<div><span /></div>, node);
They should have a composition level of 1 and their keys should be prefixed with 0 to indicate they were created without owners. However, they currently incorrectly get a composition level of 0 (which means that //their// children will have keys prefixed with 0, which is wrong).
The current `ReactInstanceHandles` has a bug where `findComponentRoot` barfs if it comes across a node that was not identified by React (via `ReactID`). This fixes that.
This was always a bug, but it became more apparent once we switched to `data-reactid` because arbitrary `document.createElement`'d nodes are much more likely to have an `id` than they are to have a `data-reactid`.
This final change is what we've all been waiting for.
Note that it no longer makes sense to use `document.getElementById` in
`getNode`, because that only ever worked with "id" attributes.
This prevents PhantomJS tests from hanging in the open-source React repo.
Until the advent of `"use strict"`, passing `null` as the context object
to `.call` or `.apply` resulted in `this` taking on the value of the
global object inside the invoked function.
Technically the `"use strict"` directive is supposed to make it possible
that `this === null`, but strict mode is not respected by all browsers,
including (unfortunately) PhantomJS.
Since these `expect`-ations are just testing binding behavior, let's not
make them also test strict mode `this` handling.
The `getDefaultProps` return value should not be dependent on any external data (including `this.props` and `this.state`), so the return value should be consistent everytime we call it.
This caches the return value so we do not do work and allocate memory unnecessarily.
A node is considered valid if it
1. has the expected ID (more of a sanity check than something that is
ever likely to go wrong), and
2. is contained by a currently mounted container.
When these requirements are met, we can be confident that
`ReactMount.findReactRenderedDOMNodeSlow(node.id) === node`, which is
important for cache consistency because `findReactRenderedDOMNodeSlow` is
what we fall back to when we don't find a node in the cache.
Point 2 is a subtle requirement, because it allows nodes to be valid even
if they are not currently contained by a document. Rendering into a
detached node is okay, in other words (which is something that
`document.getElementById` never properly accounted for).
Containment testing takes linear time in the depth of the DOM, which
sounds unfortunate until you realize that virtually all browsers support a
native `ancestor.contains(descendant)` method, and in practice the vast
majority of nodes are either orphaned with `.parentNode === null` or not
very deep relative to their container.
Upgrade `TextChangeEventPlugin` to be the `onChange` event that React
fires. In React, `onChange` will now fire when `input` fires for form elements in
modern browsers.
Handle this for:
input[type=text]
input[type=password]
input[type=checkbox]
input[type=radio]
textarea
select
Support:
- OSX Chrome
- OSX Safari
- OSX Firefox
- Win 7 / IE8
- Win 7 / IE9
- Win 7 / IE10
Everything works but caret selection / placement differs from browser to
browser.
For <select> elements, the event is fired with `change`. This is a
conscious decision, even though in some browsers (OSX firefox, IE), it
can be argued that the event should fire more due to how the UI looks.
Builds on https://github.com/facebook/react/pull/75, which handled only
text inputs.
These modules have been superseded by `ReactID`. Since they were only used
internally, and I have updated all client code that previously assumed
their existence, I believe they can be dropped for good.
Although it would have been nice to prime the entire tree and achieve a
cache hit rate of 100%, that cost would have to be paid up front, during
page rendering.
This patch avoids priming up front in favor of making the most of the work
done by `ReactMount.findReactRenderedDOMNodeSlow`, which calls
`ReactID.getID` while traversing the rendered DOM. The insight is this: if
`getID` simply primes the cache whenever it finds a new ID, then
`findReactRenderedDOMNodeSlow` will end up priming quite a few more nodes
that are actually involved in `ReactID.getNode` lookups, and we won't need
`primeTree` at all.
`.grunt/` is the directory that is suggested for storing task related
files, and this file is not useful if it gets wiped out often. So I'm
moving the compare_size cache into `.grunt/` so we keep it around
longer.
This behavior seemed incorrect for composite components.
- isComponentMounted() represents ReactComponent's lifecycle of mounting
- isMounted() represents ReactCompositeComponent's lifecycle of isMounted()
Therefore, ReactComponents no longer have isMounted(). I think this is fine since it was not supposed to be public anyway.
Summary:
This is a proposal based loosely on the discussions I've had with @paulshen and @jwalke. It implements a shim for `React.DOM.input` (used as `<input>`) that supports two different use cases depending on whether `value` is provided or not.
If a `value` is //not// provided, the input will be initialized with the empty string (or `defaultValue`) and anytime the user changes the input, the `onChange` (or `onTextChange`) handler will be fired and the DOM will reflect the new changes.
React.renderComponent(
<input type="text" defaultValue="Untitled" onTextChange={handleChange} />,
container
);
If a `value` is provided, the input will be initialized to that value. Anytime the user changes the input, the `onChange` (or `onTextChange`) handler will be fired. However, the DOM will //not// reflect the new changes. If a `value` is provided, it is the responsibility of the owner to update the `value` prop passed in.
var value = "Untitled";
var input = React.renderComponent(
<input type="text" value={value} onTextChange={handleChange} />,
container
);
function handleChange(event) {
// Do something cool like strip out non-numbers.
var value = event.target.value.replace(/\D/g, '');
input.setProps({value: value});
}
This is just a start and we should build similar components for `textarea` and `select`. Also, this does not inject the new components because the changes are not backward compatible. Once we change all `<input>` uses to use `ReactDOMInput`, then we can inject.
The original autobinding diff made some assumptions about how methods were called on components that had to be reverted. This diff
enforces those assumptions in a test
Per our discussion - this is the general approach we'd like to take for
the public facing API.
var MyComponent = React.createClass({
render: function() {
return <div onClick={this.myCallback} />;
},
myCallback: function() {
}
});
Also removed some unnecessary calls to `document.getElementById`, which
will eventually cease to work for React-specific IDs.
This clears the way for the deprecation of `ReactDOMNodeCache` and
`getDOMNodeID`.
When we move away from using the "id" attribute to identify
React-generated elements, we will need the cache (formerly
ReactDOMNodeCache) to be tied much more closely to the code that looks
elements up by ID (getDOMNodeID) and sets element IDs, since the magic of
document.getElementById will no longer be available.
The priming functions are going to come in handy when we create new DOM
fragments in mountComponent.
For backwards compatibility, the ReactDOMNodeCache and getDOMNodeID
modules still exist, but they are implemented entirely in terms of
functions exported from ReactID.
This adds a `toBeComponentOfType` method to `reactComponentExpect`. Now that we are injecting composite native components, `toBeDOMComponentWithTag` will not suffice and should be deprecated.
_updateDOMChildren was already updating textContent so we don't need to
do it in _updateDOMProperties. Additionally, don't update .value if
it'll be a noop because it has side-effects (like moving the cursor) in
some browsers (like IE 9).
Refactor tests to be a bit more robust and a bit cleaner too.
It turns out that (at least for local development) npm has a long
standing bug where it doesn't recognize changing dependencies stored as
git urls (see https://github.com/isaacs/npm/issues/1727). Luckily npm
understand tarballs and GitHub provides tarballs for every commit, so
the workaround is easy, though unfortunate.
We have less dynamic arrays in the code base now so let's start warning for all
the cases where we pass dynamic arrays without keys.
I use the displayName to point out which component's render method was
responsible. I only warn once per component. If the child was created in a
different component (and passed as a property) I also show the owner of the
child. Maybe it should've attached the key at a higher level.
This does give false positives for arrays that are truly static. Those should
probably be refactored to use the XML syntax if possible.
06cff60bc1 made it so that `this.props.children` was no longer set when
none were provided.
var x = <div />;
This caused an issue if the code was relying on the following not
transferring children.
return this.transferPropsTo(<div />);
// this now transfer children
This fixes the last known parts of the flattening experiment. This has grown to
be somewhat complex and potentially fragile because of it. We may end up
reverting flattening in the future or address it slightly differently.
The purpose of this diff is to test if we've finally understood the real world
edge cases that flattening can lead to and how we have to key components to
cover those cases.
With this commit we never rekey the internal _key property. The semantics is
that once a component passes through a composite component, it's identity is
frozen.
props.key should accept numeric values and booleans which includes 0 and false.
This fixes the truthiness check.
We should never warn about missing key properties if a component is passed as a
static child. The _key acts as a flag to determine whether this component
was checked already.
Dumping the mock cache isn't dirying the modules in the open source version, so we have to unit test a different way. If we can fix the unit test framework, we should revert this.
Also, I added strict mode to `EventPluginRegistry.js`.
See: https://github.com/facebook/react/pull/91
Small utility that extracts and validates that there is only a single
child passed to a React composite component. The benefit here is that we
abstract away *how* the children are actually stored while we iterate on
different approaches. This way we won't break callsites as we try different
ideas. When we settle on a final approach, all of these callsites will still
work.
There are currently two places where we lookup and cache nodes: `ReactDOMNodeCache` and `ReactComponent`. Instead, we should just consolidate caches and make `ReactComponent` use `ReactDOMNodeCache`.
This should prevent "Warning: stdout maxBuffer exceeded" errors.
Also piping child process stdout and stderr to the parent process, so
you can see more of what's happening during the build process.
The biggest improvement is that we'll now insert each parsed JSX script
back into a `<script>` tag with the body set. This allows the browser to
execute these scripts normally. Using `Function(functionBody)` or
`eval(functionBody)` both execute in window scope, but `var` assignments
don't actually get set on window (unlike everywhere else).
I also did some cleanup to make the code a little bit more readable.
In my minimal test cases this didn't break anything (scripts loaded in
the right order).
This commit adds an optional callback as a second argument to
`setState`, to be called after `setState` runs.
We never guarantee synchronous execution of `setState`, and as per
@phunt, we don't want to make that guarantee because we may eventually
batch calls to `setState`. @jwalke agrees with him.
If you defined a global named `id` (a horrible name, I know) then
getDOMNodeID(window) would return that object. Since only DOM nodes can
have IDs, this should be a noop change otherwise.
Test Plan:
Verified that document.documentElement and document.body both support
getAttributeNode properly in latest Chrome and in IE8.
Dumping the mock cache isn't dirying the modules, so we have to unit test a different way. If we can fix our unit test framework, we should revert this.
Also, I added strict mode to `EventPluginRegistry.js`.
Summary: This invariant is unnecessary because `ReactComponent.Mixin.receiveProps` already asserts that this component is mounted. (Being mounted guarantees you have a DOM ID, look at `ReactComponent` and see when `this._rootNodeID` is mutated.)
This can be replicated with a custom component that always returns false`
from `shouldComponentUpdate`. A generic implementation might look like:
```
var StaticContainer = React.createClass({
shouldComponentUpdate: function() {
return false;
},
render: function() {
return this.transferPropsTo(this.props.children[0]);
}
});
```
And then used in JSX as
`<StaticContainer><div>Hello!</div></StaticContainer>`, resulting in
only `<div>Hello!</div>` being inserted into the DOM.
This fixes an edge case that can cause unnecessary mutations in the DOM. Namely, if a prop is falsey, it will get touched on every update by reconciliation. See unit test.
This cleans up the reconcilation path when adding a `style` prop (going from a falsey or no `style` to having one) by reducing the need for an object allocation and for-loop.
The `EventPluginHub` module was getting huge and scary. This pulls out all of the logic required to inject plugins and publish their event registration names into a new `EventPluginRegistry` module.
Functionally, nothing should have changed. I added many error checks to cover edge cases that we were not yet running into, but they are all in `EventPluginRegistry` and unit tested.
There is currently no way for components to know whether or not they are mounted. This means there's no way for callbacks to figure out if they can make certain assumptions (e.g. can `getDOMNode()` or `setState()` be safely invoked).
This adds an `isMounted` protected method that lets components properly handle callback behavior when unmounted.
Turns out my tests before weren't particularly useful because
receiveProps doesn't end up running componentDidUpdate since the
transaction never finishes. Now they use replaceProps instead (and I
verified that commenting out the "rootNode.value = ..." line makes the
tests fail, which wasn't true before).
The most obvious manifestation of this bug is visible here:
http://jsfiddle.net/spicyj/zzGas/. In short, when props are removed from a
component, the underlying HTML element doesn't have the attribute
removed.
This change should fix it, but unfortunately it (presumably) makes
_updateDOMProperties a bit slower.
The Commoner upgrade is a big one because it makes bin/jsx no longer
rewrite module identifiers to be relative by default, which should
reduce confusion for people trying to use it as a standalone
transformer.
Closes#80.
IE<9 relied on the `target` property being overriden. This adds back a hack that only applies in IE<9. I'll be able to revert this hack once I check in synthetic events.
This is just a simple rename of the event classes to `SyntheticEvent`. I've also updated the constructor arguments to be more correct:
- `dispatchConfig`: Data used by the plugin system for dispatching the event, for example: `{registrationName: 'onClick'}`
- `dispatchMarker`: An identifying marker used to describe where the event is occuring, for example: `.reactRoot[0]`
This is both a functional fix and performance fix for `ReactInstanceHandles`.
- `getFirstReactDOM` uses `indexOf` but should be checking ancestry (via `isMarker()`).
- Added `isAncestorIDOf`, checking ancestry can be way faster than getting a common ancestor: http://jsperf.com/react-ancestor-id-check
Change `ReactInstanceHandles` so that `getFirstCommonAncestorID` and `nextDescendantID` are now private (and documented to be only exposed for unit testing). Also:
- Renamed `nextDescendantID` to `getNextDescendantID`.
- Renamed `parentID` to `getParentID`.
I also organized `ReactInstanceHandles-test` by method names.
Functionally, this diff should not change anything.
IE8 doesn't support oninput and IE9 supports it badly but we can do
almost a perfect shim by listening to a handful of different events
(focus, blur, propertychange, selectionchange, keyup, keydown).
This always triggers event handlers during the browser's event loop (not
later in a setTimeout) and after the value property has been updated.
The only case I know of where this doesn't fire the event immediately is
if (in IE8) you modify the input value using JS and then the user does a
key repeat, in which case we fire the event on the second keydown.
Test Plan:
Modify ballmer-peak example to add es5-shim and to use onTextChange
instead of onInput. In IE8, IE9, and latest Chrome, make sure that the
event is fired upon:
* typing normally,
* backspacing,
* forward-deleting,
* cutting,
* pasting,
* context-menu deleting,
* dragging text to reorder characters.
After modifying the example to change .value, make sure that the event
is not fired as a result of the changes from JS (even when the input box
is focused).
Remove ReactMount.createComponentRenderer because it does not function
correctly.
var f = React.createComponentRenderer(<div />);
var container1 = document.createElement('div');
var container2 = document.createElement('div');
f(container1);
f(container2); // error because mounting same instance into new root
React's top-level event delegation dispatches `AbstractEvent` objects that contain:
- `nativeEvent`, the original browser event.
- `data`, an object with custom normalized properties.
This diff creates a set of `DelegateEvent` classes that will replace `AbstractEvent`. The goal is two-fold:
# Provide a cross-browser implementation that conforms to the DOM Level 3 Events API so people don't have to use `nativeEvent`.
# Generalize the event object API so that it can be shared by `DOMEventManager`, a top-level event delegation WIP.
This simply implements the classes. I will follow-up by replacing `AbstractEvent` with them.
Type coersion bug and ID breaking assumption.
Names need to be wrapped in something unique since otherwise two unique siblings
can end up having IDs that are subsets of eachother.
There are to reasons to prefer a `persist` method on the event rather than a static method:
- In open source, people do not have access to `AbstractEvent`.
- This will allow people to persist events without requiring another module.
- This will make refactors easier and more flexible.
As of Commoner v0.6.11, the default is to put the cache files in
output/.module-cache, which used to be build/modules/.module-cache
before this commit. That still happens when you run bin/jsx directly,
just not for grunt tasks anymore.
The module cache needs to be cleared much less often than
build/modules, so it doesn't make sense to throw away all that work.
This improved browser support for the `wheel` event.
- Try to use `wheel` event (DOM Level 3 Specification).
- Fallback to `mousewheel` event.
- Fallback to `DOMMouseWheel` (older Firefox).
Also, since `wheel` is the standard event name, let's use that in React.
NOTE: The tricky part was detecting if `wheel` is supported for IE9+ because `onwheel` does not exist.
Test Plan:
Execute the following in the console on a page with React:
var React = require('React');
React.renderComponent(React.DOM.div({
style: {
width: 10000,
height: 10000
},
onWheel: function() {
console.log('wheel');
}
}, null), document.body);
Verified that mousewheel events are logged to the console.
Verified in IE8-10, Firefox, Chrome, and Safari.
Summary:
This makes a few changes to React Core, most notably `ReactEventEmitter` and `ReactEventTopLevelCallback`.
- Changed `ReactEventEmitter` to use `EventListener` (instead of `NormalizedEventListener`).
- Deleted `NormalizedEventListener` (which was previously broken).
- Created `getEventTarget` which is used to get a normalized `target` from a native event.
- Changed `ReactEventTopLevelCallback` to use `getEventTarget`.
- Renamed `abstractEventType` to `reactEventType` in `AbstractEvent`.
- Reanmed `abstractTargetID` to `reactTargetID` in `AbstractEvent`.
- Removed `originatingTopLevelEventType` from `AbstractEvent` (unused and violates encapsulation).
- Removed `nativeEvent.target === window` check when refreshing authoritative scroll values (unnecessary).
This actually fixes React because `NormalizedEventListener` does not currently do what it promises to do (which is normalizing `target` on the native event). The `target` event is read-only on native events.
This also revises documentation and adds `@typechecks` to a few modules.
NOTE: Most importantly, this sets the stage for replacing `AbstractEvent` with `ReactEvent` and subclasses, piecemeal.
Summary: Since grepping for `update` and `updateAll` is pretty hard, I had these these functions call through but complain loudly. This noisy call through has been in prod for over a week and I haven't heard any complains, so let's take it out altogether.
ReactEvent should be reserved for the actual object created when an
event fires. The current ReactEvent is more like EventEmitter than
anything (e.g. it sets up delegation, provides methods to attach and
remove listeners).
We need to make sure that deleteAllListeners() is invoked before we call
the superclass's unmountComponent() method or else we will lose
this._rootNodeID.
I also added an invariant and unit test to make sure we do not break
this in the future.
If a React component's render() fatals, it may contaminate
ReactCurrentOwner. This will cause the owner to be set improperly for
the next React.renderComponent() invocation (which causes an owner to be
set when there shouldn't be one).
As it turns out, default values are very useful. This implements
getDefaultProps(), a hook for components to provide prop values when
a prop is not specified by the user.
var container = ...; // some DOM node
React.renderComponent(<div />, container);
React.renderComponent(<span />, container);
This should replace the rendered <div> with a <span>, effectively
reconciling at the root level.
Currently we're mutating _key. Mutation here is fine, but it needs to
be idempotent - which it's not. This is causing some issues.
Instead I reassign the _key every time it passes through a flattening.
This means that it's unique and stable for a single pass through a composite
component. When it's repassed another level, it loses it previous
identity and is rekeyed by it's new location.
For auto-generated keys by index, this actually means it has the same
semantics as before flattening.
For explicit keys, it has the effect that keys need to be unique at
every level. Regardless of how the key got there. Every component needs to ensure
that it doesn't combine keys from two different sources that may collide. This
is also inline with the old semantics but less intuitive in the new model.
flattenChildren was only using key when child.mountInContainerNode
exists, which is defined on ReactCompositeComponent, and not
ReactNativeComponent.
This uses the isValidComponent() fn to see if we should use this key.
Some improvements to how style={{x:y}} is handled in React:
* ignores null styles, rather than setting them.
Codez:
var highlighted = false;
<div style={{color: highlighted ? 'red' : null}} />
Before:
<div style="color:;"></div>
After:
<div></div>
Respects that 0 has no units.
This expects static children as additional arguments to the constructor
and flattens any array arguments one level deep.
Component(props, child1, child2, arrayOfChildren, child3) ->
.props.children = [child1, child2, ...arrayOfChildren, child3]
This can avoid an additional heap allocation for the unflat array.
It allows you to pass nested arrays and objects like you used to. Those
aren't immediately flattened. That makes this a fairly safe change.
Passing a dynamic array without key properties will yield a warning
(once). Might consider throwing later.
Once we change the transpiler to use the new syntax, you'll end up with
a single flat array in normal usage.
This doesn't actually update the JSX transform.
When there isn't any React node in the DOM, unmountAndReleaseReactRootNode
threw an exception because component was undefined. Instead, return whether we
were able to unmount the component.
Test Plan:
With the ballmer-peak example (modified to use input), tested that the
percentage updates when adding or deleting text in the field on Chrome
and IE9. After adding es5-shim and es5-sham to the ballmer-peak page,
IE8 works properly too.
onInput has the advantage that it responds to repeated key events before
onKeyUp and is called when modifying the input without the keyboard
(such as pasting with the mouse).
Test Plan:
Opened the ballmer-peak example and docs homepage in Chrome and checked
that both examples update whenever the text is changed.
'input' is supported in IE9+ and all other browsers according to
https://developer.mozilla.org/en-US/docs/Web/API/window.oninput
Test Plan:
Modified ballmer-peak example to use onInput instead of onKeyUp and
tested that it works properly on latest Chrome.
2013-05-30 18:20:34 -07:00
719 changed files with 52311 additions and 16813 deletions
*`setState` can be called inside `componentWillMount` in non-DOM environments
*`SyntheticMouseEvent.getEventModifierState` correctly renamed to `getModifierState`
*`getModifierState` correctly returns a `boolean`
*`getModifierState` is now correctly case sensitive
* Empty Text node used in IE8 `innerHTML` workaround is now removed, fixing rerendering in certain cases
### JSX
* Fix duplicate variable declaration in JSXTransformer (caused issues in some browsers)
## 0.11.0 (July 17, 2014)
### React Core
#### Breaking Changes
*`getDefaultProps()` is now called once per class and shared across all instances
*`MyComponent()` now returns a descriptor, not an instance
*`React.isValidComponent` and `React.PropTypes.component` validate *descriptors*, not component instances
* Custom `propType` validators should return an `Error` instead of logging directly
#### New Features
* Rendering to `null`
* Keyboard events include normalized `e.key` and `e.getModifierState()` properties
* New normalized `onBeforeInput` event
*`React.Children.count` has been added as a helper for counting the number of children
#### Bug Fixes
* Re-renders are batched in more cases
* Events: `e.view` properly normalized
* Added Support for more HTML attributes (`coords`, `crossOrigin`, `download`, `hrefLang`, `mediaGroup`, `muted`, `scrolling`, `shape`, `srcSet`, `start`, `useMap`)
* Improved SVG support
* Changing `className` on a mounted SVG component now works correctly
* Added support for elements `mask` and `tspan`
* Added support for attributes `dx`, `dy`, `fillOpacity`, `fontFamily`, `fontSize`, `markerEnd`, `markerMid`, `markerStart`, `opacity`, `patternContentUnits`, `patternUnits`, `preserveAspectRatio`, `strokeDasharray`, `strokeOpacity`
* CSS property names with vendor prefixes (`Webkit`, `ms`, `Moz`, `O`) are now handled properly
* Duplicate keys no longer cause a hard error; now a warning is logged (and only one of the children with the same key is shown)
*`img` event listeners are now unbound properly, preventing the error "Two valid but unequal nodes with the same `data-reactid`"
* Added explicit warning when missing polyfills
### React With Addons
* PureRenderMixin: a mixin which helps optimize "pure" components
* Perf: a new set of tools to help with performance analysis
* Update: New `$apply` command to transform values
* TransitionGroup bug fixes with null elements, Android
### React NPM Module
* Now includes the pre-built packages under `dist/`.
*`envify` is properly listed as a dependency instead of a peer dependency
### JSX
* Added support for namespaces, eg `<Components.Checkbox />`
* JSXTransformer
* Enable the same `harmony` features available in the command line with `<script type="text/jsx;harmony=true">`
* Scripts are downloaded in parallel for more speed. They are still executed in order (as you would expect with normal script tags)
* Fixed a bug preventing sourcemaps from working in Firefox
### React Tools Module
* Improved readme with usage and API information
* Improved ES6 transforms available with `--harmony` option
* Added `--source-map-inline` option to the `jsx` executable
* New `transformWithDetails` API which gives access to the raw sourcemap data
## 0.10.0 (March 21, 2014)
### React Core
#### 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)
* Added support for more attributes:
*`srcSet` for `<img>` to specify images at different pixel ratios
*`textAnchor` for SVG
#### Bug Fixes
* Ensure all void elements don’t insert a closing tag into the markup.
* Ensure `className={false}` behaves consistently
* Ensure `this.refs` is defined, even if no refs are specified.
### Addons
*`update` function to deal with immutable data. [Read the docs](http://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).
## 0.9.0 (February 20, 2014)
### React Core
#### Breaking Changes
- The lifecycle methods `componentDidMount` and `componentDidUpdate` no longer receive the root node as a parameter; use `this.getDOMNode()` instead
- Whenever a prop is equal to `undefined`, the default value returned by `getDefaultProps` will now be used instead
-`React.unmountAndReleaseReactRootNode` was previously deprecated and has now been removed
-`React.renderComponentToString` is now synchronous and returns the generated HTML string
- Full-page rendering (that is, rendering the `<html>` tag using React) is now supported only when starting with server-rendered markup
- On mouse wheel events, `deltaY` is no longer negated
- When prop types validation fails, a warning is logged instead of an error thrown (with the production build of React, type checks are now skipped for performance)
- On `input`, `select`, and `textarea` elements, `.getValue()` is no longer supported; use `.getDOMNode().value` instead
-`this.context` on components is now reserved for internal use by React
#### New Features
- React now never rethrows errors, so stack traces are more accurate and Chrome's purple break-on-error stop sign now works properly
- Added support for SVG tags `defs`, `linearGradient`, `polygon`, `radialGradient`, `stop`
- Added support for more attributes:
-`crossOrigin` for CORS requests
-`download` and `hrefLang` for `<a>` tags
-`mediaGroup` and `muted` for `<audio>` and `<video>` tags
-`noValidate` and `formNoValidate` for forms
-`property` for Open Graph `<meta>` tags
-`sandbox`, `seamless`, and `srcDoc` for `<iframe>` tags
-`scope` for screen readers
-`span` for `<colgroup>` tags
- Added support for defining `propTypes` in mixins
- Added `any`, `arrayOf`, `component`, `oneOfType`, `renderable`, `shape` to `React.PropTypes`
- Added support for `statics` on component spec for static component methods
- On all events, `.currentTarget` is now properly set
- On keyboard events, `.key` is now polyfilled in all browsers for special (non-printable) keys
- On clipboard events, `.clipboardData` is now polyfilled in IE
- On drag events, `.dragTransfer` is now present
- Added support for `onMouseOver` and `onMouseOut` in addition to the existing `onMouseEnter` and `onMouseLeave` events
- Added support for `onLoad` and `onError` on `<img>` elements
- Added support for `onReset` on `<form>` elements
- The `autoFocus` attribute is now polyfilled consistently on `input`, `select`, and `textarea`
#### Bug Fixes
- React no longer adds an `__owner__` property to each component's `props` object; passed-in props are now never mutated
- When nesting top-level components (e.g., calling `React.renderComponent` within `componentDidMount`), events now properly bubble to the parent component
- Fixed a case where nesting top-level components would throw an error when updating
- Passing an invalid or misspelled propTypes type now throws an error
- On mouse enter/leave events, `.target`, `.relatedTarget`, and `.type` are now set properly
- On composition events, `.data` is now properly normalized in IE9 and IE10
- CSS property values no longer have `px` appended for the unitless properties `columnCount`, `flex`, `flexGrow`, `flexShrink`, `lineClamp`, `order`, `widows`
- Fixed a memory leak when unmounting children with a `componentWillUnmount` handler
- Fixed a memory leak when `renderComponentToString` would store event handlers
- Fixed an error that could be thrown when removing form elements during a click handler
- Boolean attributes such as `disabled` are rendered without a value (previously `disabled="true"`, now simply `disabled`)
-`key` values containing `.` are now supported
- Shortened `data-reactid` values for performance
- Components now always remount when the `key` property changes
- Event handlers are attached to `document` only when necessary, improving performance in some cases
- Events no longer use `.returnValue` in modern browsers, eliminating a warning in Chrome
-`scrollLeft` and `scrollTop` are no longer accessed on document.body, eliminating a warning in Chrome
- General performance fixes, memory optimizations, improvements to warnings and error messages
### React with Addons
-`React.addons.TestUtils` was added to help write unit tests
-`React.addons.TransitionGroup` was renamed to `React.addons.CSSTransitionGroup`
-`React.addons.TransitionGroup` was added as a more general animation wrapper
-`React.addons.cloneWithProps` was added for cloning components and modifying their props
- Bug fix for adding back nodes during an exit transition for CSSTransitionGroup
- Bug fix for changing `transitionLeave` in CSSTransitionGroup
- Performance optimizations for CSSTransitionGroup
- On checkbox `<input>` elements, `checkedLink` is now supported for two-way binding
### JSX Compiler and react-tools Package
- Whitespace normalization has changed; now space between two tags on the same line will be preserved, while newlines between two tags will be removed
- The `react-tools` npm package no longer includes the React core libraries; use the `react` package instead.
-`displayName` is now added in more cases, improving error messages and names in the React Dev Tools
- Fixed an issue where an invalid token error was thrown after a JSX closing tag
-`JSXTransformer` now uses source maps automatically in modern browsers
-`JSXTransformer` error messages now include the filename and problematic line contents when a file fails to parse
## 0.8.0 (December 19, 2013)
### React
* Added support for more attributes:
*`rows` & `cols` for `<textarea>`
*`defer` & `async` for `<script>`
*`loop` for `<audio>` & `<video>`
*`autoCorrect` for form fields (a non-standard attribute only supported by mobile WebKit)
* Improved error messages
* Fixed Selection events in IE11
* Added `onContextMenu` events
### React with Addons
* Fixed bugs with TransitionGroup when children were undefined
* Added support for `onTransition`
### react-tools
* Upgraded `jstransform` and `esprima-fb`
### JSXTransformer
* Added support for use in IE8
* Upgraded browserify, which reduced file size by ~65KB (16KB gzipped)
## 0.5.2, 0.4.2 (December 18, 2013)
### React
* Fixed a potential XSS vulnerability when using user content as a `key`: [CVE-2013-7035](https://groups.google.com/forum/#!topic/reactjs/OIqxlB2aGfU)
## 0.5.1 (October 29, 2013)
### React
* Fixed bug with `<input type="range">` and selection events.
* Fixed bug with selection and focus.
* Made it possible to unmount components from the document root.
* Fixed bug for `disabled` attribute handling on non-`<input>` elements.
### React with Addons
* Fixed bug with transition and animation event detection.
## 0.5.0 (October 16, 2013)
### React
* Memory usage improvements - reduced allocations in core which will help with GC pauses
* Performance improvements - in addition to speeding things up, we made some tweaks to stay out of slow path code in V8 and Nitro.
* Standardized prop -> DOM attribute process. This previously resulting in additional type checking and overhead as well as confusing cases for users. Now we will always convert your value to a string before inserting it into the DOM.
* Support for Selection events.
* Support for [Composition events](https://developer.mozilla.org/en-US/docs/Web/API/CompositionEvent).
* Support for additional DOM properties (`charSet`, `content`, `form`, `httpEquiv`, `rowSpan`, `autoCapitalize`).
* Support for additional SVG properties (`rx`, `ry`).
* Support for using `getInitialState` and `getDefaultProps` in mixins.
* Support mounting into iframes.
* Bug fixes for controlled form components.
* Bug fixes for SVG element creation.
* Added `React.version`.
* Added `React.isValidClass` - Used to determine if a value is a valid component constructor.
* Removed `React.autoBind` - This was deprecated in v0.4 and now properly removed.
* Renamed `React.unmountAndReleaseReactRootNode` to `React.unmountComponentAtNode`.
* Began laying down work for refined performance analysis.
* Better support for server-side rendering - [react-page](https://github.com/facebook/react-page) has helped improve the stability for server-side rendering.
* Made it possible to use React in environments enforcing a strict [Content Security Policy](https://developer.mozilla.org/en-US/docs/Security/CSP/Introducing_Content_Security_Policy). This also makes it possible to use React to build Chrome extensions.
### 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).
### JSX
* No longer transform `class` to `className` as part of the transform! This is a breaking change - if you were using `class`, you *must* change this to `className` or your components will be visually broken.
* Added warnings to the in-browser transformer to make it clear it is not intended for production use.
* Improved compatibility for Windows
* Improved support for maintaining line numbers when transforming.
## 0.4.1 (July 26, 2013)
### React
*`setState` callbacks are now executed in the scope of your component.
*`click` events now work on Mobile Safari.
* Prevent a potential error in event handling if `Object.prototype` is extended.
* Don't set DOM attributes to the string `"undefined"` on update when previously defined.
* Improved support for `<iframe>` attributes.
* Added checksums to detect and correct cases where server-side rendering markup mismatches what React expects client-side.
### JSXTransformer
* Improved environment detection so it can be run in a non-browser environment.
## 0.4.0 (July 17, 2013)
### React
* 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)
* 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.
### JSX
* Support for comment nodes `<div>{/* this is a comment and won't be rendered */}</div>`
* Children are now transformed directly into arguments instead of being wrapped in an array
E.g. `<div><Component1/><Component2/></div>` is transformed into `React.DOM.div(null, Component1(null), Component2(null))`.
Previously this would be transformed into `React.DOM.div(null, [Component1(null), Component2(null)])`.
If you were using React without JSX previously, your code should still work.
### react-tools
* Fixed a number of bugs when transforming directories
* No longer re-write `require()`s to be relative unless specified
## 0.3.3 (June 20, 2013)
### React
* Allow reusing the same DOM node to render different components. e.g. `React.renderComponent(<div/>, domNode); React.renderComponent(<span/>, domNode);` will work now.
### JSX
* Improved the in-browser transformer so that transformed scripts will execute in the expected scope. The allows components to be defined and used from separate files.
### react-tools
* Upgrade Commoner so `require` statements are no longer relativized when passing through the transformer. This was a feature needed when building React, but doesn't translate well for other consumers of `bin/jsx`.
* Upgraded our dependencies on Commoner and Recast so they use a different directory for their cache.
* Freeze our esprima dependency.
## 0.3.2 (May 31, 2013)
### JSX
* Improved compatability with other coding styles (specifically, multiple assignments with a single `var`).
### react-tools
* Switch from using the browserified build to shipping individual modules. This allows react-tools to be used with [browserify](https://github.com/substack/node-browserify).
## 0.3.1 (May 30, 2013)
### react-tools
* Fix bug in packaging resulting in broken module.
@@ -27,7 +27,7 @@ The core team will be monitoring for pull requests. When we get one, we'll run s
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://developers.facebook.com/opensource/cla>
Complete your CLA here: <https://code.facebook.com/cla>
## Bugs
@@ -57,6 +57,7 @@ Facebook has a [bounty program](https://www.facebook.com/whitehat/) for the safe
*`"use strict";`
* 80 character line length
* "Attractive"
* Do not use the optional parameters of `setTimeout` and `setInterval`
React is a JavaScript library for building user interfaces.
* **Declarative:** React uses a declarative paradigm that makes it easier to reason about your application.
* **Efficient:** React computes the minimal set of changes necessary to keep your DOM up-to-date.
* **Flexible:** React works with the libraries and frameworks that you already know.
* **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.
* **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)
## 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](http://facebook.github.io/react/). Here is the first one to get you started:
```js
/** @jsx React.DOM */
varHelloMessage=React.createClass({
render:function(){
return<div>{'Hello '+this.props.name}</div>;
return<div>Hello{this.props.name}</div>;
}
});
@@ -28,20 +28,20 @@ React.renderComponent(
This example will render "Hello John" into a container on the page.
You'll notice that we used an XML-like syntax; [we call it JSX](http://facebook.github.io/react/docs/syntax.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](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.
## Installation
The fastest way to get started is to serve JavaScript from the CDN:
The fastest way to get started is to serve JavaScript from the CDN (also available on [CDNJS](http://cdnjs.com/#react)):
We've also built a [starter kit](http://facebook.github.io/react/downloads/react-0.3.2.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](http://facebook.github.io/react/downloads/react-0.11.1.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:
@@ -51,7 +51,7 @@ bower install --save react
## Contribute
The main purpose of this repository is to continue to evolve React core, making it faster and easier to use. If you're interested in helping with that, then keep reading. If you're not interested in helping right now that's ok too :) Any feedback you have about using React would be greatly appreciated.
The main purpose of this repository is to continue to evolve React core, making it faster and easier to use. If you're interested in helping with that, then keep reading. If you're not interested in helping right now that's ok too. :) Any feedback you have about using React would be greatly appreciated.
### Building Your Copy of React
@@ -81,12 +81,14 @@ At this point, you should now have a `build/` directory populated with everythin
We use grunt to automate many tasks. Run `grunt -h` to see a mostly complete listing. The important ones to know:
```sh
# Create test build & run tests with PhantomJS
# Build and run tests with PhantomJS
grunt test
# Lint the core library code with JSHint
# Build and run tests in your browser
grunt test --debug
# For speed, you can use fasttest and add --filter to only run one test
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 relase tag in the main repository.
**Note:** This should only be done for new releases. You should create a tag corresponding to the release tag in the main repository.
We also have a rake task that does the same thing (without creating commits). It expects the directory structure mentioned above.
"undefined"==typeofc.createDocumentFragment||"undefined"==typeofc.createElement}g=b}catch(d){g=j=!0}})();vare={elements:k.elements||"abbr article aside audio bdi canvas data datalist details figcaption figure footer header hgroup main mark meter nav output progress section summary time video",version:"3.6.2",shivCSS:!1!==k.shivCSS,supportsUnknownElements:g,shivMethods:!1!==k.shivMethods,type:"default",shivDocument:q,createElement:p,createDocumentFragment:function(a,b){a||(a=f);if(g)returna.createDocumentFragment();
React was open sourced two weeks ago and it's time for a little round-up of what has been going on.
## Khan Academy Question Editor
It looks like [Ben Alpert](http://benalpert.com/) is the first person outside of Facebook and Instagram to push React code to production. We are very grateful for his contributions in form of pull requests, bug reports and presence on IRC ([#reactjs on Freenode](irc://chat.freenode.net/reactjs)). Ben wrote about his experience using React:
> I just rewrote a 2000-line project in React and have now made a handful of pull requests to React. Everything about React I've seen so far seems really well thought-out and I'm proud to be the first non-FB/IG production user of React.
>
> The project that I rewrote in React (and am continuing to improve) is the Khan Academy question editor which content creators can use to enter questions and hints that will be presented to students:
> [Read the full post...](http://benalpert.com/2013/06/09/using-react-to-speed-up-khan-academy.html)
## Pimp my Backbone.View (by replacing it with React)
[Paul Seiffert](https://blog.mayflower.de/) wrote a blog post that explains how to integrate React into Backbone applications.
> React has some interesting concepts for JavaScript view objects that can be used to eliminate this one big problem I have with Backbone.js.
>
> As in most MVC implementations (although React is probably just a VC implementation), a view is one portion of the screen that is managed by a controlling object. This object is responsible for deciding when to re-render the view and how to react to user input. With React, these view-controllers objects are called components. A component knows how to render its view and how to handle to the user's interaction with it.
>
> The interesting thing is that React is figuring out by itself when to re-render a view and how to do this in the most efficient way.
>
> [Read the full post...](https://blog.mayflower.de/3937-Backbone-React.html)
## Using facebook's React with require.js
[Mario Mueller](http://blog.xenji.com/) wrote a menu component in React and was able to easily integrate it with require.js, EventEmitter2 and bower.
> I recently stumbled upon facebook's React library, which is a Javascript library for building reusable frontend components. Even if this lib is only at version 0.3.x it behaves very stable, it is fast and is fun to code. I'm a big fan of require.js, so I tried to use React within the require.js eco system. It was not as hard as expected and here are some examples and some thoughts about it.
>
> [Read the full post...](http://blog.xenji.com/2013/06/facebooks-react-require-js.html)
## 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:
> 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)
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.
