* Update example snippet in old 'React.addons' doc page
This makes the example more consistent.
* Add back the pointers in docs that were mistakenly removed
In https://github.com/facebook/react/pull/9359 we accidentally removed
pointers in some doc pages. Putting them back now.
* Link to npm package instead of github page
This seems like a more stable place to link to in the 'context'
document.
Based on @bvaughn's feedback in https://github.com/facebook/react/pull/9359
* `react-addons-test-utils` -> `react-dom/test-utils`
Updating all references and docs on the `React.addons.TestUtils` and the
shallow renderer to refer to the correct targets.
Instead of:
```
const React = require('react');
// ...
React.addons.Testutils
// or
const ReactTestUtils = require('react-addons-test-utils');
```
we now show:
```
const ReactTestUtils = require('react-dom/test-utils');
```
And for shallow renderer, instead of:
```
const shallowRenderer = TestUtils.createRenderer();
```
we now show:
```
const shallowRenderer = require('react-test-renderer/shallow');
```
* Update the 'prev' and 'next' attributes of 'add-ons' docs
These flags are used to set arrow links to easily navigate through the
documents. They were wrong or missing in some of the 'add-ons' pages and
this bothered me when manually testing the updates from the previous
commit.
* Update syntax for instantiating shallow renderer
Missed this when updating the docs for the changes to shallow-renderer
in React 15.5.
* Fix pointers in addons docs
Thanks @bvaughn for catching this
* Make example of shallow renderer more consistent
We should show using the same variable names between code samples.
* Make names in example even more consistent
We should use the same variable name for the same thing across examples.
`renderer` -> `shallowRenderer`.
* Update docs to deprecate React<CSS>TransitionGroup
- removes link to the docs about `ReactCSSTransitionGroup` and
`ReactTransitionGroup` from the main navigation
- updates 'prev' and 'next' pointers to skip this page
- adds deprecation warning to the top of the page
- remove references to these modules from the packages README
- updates 'add-ons' main page to list this as a deprecated add-on
* Update `React.createClass` to `createReactClass` in the docs
The `React.createClass` method is being deprecated in favor of
`createReactClass`.
* Remove 'React.createClass' from top level API docs
It no longer makes sense to have a section for the 'createClass' method
in this page, since it won't be available as a top level method on
'React'.
I initially was going to pull the section about 'createClass' into a
separate page to add under 'addons' but it was short and duplicative of
the 'react-without-es6' docs. So I just linked to those.
* Remove *most* `React.PropTypes` from the docs
I am doing the docs for `context` in a separate commit because that case
was a bit less clear-cut.
We will no longer support `React.PropTypes` as a built-in feature of
React, and instead should direct folks to use the `PropTypes` project
that stands alone.
Rather than retaining the `React.PropTypes` examples and just revamping
them to show the use of the stand-alone `PropTypes` library with React,
it makes more sense to direct people to that project and reduce the
perceived API area and complexity of React core. The proper place to
document `PropTypes` is in the README or docs of that project, not in
React docs.
* Update `context` docs to not use `React.PropTypes`
We use `React.PropTypes` to define the `contextType` for the `context`
feature of React. It's unclear how this will work once `React.PropTypes`
is replaced by the external `PropTypes` library. Some options;
a) Deprecate `context`, either in v16 or shortly after. Seems reasonable
based on the intense warnings against using context that we have in the
docs -
https://facebook.github.io/react/docs/context.html#why-not-to-use-context
**Except** that probably some widely used libraries depend on it, like
`React-Router`.
b) Expect users will use external `PropTypes` library when defining
`contextTypes` and just don't do our `checkReactTypeSpec` against them
any more in v16.
c) Stop masking context and pass the whole context
unmasked everywhere. Worst option, do not recommend.
I went with `b` and assume that, for now, we will get users to use the
external `PropTypes` when defining context. I will update this PR if we
want a different approach.
* Remove 'addons' items from left nav, and deprecate 'addons' doc page
The plan:
[X] Remove links to 'addons' items from main navigation
[X] Add deprecation notices where appropriate, and update syntax to show
using the separate modules.
[ ] Update other references to 'React.addons' in docs. Coming in next
commit.
--- blocked but coming in future PRs
[ ] Link to a blog post describing the new locations of add-ons in the
deprecation notice on the '/docs/addons.html' page. Blocked until we
actually publish that blog post.
[ ] Move the docs for each add-on to the actual github repo where it now
lives.
[ ] Redirect the old add-ons doc permalinks to the docs in the separate
github repos for those modules.
[ ] Remove the old add-ons doc markdown files from React core docs.
* Remove references to `React.addons` from docs
Just misc. places where we referenced the 'addons' feature. All gone!
features → feature
> There is nothing "bad" about using state or lifecycle hooks in components. Like any powerful feature**s**, they should be used in moderation, but we have no intention to remove them.
I can’t explain the exact grammatical principle this violates, but it sounds wrong to my native English ears that “feature” is plural here. Another way to check if the grammar sounds right is to change the order of the clauses: ”They should be used in moderation, like any powerful feature“ sounds right, whereas “They should be used in moderation, like any powerful features” does not.
1. Moved react-addons-test-utils to react-dom/test-utils and added deprecation message.
2. Moved shallow renderer (previous accessible via TestUtils.createRenderer) to react-test-renderer/shallow and added deprecation message.
3. Updated READMEs for react-addons-test-utils and react-test-renderer
* Only re-assign defaultValue if it is different
* Do not set value if it is the same
* Properly cover defaultValue
* Use coercion to be smart about value assignment
* Add explanation of loose type checks in value assignment.
* Add test coverage for setAttribute update.
* Only apply loose value check to text inputs
* Fix case where empty switches to zero
* Handle zero case in controlled input
* Correct mistake with default value assignment after rebase
* Do not assign bad input to number input
* Only trigger number input value attribute updates on blur
* Remove reference to LinkedValueUtils
* Record new fiber tests
* Add tests for blurred number input behavior
* Replace onBlur wrapper with rule in ChangeEventPlugin
* Sift down to only number inputs
* Re-record fiber tests
* Add test case for updating attribute on uncontrolled inputs. Make related correction
* Handle uncontrolled inputs, integrate fiber
* Reorder boolean to mitigate DOM checks
* Only assign value if it is different
* Add number input browser test fixtures
During the course of the number input fix, we uncovered many edge
cases. This commit adds browser test fixtures for each of those instances.
* Address edge case preventing number precision lower than 1 place
0.0 coerces to 0, however they are not the same value when doing
string comparision. This prevented controlled number inputs from
inputing the characters `0.00`.
Also adds test cases.
* Accommodate lack of IE9 number input support
IE9 does not support number inputs. Number inputs in IE9 fallback to
traditional text inputs. This means that accessing `input.value` will
report the raw text, rather than parsing a numeric value.
This commit makes the ReactDOMInput wrapper check to see if the `type`
prop has been configured to `"number"`. In those cases, it will
perform a comparison based upon `parseFloat` instead of the raw input
value.
* Remove footnotes about IE exponent issues
With the recent IE9 fix, IE properly inserts `e` when it produces an
invalid number.
* Address exception in IE9/10 ChangeEventPlugin blur event
On blur, inputs have their values assigned. This is so that number
inputs do not conduct unexpected behavior in
Chrome/Safari. Unfortunately, there are cases where the target
instance might be undefined in IE9/10, raising an exception.
* Migrate over ReactDOMInput.js number input fixes to Fiber
Also re-record tests
* Update number fixtures to use latest components
* Add number input test case for dashes and negative numbers
* Replace trailing dash test case with replace with dash
Also run prettier
* Show Source Error Addemden if __source available
* Add Parent Stack on invalid element type
* refactor to use normalizeCodeLocInfo
* Remove ( ) from addendum
- Backport change to enqueueReplaceState. Use new API instead of
enqueueCallback, which is gone in 16.
- Implement isMounted using lifecycles, so we have the option of
removing this later.
* Updated Chain React
Changed conference date from "Summer 2017" to given date on website
* Updated React Native EU
Updated date and place with information from website
(cherry picked from commit 2b59afb984)
Warns when using React.createClass for the first time.
Usages of createClass in tests have been converted to plain JavaScript
classes. Tests that rely on replaceState or isMounted use
updater.enqueueReplaceState and updater.isMounted.
* Update Lifting State Up not to mix up DOM value with component state
A few weeks ago when teaching my friend, she got stuck on
`this.state.value` vs. `event.target.value`. As the documentation
talked a lot about "values", and the term value could mean three
different things (values in general, the "value" prop / DOM value of
the <input> component and the value in state/props), it was not weird
that she got a bit confused.
* Rename Lifting State Up onChange props to onTemperatureChange
This is in-line with how the temperature is provided as a prop named `temperature`
* Fix one value prop not being renamed to temperature
* Update codepen examples in Lifting state up documentation
* Update devtools state change to reflect docs change
(cherry picked from commit a190cfce29)
* Replace the header_links plugin with client-side generated anchors.
Fixesfacebook/react#4124
* Move anchor-link code into a separate script
Also adds a couple comments, for context.
(cherry picked from commit 7a878d27e3)
* Improved for a better understanding
that code shouldn't name this parameter onchange. It is so confusing for a starter of ReactJs like me. It looks like that the onChange is an common event from props.
* Update the lifting state up paragraph
I tried to write something to explain to starter programmers in react, how we lift the state up calling a method defined by the ancestor and called by the children that will affect the children element.
* Rewrite Lifting State Up
(cherry picked from commit fc362bf095)
* Add note about refs on stateless components
* Move info about refs in the stateless components to the main section
* Simplification of the part about refs and functional components
* Tweaks
* Move sections around
* Oops
* Rearrange more sections
(cherry picked from commit d42c285aa2)
* Explain arbitrariness of ref name in callback
The sample code was confusing because it's not clear that "textInput" in this.textInput is an arbitrary name for the ref.
* Tweak wording
(cherry picked from commit 79be3543dd)
* Add benchmarking tutorial
I've written what I hope is the simplest introduction to benchmarking React components. It's meant to be straightforward and easy to follow for beginners. If you agree that it would be helpful, I'd like to add it to the docs.
Would also welcome any and all feedback.
* Just put links together
(cherry picked from commit 4c6fec902f)
* Added a link to "State Updates are Merged"
* better inline links
* moved the explanation down
* Minor unrelated tweaks
(cherry picked from commit eb89bc4c30)
* Update conferences.md
* Update conferences.md
path fixed
* Changed capitalization to match the website and Twitter
(cherry picked from commit b2b6d9daf7)
* devDependencies: add core-js and es6-symbol polyfill for tests
* Update Flow and fix issues (#8006)
* Add npm v4.0.0 support (#8082)
* Add support for node v7 (#8135)
* Upgrade ESLint and dependencies, fix new lint errors, switch Travis to Yarn (#8309)
* Update ESLint to 3.10.2
Also pull in fbjs for extending properly, per @zpao. This also disables consistent-return, which has about 80 failing cases in React currently. If we'd like to turn this back on, we should do it separately and fix all the call sites properly (rather than just adding 'return undefined;' everywhere, which adds no value.
Fixes to all existing lint errors plus an update for yarn.lock to follow.
* Update yarn.lock after the eslint update.
* Fix all new eslint failures
Unfortunately I had to add three eslint-disable-next-line instances. All have explanations inline.
* Switch Travis to use yarn instead of npm
* Update all Jest packages to 17.x (#8327)
* Update all Jest packages to 17.x, cache babel-jest transforms
* Remove the caching
Looking at the other builds it doesn't seem to actually be that necessary. The bottleneck is executors, not build time.
* Remove unnecessary package, fix fiber test runner
* Regenerate yarn lockfile
* Update Flow to 0.37.0 (#8608)
Nothing really changes.
* Update to Jest 18 (#8621)
* mockImpl -> mockImplementation
D4329549
* Fixed linting errors
* circle.yml and circleci scripts
* Update Flow and fix issues (#8006)
* Fixed flow errors
* Updated shrinkwrap
* Removed unnecessary change
* Added jest --runInBand flag
* Removed ReactDOMFiber changes
* devDependencies: add core-js and es6-symbol polyfill for tests
* Update Flow and fix issues (#8006)
* Add npm v4.0.0 support (#8082)
* Add support for node v7 (#8135)
* Upgrade ESLint and dependencies, fix new lint errors, switch Travis to Yarn (#8309)
* Update ESLint to 3.10.2
Also pull in fbjs for extending properly, per @zpao. This also disables consistent-return, which has about 80 failing cases in React currently. If we'd like to turn this back on, we should do it separately and fix all the call sites properly (rather than just adding 'return undefined;' everywhere, which adds no value.
Fixes to all existing lint errors plus an update for yarn.lock to follow.
* Update yarn.lock after the eslint update.
* Fix all new eslint failures
Unfortunately I had to add three eslint-disable-next-line instances. All have explanations inline.
* Switch Travis to use yarn instead of npm
* Update all Jest packages to 17.x (#8327)
* Update all Jest packages to 17.x, cache babel-jest transforms
* Remove the caching
Looking at the other builds it doesn't seem to actually be that necessary. The bottleneck is executors, not build time.
* Remove unnecessary package, fix fiber test runner
* Regenerate yarn lockfile
* Update Flow to 0.37.0 (#8608)
Nothing really changes.
* Update to Jest 18 (#8621)
* mockImpl -> mockImplementation
D4329549
* Fixed linting errors
* circle.yml and circleci scripts
* Update Flow and fix issues (#8006)
* Fixed flow errors
* Updated shrinkwrap
* Removed unnecessary change
* Added jest --runInBand flag
* Removed ReactDOMFiber changes
* Reminder: strip quotes from attributes with JS code
Web developers who are used to standards-compliant HTML and XML will, out of habit, put quotes around all attributes because the standards require them. Other templating systems like ASP.NET also require (or at least allow) quotes around attributes that contain code. This behavior will get users into trouble in JSX because a quoted attribute is always treated as a string literal, even if it contains curly-braced javascript code. Let's add to the docs to help newbies evade this problem.
* Tweak wording
(cherry picked from commit fc302494b7)
* use an easier word
The word `mandatory` is relatively difficult for people with ESL (English as a second language), so I propose an alternative word.
This would be much easier to understand.
* use simpler word
(cherry picked from commit 6308238498)
* Added flow to PR template
* Added record-tests step to PR template and contribution docs
* Updated order of PR checks
(cherry picked from commit bfd5b1878e)
* Update refs-and-the-dom.md
I want to propose some changes to the Refs and the DOM documentation page.
- Make it clear that string refs are legacy. It seems that this information got lost during the transition to new docs and only some part stayed the same, which was confusing when first reading the docs.
- Clarify and explain that during render, if the ref callback is provided, it will get called twice, first with `null` and then with the rendered DOM element. Discussed in https://github.com/facebook/react/issues/4533 and first proposed docs change in PR #8333.
I've also planned on adding an example for passing the refs up the component chain based on something I've needed to solve myself (e.g. you want to connect two dynamic components by line in React, so you need to both use refs and propagate them up the chain), and while it would be great to read up on this in the docs, it may be too specific for this section; I'd be happy to hear any recommendations.
* Adds more specific information about the callback
* Moved the ref callback description to the Caveats section
* Fixed suggested nits
* Replace 'each render pass' with 'updates'
* Tweak the wording
(cherry picked from commit 4a7e06bab7)
* Add manual build fixtures
* Inject ReactDOM into ReactWithAddons from ReactWithAddons
We used to read ReactDOM as a global inside ReactAddonsDOMDependenciesUMDShim.
This didn't work in AMD environments such as RequireJS and SystemJS.
Instead, I changed it so that ReactDOM gets injected into ReactWithAddons by ReactDOM itself.
This way we don't have to try to require it (which wouldn't work because AMD doesn't handle circular dependencies well).
This means you have to load ReactDOM first before using ReactDOM-dependent addons, but this was already the case before.
This commit makes all build fixtures pass.
* Memoize ReactDOM to avoid going into require on every access
* Add Brunch fixture
* Inline requires to work around Brunch bug
See #8556 and https://github.com/brunch/brunch/issues/1591#issuecomment-270742503 for context.
This appears to be a Brunch bug but we can keep a temporary fix until the next major.
(cherry picked from commit ca2c71c0c5)
**What** and **Why**:
* When using npm version 2, `object-assign` and `fbjs` were not getting properly installed
* This PR adds `object-assign` and `fbjs` as explicit dependencies to both `react-test-renderer` and `react-addons`
(cherry picked from commit 7cd26024ce)
* Check if textContent should be set for textarea
shouldSetNodeTextContent returns whether a node.textContent should be
updated. Currently it only covers one case, which is to avoid setting
the textContent if the text is empty and a placeholder exists.
* Only set node.value if it's equal to initialValue
In IE11 textContent is populated when the placeholder attribute is set.
Without this check, we end up setting node.value equal to the
placeholder text, causing the textarea to actually render with the text
inside.
This check makes sure that textContent is equal to our expected
initialValue, which should be the case when using defaultValue.
* Remove placeholder/textarea check, use contentToUse instead
(cherry picked from commit e644faa610)
* Consider Host Component classes when creating a new internal instance
* Remove unused tagToComponentClass & injectComponentClasses from ReactHostComponent
(cherry picked from commit 461a74115c)
* Only assign defaultValue if it has changed.
* Improve comment about reason for defaultValue conditional assignment
(cherry picked from commit 0d20dcf910)
* Fix typo in Proposing a Change section in how-to-contribute.md
Not sure if it was actually intended or was a typo but changed 'If you intend to change to the public API' --> 'If you intend to make a change to the public API'
* Simplify
* Component Lifecycle In Depth documentation
* first steps to improve react component reference
* improved react component reference
- remove the component-lifecycle-in-depth
* add a note for usage of ReactDOM.findDOMNode
* one note on componentWillReceiveProps
* remove old useless images for lifecycle docs
* Tweak wording
- In the previous example, the code works even without using bind(this) in the constructor.
- the reason being handleClick doesn't even use `this` and its just calling the global function alert.
- this change make use of this via access this.state.
My first contribution to React!
While upgrading a React project, I found some suspect SVG that needed updating, so I dug in after checking the docs. I knew that support for some SVG properties had been added (namely `xmlns` and `xmlnsXlink`), but I noticed them missing from the reference's attribute list. This pull request updates `reference-dom-elements.md` by adding said properties.
Fix for #8308. This is a bad hack -- EventPluginHub.getListener isn't even DOM-specific -- but this works for now and lets us release 15.4.1.
(cherry picked from commit c7129ce1f0)
* Fix browser bundle for AMD
* Final fix for standalone browser build.
Much more scientific than the rest so it should stick.
* Throw when we can't find code we need to replace.
(cherry picked from commit a3ba48bf72)
Showing how to create a form without labeling inputs is an accessibility anti-pattern. This change adds labels to the examples to address that. Codepen may still need to be updated depending on how that example is created.
* Remove spread operator
I believe what was meant here was to express that you would create the new player object with all the previous properties of the existing player object in addition to now updating the score value. That being said, this is a simple example, and the player object clearly has no other values. Objects are not (by default) iterable using this operator, so this little piece does more harm than good. I believe the new example to be much clearer.
* Using Object.assign()
* Tweak wording
* Update tutorial.md
Is it possible to be more clear here?
This implies that we are removing the constructor from GAME, and not board (which is what I believe the author is trying to say).
It took me several reads to understand.
With this edit, it is now clear that the adjustment is being made to -Board- and not to -Game-
* also remove "for Board earlier"
* Make the Shallow Rendering example clearer
I was reading through the documentation, and I found that the `render` call on the `renderer` was missing.
* Use a regular function to define MyComponent
(cherry picked from commit 53e45e78e4)
* fix broken links to outdated code
* another broken links to outdated code
* update hash commit & folder structure to current
(cherry picked from commit b847226ec4)
* Use _hostContainerInfo to track test renderer options
The transaction is not available when unmounting or updating the
instance, so we track it using _hostContainerInfo
* Throw if hostContainerInfo is not populated in getPublicInstance
* Linting fixes
* Remove transaction from ref lifecycle code path
We don't need to pass the transaction around anymore since we store the
test options on _hostContainerInfo instead
* Remove unused argument
(cherry picked from commit e43aaab254)
Prior to this, React was using a nextDebugID variable that was locally
scoped to both `instantiateReactComponent` and `ReactShallowRenderer`.
This caused problems when the debugIDs would collide, the `itemMap` in
`ReactComponentTreeHook` would be overwritten and tests would fail
with the message "Expected onBeforeMountComponent() parent and
onSetChildren() to be consistent".
This change shares the debugID with both modules thus preventing any
collisions in the future.
(cherry picked from commit 6eebed0535)
* took codes.json from the 15-dev branch
* fixed react:extract-errors task in gulpfile
* generated error codes
* Revert "generated error codes"
This reverts commit b8f3aeed9d8f0d469edd5f6623fa6090930594d8.
* Added a README for the error code system
* took codes.json from the 15-dev branch
* fixed react:extract-errors task in gulpfile
* generated error codes
* Revert "generated error codes"
This reverts commit b8f3aeed9d8f0d469edd5f6623fa6090930594d8.
* Added a README for the error code system
Gets rid of an obsolete word in the documentation for "State and Lifecycle":
"Consider the ticking clock example from the one of the previous sections."
->
"Consider the ticking clock example from one of the previous sections."
The code section above these changes defines a `formatName` function
that expects a parameter `user`. The code section containing these
changes incorrectly called `formatName(user.name)`. For those following
along with CodePen, this section should correctly call
`formatName(user)`.
* Reapplied fixes to updated docs from master
* Reapplied fixes to Forms, removed ES2016 function includes()
* Missing carriage return
* Adding back some line breaks
* Making requested changes.
* Making space changes
* Fixed typo and removed unnecessary hyphen.
* Reworded select, and highlighted line
* Fixed string styles
* Refactored <label> to use htmlFor
* Another refactor of <label>
* Removed name prop from radiobutton
* Reapplied fixes to updated docs from master
* Reapplied fixes to Forms, removed ES2016 function includes()
* Missing carriage return
* Adding back some line breaks
* Making requested changes.
* Making space changes
The tutorial wants to throw a 'warning' and explains about 'key' of React's list, but it throws nothing since there is sensible key.
"key={move}" should be removed, and added after explaining about key.
The script that strips providesModule is very sensitive.
Test plan:
Searched for providesModule in build. No more.
reactComponentExpect used to have problems too but doesn't seem
to anymore. Don't know why.
* Add more to Codebase Overview
* WIP
* Start a reconciler overview
* Add a few more sections
* todo
* WIP
* Finish it
* Whitespace
* Minor tweaks
* Minor tweaks
* Ensure lib/ is packaged for react-test-renderer
* Run npm pack from right working directory
We were running this on the original packages not the compiled ones, resulting in missing files
(cherry picked from commit 077d660a27)
This is a manual cherry-pick of 2 PRs, updated to handle differences in the stable branch:
- c78464f8ea - Resolve flow errors with ReactTestRenderer (#7736)
- 7dfa01f9fa - Revert ReactMultiChild to plain object (#7757)
This should be more of a fair A/B test so the timings aren't affected by having different load on your system when testing the two alternatives.
(cherry picked from commit c0007d56e9)
* Add a hook that throws a runtime warning for invalid WAI ARIA attributes and values.
* Resolved linting errors.
* Added a test case for many props.
* Added a test case for ARIA attribute proper casing.
* Added a warning for uppercased attributes to ReactDOMInvalidARIAHook
(cherry picked from commit 59ff7749ed)
When you put the output of a bash command in a variable, it replaces the `\n` with a space. Using `ls` instead of `echo` fixes it
Test Plan:
Run
```
ALL_FILES=`find src -name '*.js' | grep -v umd/ | grep -v __tests__ | grep -v __mocks__`
COUNT_ALL_FILES=`ls $ALL_FILES | wc -l`
echo $COUNT_ALL_FILES
```
Make sure that it outputs 221
(cherry picked from commit 72ed5df5a4)
Use the newly added tracking system to track the number of fiber tests that are passing/failing.
I first tried to modify the grunt lint rule for it and send the output in stdout but unfortunately grunt displays the rule + done messages there. I had like 30 lines of js already and I figured I could just write 3 lines of bash and it would work the same. Let me know if you want me to use another approach for it.
Test Plan:
Run the commands that have been introduced in this commit but the facts-tracker one
Run `echo $FIBER_TESTS` and make sure it prints `666/1434`
(cherry picked from commit 84f8df1f89)
* Introduce facts-tracker
We want to be able to track various things like number of files that are flowified, number of tests passing with Fiber...
This introduces a tool that lets you do that. The API is very simple, you execute the script with a list of tuples [key value] and it's going to create a `facts` branch and put a txt file for each fact and values over time.
```
node scripts/facts-tracker/index.js \
"flow-files" "$COUNT_WITH_FLOW/$COUNT_ALL_FILES"
```
Test Plan:
This is tricky to test because Travis only exposes the private variables (github token) when it processes a committed file and not on branches. The reason is that otherwise anyone could send a pull requests that does `echo $GITHUB_TOKEN` and steal your token.
Given this constraint, I did all the work using two of my repos:
- https://github.com/vjeux/facts-tracker
- https://github.com/vjeux/facts-tracker-test
and am sending this pull request that should work as is /fingers crossed/, but we won't be able to test it out until it is committed.
Note that once this lands, I'm going to kill those two repos.
* Update with all the suggested changes
* Branch on a flow type in travis.yml
* Use $GITHUB_TOKEN
* properly escape it
(cherry picked from commit dbd9c4b205)
This ensures we ignore relative to our project root and won't be tripped up by issues where checkouts in other places result in Flow passing when it shouldn't (eg on Travis CI where the checkout path is `/home/travis/build/facebook/react`)
(cherry picked from commit 864bc7b939)
* create ReactTestTextComponent fil
* create ReactTestEmptyComponent
* Use class for ReactTestRenderer
* Add flow to ReactTestRenderer
(cherry picked from commit 5a3abab660)
* High priority work
Adds the ability to schedule and perform high priority work. In the
noop renderer, this is exposed using a method `performHighPriWork(fn)`
where the function is executed and all updates in that scope are given
high priority.
To do this, the scheduler keeps track of a default priority level.
A new function `performWithPriority(priority, fn)` changes the default
priority before calling the function, then resets it afterwards.
* Rename overloaded priority terms
"High" and "low" priority are overloaded terms. There are priority
levels called HighPriority and LowPriority. Meanwhile, there are
functions called {perform,schedule}HighPriWork, which corresponds
to requestAnimationFrame, and {perform,schedule}LowPriWork, which
corresponds to requestIdleCallback. But in fact, work that has
HighPriority is meant to be scheduled with requestIdleCallback.
This is super confusing.
To address this, {perform,schedule}HighPriWork has been renamed
to {perform,schedule}AnimationWork, and
{perform,schedule}LowPriWork has been renamed to
{perform,schedule}DeferredWork. HighPriority and LowPriority
remain the same.
* Priority levels merge fix
(cherry picked from commit 6144212a86)
* Implement optional mockConfig and getMockRef
* default mockConfig, walk render tree
* Pass mockConfig to transaction
* Attach mockConfig to transaction
* type mockConfig in ReactRef
* Expect object in native component ref test
* Fix argument name for attachRefs
* Add mockConfig support to legacy refs
* Pass transaction to getPublicInstance
* Implement getMockConfig on ReactTestReconcileTransaction
* Merge defaultMockConfig and mockConfig options
* Rename mockConfig to testOptions
* Break getPublicInstnce into three lines
* createMockRef -> createNodeMock
(cherry picked from commit f3569a2c31)
Due to a typo in PR#7667 where I put 'DispatchConfig' when the type was
'EventTypes', there were some flow errors being thrown.
Then PR#7642 fixed a bug in SimpleEventPlugin and added some untyped
methods, which threw more flow errors.
Last, while fixing this, I fixed two eslint errors in the
SimpleEventPlugin test.
(cherry picked from commit 54cbe29262)
* Cull disabled mouse events at plugin level. Remove component level filters
* DisabledInputUtils tests are now for SimpleEventPlugin
* Add click bubbling test
* Add isInteractive function. Use in iOS click exception rules
* Invert interactive check in local click listener. Add test coverage
* Reduce number of mouse events disabable. Formatting in isIteractive()
* Switch isInteractive tag order for alignment
* Update formatting of isInteractive method
(cherry picked from commit 73c50e7d00)
In order to properly type an `Operation`, we need to change the call site from having two arguments: one for `type` and one for `payload` into an object that contains both. This isn't a perf regression because we were already constructing this object in the first place and doesn't change the emitted event so shouldn't affect the dev tools.
None of the call sites are actually flow-ified so it isn't technically used but once we will, it'll make sure that we don't send random strings and payload through those very generic methods.
(cherry picked from commit eaefd9052a)
React IDs have been killed and there was one call site left in a test. I trimmed down the implementation to keep only what is actually used and inlined it inside of the test so we don't get more people using it in the future.
(cherry picked from commit 82598eec79)
* Type SimpleEventPlugin and TapEventPlugin
- Renamed file from 'ReactSynteticEvent' to 'ReactSyntheticEventType'
- Fills in the 'any' holes that were left in DispatchConfig type and the
type annotations in EventPluginRegistry.
- Adds polymorphic PluginModule type and related types
- Uses hack to support indexable properties on 'Touch' type in
TapEventPlugin
The issue in TapEventPlugin is that the code is accessing one of four
possible properties on the 'Touch' type native event using the bracket
accessor. Classes in Flow don't support using the bracket accessor,
unless you use a declaration and the syntax `[key: Type]: Type`.[1] The
downside of using that here is that we create a global type, which we
may not need in other files.
[1]: https://github.com/facebook/flow/issues/1323
Other options:
- Use looser typing or a '@FixMe' comment and open an issue with Flow to
support indexing on regular classes.
- Rewrite TapEventPlugin to not use the bracket accessor on 'Touch'. I
thought the current implementation was elegant and didn't want to
change it. But we could do something like this:
```
if (nativeEvent.pageX || nativeEvent.pageY) {
return axis.page === 'pageX' ? nativeEvent.pageX : nativeEvent.pageY;
} else {
var clientAxis = axis.client === 'clientX' ? nativeEvent.clientX : nativeEvent.clientY;
return nativeEvent[axis.client] + ViewportMetrics[axis.envScroll];
}
```
(cherry picked from commit 7b2d9655da)
It turns out that flow cannot type `this` with a function constructor + prototype overrides. Turning it to a class makes flow happy and has minimal impact on the output.
In open source, we already use the loose version of the class transform and internally we have one that's outputting even less code if you have `@preventMunge` in the header.
See discussion in https://www.facebook.com/groups/2003630259862046/permalink/2098480820376989/
(cherry picked from commit a70acb37d9)
We disabled coverage in Travis because the implementation was crashing ( https://github.com/facebook/react/issues/6290 ). Since we upgraded to Jest 15, the entire coverage implementation is brand new so we should give it another try.
(cherry picked from commit 839697f60c)
We used to copy and paste the same big blob many times in order for it to work with keyOf which is no longer a constraint. This pull request takes a list of all the events as string and generate those data structures at runtime.
It reduces the size of React by 1k post gzip and flow is able to extract the structure out of it :)
(cherry picked from commit 1229a238c4)
This is the last callsite of keyMirror! It removes 0.5k gzipped :)
The only trick with this one is that ReactTestUtils actually iterates over the list of all the events. Instead of duplicating the logic, I used the $Enum feature of flow that lets us statically extract out the type from the dynamic value. Inside of react-dom we're no longer requiring the file directly so it doesn't bloat the file size, and we still get to have static typing, best of both worlds!
(cherry picked from commit 2f9a9dc4c5)
This one is interesting because we have transaction objects being passed around everywhere in the codebase but there's actually no Transaction class. It's a "mixin" that comes to life by being Object.assigned to the prototype of a real "class" (before class was cool!). Therefore, we can't just say `var Transaction = require('Transaction'); (transaction: Transaction) => { }` because it would be the object that contains a mixin and not an instance of a transaction.
The trick I use is to export `TransactionType` and alias it to `Transaction` in the file as it doesn't actually require transaction. In case they do, we'll figure it out, but in the few files I looked at, it doesn't seem to be the case.
For the perform function, it actually typechecks pretty well!
(cherry picked from commit a3e576e1bb)
This one was really interesting to type as it's doing a lot of unusual JavaScript. Fortunately flow is now pretty kick ass and I've been able to mostly type it. The only missing piece is that it won't check the constructor arguments.
If you are a fb employee, you can follow the discussion here: https://www.facebook.com/groups/flowtype/permalink/1132359430146004/
(cherry picked from commit 19b8eadb24)
Incrementally type ReactInstance by adding the types of attach/detachRef.
I moved isValidOwner as a function inside of the file since it's never used externally.
(cherry picked from commit fa9869b5a0)
This one involves a bit more work as I added "phantom" flow types to a bunch of places where the type is a ReactPropTypeLocations even though those files are not `@flow` yet.
A good side effect is that `ReactPropTypeLocationNames` keys are now correctly typed, this means that they cannot go out of sync without breaking flow :)
(cherry picked from commit 84084153ed)
Flow doesn't really support the concept of variables that are non-null but only inside of a `__DEV__` block. There's an internal post about it ( https://www.facebook.com/groups/flowtype/permalink/1132437726804841/ ) and the conclusion is that we should force it to be non-null and trust the developer to put the proper DEV checks in place.
(cherry picked from commit 0d927844fb)
We need to export FlushHistory type and I submitted a PR on flow to fix the type of console.table which is too restrictive.
I'm already starting to see the benefits of flow, I can look at random variables in the code and flow knows what shape the objects are! It's really useful to try and understand what's going on :)
(cherry picked from commit 2fb5eae372)
It turns out that we don't need it, flow is smart enough to realize that the function is declared in the two branches :)
(cherry picked from commit b977cf13c4)
In Type ReactComponentTreeHook #7504, I merged even though travis didn't report green (travis for all the fb repos has been backlogged like crazy since this morning) by manually doing `npm test` and `npm run flow` but I didn't ensure that lint was all green.
@millermedeiros pinged me about it so here's a quick fix
(cherry picked from commit 66e77f696a)
For this one, I wanted to type a non-trivial piece of the codebase and ran into the fact that we do not have types for ReactElement nor ReactInstance, so I had to create them.
I'll add comments inline
(cherry picked from commit ea494a2c10)
* Show React events in the timeline when ReactPerf is active
This currently only seems to work on Chrome.
* Address Chrome issue
(cherry picked from commit 0a248ee7b9)
I already had to aliasify to have better control over the requires
so we might as well do it everywhere for consistency.
This probably makes it easier to rebase the rollup work too
because aliases seems to be how you solve this in that world.
(cherry picked from commit c8f7215b20)
This is needed for flat builds. It also lets us get rid of a bunch
of special cases in the build scripts.
It also allow us to just copy the source files into React Native
instead of having to build first to resolve the special cases.
(cherry picked from commit 1c5a639c37)
This builds a `react-dom-fiber.js` bundle which exposes ReactDOMFiber.
This allows early experiments with the new Fiber reconciler.
I also expose it in the npm package through `react-dom/fiber`.
(cherry picked from commit f7e0db9a18)
This copies modules into three separate packages instead of
putting it all in React.
The overlap in shared and between renderers gets duplicated.
This allows the isomorphic package to stay minimal. It can also
be used as a direct dependency without much risk.
This also allow us to ship versions to each renderer independently
and we can ship renderers without updating the main react package
dependency.
(cherry picked from commit 0f004efce2)
We currently write all our tests against the DOM implementation.
I need a way to run the Fiber tests against it. But I don't want
to take on any package dependencies on Fiber modules yet.
There's a problem with jest right now where you can't globally
mock modules that already exist. So I have to add a global call
to jest.mock.
Luckily we already have a way to test the useCreateElement paths
using a feature flag. I won't activate this flag in travis until
it passes, but the idea is to run all three variants in travis.
I'm not sure that invoking rAF and rIC synchronously is the best
way to test this since it doesn't capture the backwards
compatibility aspect. I.e. the fact that people might be relying
on the synchronous nature in real apps too. It's a start.
Ideally, jest would have these built-in.
(cherry picked from commit c06a68a10b)
Without this we end up bundling all of the isomorphic React into
the DOM bundle. This was fixed in #7168 too but I'll just do an
early fix to ensure that #7168 is purely an npm change.
(cherry picked from commit ca9167c202)
* Cut out isomorphic dependencies from the renderers
These files reaches into isomorphic files.
The ReactElement functions are exposed on the React object anyway
so I can just use those instead.
I also found some files that are not shared that should be in
renderers shared.
* Found a few more shared dependencies
renderSubtreeIntoContainer is only used by the DOM renderer.
It's not an addon.
ReactClass isn't needed as a dependency since injection doesn't
happen anymore.
* Use a shim file to load addons' dependencies on DOM
By replacing this intermediate file we can do the lazy loading
without needing any lazy requires. This set up works with ES
modules.
We could also replace the globalShim thing with aliased files
instead for consistency.
* Bundle DOM renderers into their individual UMD bundles
Instead of exposing the entire DOM renderer on the react.js
package, I only expose CurrentOwner and ComponentTreeDevtool which
are currently the only two modules that share __state__ with the
renderers.
Then I package each renderer in its own package. That could allow
us to drop more server dependencies from the client package. It
will also allow us to ship fiber as a separate renderer.
Unminified DEV after before
react.js 123kb 696kb
react-with-addons.js 227kb 774kb
react-dom.js 668kb 1kb
react-dom-server.js 638kb 1kb
Minified PROD after before
react.min.js 24kb 154kb
react-with-addons.min.js 37kb 166kb
react-dom.min.js 149kb 1kb
react-dom-server.min.js 144kb 1kb
The total size for react.min.js + react-dom.min.js is +19kb larger
because of the overlap between them right now. I'd like to see
what an optimizing compiler can do to this. Some of that is fbjs
stuff. There shouldn't need to be that much overlap so that's
something we can hunt. We should keep isomorphic absolutely
minimal so there's no reason for other React clones not to use it.
There will be less overlap with Fiber.
However, another strategy that we could do is package the
isomorphic package into each renderer bundle and conditionally
initialize it if it hasn't already been initialized. That way
you only pay an overlap tax when there are two renderers on the
page but not without it. It's also easier to just pull in one
package. The downside is the versioning stuff that the separate
npm package would solve. That applies to CDNs as well.
ReactWithAddons is a bit weird because it is packaged into the
isomorphic package but has a bunch of DOM dependencies. So we have
to load them lazily since the DOM package gets initialized after.
(cherry picked from commit 8ef00dbb7d)
* PropTypes: distinguish nullable from optional object field
This gives a more precise message (no type semantics change) to the case of passing a field in an object, but whose value is `null`:
Before:
```js
propTypes: {
foo: React.PropTypes.number.isRequired
}
```
Would scream "Required prop `foo` was not specified in `MyComp`".
Now it'll be "Required prop `foo` was specified in `MyComp`, but its value is `null`.".
Works as expected in nested objects.
This fixes the issue of a component transitively passing a `null`, specifying the correct field to the child but have the child tell it that it didn't provide the prop.
Optional field and nullable are two different things anyway.
* Add missing test case.
* Reword messages.
(cherry picked from commit 0292d34047)
* Reduce confusion in testing documentation.
Just wanted to add some clarity to this page and link to the react tutorial on Jest's website to give people more information. Also changed enzyme's definition from library to utility to help reduce the confusion. Hope this makes sense to everybody :)
See https://twitter.com/damusnet/status/780752042675597312
cc @lelandrichardson
* Update 10.4-test-utils.md
(cherry picked from commit 0990c93806)
* Russian translation for self-closing-tag of tips
* Fix next link for inline styles tip
* Update 04-self-closing-tag.ru-RU.md
(cherry picked from commit 7d5c70d98c)
To demonstrate multiple arguments `bind(this, arg1, arg2, ...)`, also not to pass in for than what `handleClick` needed, namely props, or maybe even pass item itself, etc.
Going to change the kor file after review.
(cherry picked from commit 05cbc93401)
comments to issue #7317.
Updated JP doc examples to match other languages
Reformat to match JSX multi-line style #7550
(cherry picked from commit 3071f31d04)
It used to be slow whenever a type miss occurred because expensive `Error` objects were being created. For example, with `oneOfType([number, data])`, passing a date would create an `Error` object in `number` typechecker for every item.
The savings depend on how much commonly you used `oneOfType()`, and how often it had “misses”. If you used it heavily, you might see 1.5x to 2x performance improvements in `__DEV__` after this fix.
(cherry picked from commit 680685bec4)
* Add propsTypes and defaultProps example for stateless functions
* Update 05-reusable-components.md
* Update 05-reusable-components.md
(cherry picked from commit 09f0a06b8a)
* Write failing test
* Ensure .min and .max are set before .value
* Adjusting test for false negative
* Revert test adjustment (apparently it was only failing locally)
(cherry picked from commit 3013afe2d5)
ReactElement requires a generic argument now and the return function of render is a ReactTestInstance and not a ReactElement.
(cherry picked from commit 9a48b5ca7b)
* Remove onBeforeMountComponent hook event
It is unnecessary.
We now pass the element as part of onInstantiateComponent, and it can't change before mounting.
* Remove onComponentHasMounted hook event
It is unused after #7410.
* Replace on(Begin|End)ReconcilerTimer hook events
We already have onBeforeUpdateComponent.
Let's just have on(Before?)(Mount|Update|Unmount)Component and stick with them.
This removes double event dispatches in some hot spots.
* Remove onComponentHasUpdated hook
The tests still pass so presumably it was not necessary.
* Add missing __DEV__ to TestUtils code
* Replace on(InstantiateComponent|SetParent) with onBeforeMountComponent
This lets us further consolidate hooks.
The parent ID is now passed as an argument to onBeforeMountComponent() with the element.
* Remove onMountRootComponent hook event
It is unnecessary now that we pass the parent ID to onBeforeMountComponent.
* Use parentDebugID = 0 both for roots and production
This removes some awkward branching.
(cherry picked from commit 0e976e136c)
* Remove unnecessary indirection from the tree hook
* Replace onSetDisplayName, onSetOwner, onSetText with one event
Less events is better.
onSetDisplayName, onSetOwner, and onSetText only existed because we didn't initially track elements.
* Remove unused variables
(cherry picked from commit 1f31357a2e)
* Comment previous occurrences of this issue
* Fix DEV performance regression in V8
* Extract try/catch into a separate function when calling hooks
(cherry picked from commit afa27bc4d5)
* Prevent internal performance regression
This only affects Facebook website, not open source version of React.
On the Facebook website, we don't have a transform for warnings and invariants.
Therefore, expensive arguments will be calculated even if the warning doesn't fire.
This fixes a few cases where that calculation might be more expensive than usually.
In my testing, this brings down average row click time in Power Editor from ~300ms to ~220ms in __DEV__ (vs ~40ms in prod).
* Put warning() that shows up in profile behind condition
(cherry picked from commit 178cb7d339)
* corrected ReactChildrenMutationWarningHook's name
* changed `onComponentHasMounted` to `onMountComponent`
and get element from `ReactComponentTreeHook` instead of keeping an internal store
(cherry picked from commit 5514ea369d)
'change' custom events raise "Member not found" in <= IE10. To
circumvent this, the SyntheticEvent class now checks for "typeof
event.cancelBubble !== 'unknown'". This eliminates this exception and
maintains the expected bubbling functionality.
Addresses #7320.
(cherry picked from commit 2823dfcbfb)
For controlled inputs, `updateWrapper` was getting called before the
`type` prop had a chance to update. This could lead to a case where
switching from the `text` to `number` type caused a validation error
that would prevent the proper input value from being assigned.
This commit moves the call to `ReactDOMInput.updateWrapper` below
`_updateProperties` to avoid this situation.
(cherry picked from commit 08a0895887)
* Update tutorial with reference to autobinding docs
* Update tutorial to clarify that autobinding happens specifically with createClass() API
(cherry picked from commit f329099831)
"It is worth repeating: there is no configuration files or complicated folder structures." > "It is worth repeating: there are no configuration files or complicated folder structures."
(cherry picked from commit c0b7d81872)
* Eagerly evaluate inline requires in Jest
I inlined some requires in #7188 to fix the build size regression.
However this caused an issue with Jest due to it resetting module registry between tests.
This is a temporary fix to #7240.
It should be reverted as part of #7178.
* Make the hack work in all environments
(cherry picked from commit 15ae5857f6)
I caused it with #7189.
We generally don’t recommend running TestUtils in production environment but this is technically a regression.
Fixes#7231.
(cherry picked from commit 27d7592cf6)
Adds `.update(newElement)` and `.unmount()` and makes children reorders and composite type swapping work.
Part of #7148.
(cherry picked from commit caec8d5ce7)
Previously, the extract-components script would create the same number of layers of composites as the page it captures, but it would output a new class for each time any composite is used (since we don't want to replicate all the component logic).
I changed the script to output a single type for each type in the input -- and each generated component takes an index for which output it should return. This should be closer to how the original code behaves, especially with respect to VM function call lookups where the amount of polymorphism makes a difference.
I re-recorded the benchmarks with the new scripts. They run significantly faster:
```
Comparing old.txt (control) vs new.txt (test)
Significant differences marked by ***
% change from control to test, with 99% CIs:
* ssr_pe_cold_ms_jsc_jit
% change: -41.73% [-43.37%, -40.09%] ***
means: 39.3191 (control), 22.9127 (test)
* ssr_pe_cold_ms_jsc_nojit
% change: -44.24% [-46.69%, -41.80%] ***
means: 45.8646 (control), 25.5764 (test)
* ssr_pe_cold_ms_node
% change: -45.61% [-47.38%, -43.85%] ***
means: 90.1118 (control), 49.0116 (test)
```
This is probably in part due to the changes here, but also the page I captured has changed somewhat in the meantime and there seem to be slightly fewer components in the hierarchy, so they're not really comparable. But going forward we can use this benchmark which should be more accurate. I also included an identical copy that uses stateless functional components so we can test optimizations to those later.
(cherry picked from commit e5513eceff)
As reported in #7227, unmounting performance regressed with React 15.
It seems that `delete` has become much slower since we started using numeric keys.
Forcing dictionary keys to start with a dot fixes the issue.
(cherry picked from commit 64e7602b3b)
This provides an easy way to indicate that components should only rerender when given new props, like PureRenderMixin. If you rely on mutation in your React components, you can continue to use `React.Component`.
Inheriting from `React.PureComponent` indicates to React that your component doesn't need to rerender when the props are unchanged. We'll compare the old and new props before each render and short-circuit if they're unchanged. It's like an automatic shouldComponentUpdate.
(cherry picked from commit c8fbdac227)
* Warn if PropType function is called in production
* Check if console is undefined before warning
* Randomize value of ReactPropTypesSecret
* Remove dev environment tests
* Rename typeCheckPass to productionWarningCheck
* Rename productionWarningCheck to expectWarningInProduction
* Call toString on Math.random()
* Rename test block for React type checks
* Make sure warning isnt emitted for failing props
* Cache warning by component and prop, warn in dev
* Pass ReactPropTypesSecret to internal checks
* Move tests to ReactPropTypes-test.js
* Update the warning message to include link
* Do not test warning for unions with invalid args
(cherry picked from commit 95ac239cf3)
* Fix for 5468: Validate proptype definitions sooner
Added typeCheckWarn() func and updated the oneOf/oneOfType tests
Added __DEV__ warning for invalid oneOf/OneOfType args
* Suppress redundant error on warn; typeCheckWarn() removed
* Return no-op
* Using emptyFunction module for consistency
* Remove createChainableTypeChecker() call
* Adjust test to assert type check passes when warned
(cherry picked from commit 6cc037bd0d)
This was added to catch internal errors in React but doesn't seem to be doing much good except frustrating people more when their apps throw (#6895, FB-internal t11950821). Until more proper error boundaries land, let's make this a warning.
(cherry picked from commit abcd567325)
Although it is unreasonable to set every possible property for
simulated events, `type` is useful for event handlers that are shared
between types and potentially have different behaviors.
(cherry picked from commit 5a20d449f6)
* Resolve refs in the order of the children
React makes no guarantees about ref resolution order. Unfortunately, some of the internal Facebook component APIs (specifically, layer dialogs) currently depend on the ref resolution order. Specifically, the assumption is that if the layer dialog is placed as a last child, by the time it mounts or updates, the refs to any previously declared elements have been resolved.
With the current `ReactMultiChild`, this is *usually* the case but not always. Both initial mount and an update of all components satisfy this assumption: by the time a child mounts or updates, the previous children’s refs have been resolved. The one scenario where it isn’t true is when **a new child is mounted during an update**.
In this case, the `mountComponent()` call used to be delayed until `ReactMultiChild` processes the queue. However, this is inconsistent with how updates normally work: unlike mounting, updating and unmounting happens inside `ReactChildReconciler.updateChildren()` loop.
This PR changes the `mountComponent()` to be performed inside `ReactChildReconciler`, just like `receiveComponent()` and `unmountComponent()`, and thus ensures that `attachRef()` calls are enqueued in the order the children were processed, so by the time the next child flushes, the refs of the previous children have been resolved.
This is not ideal and will probably be broken by incremental reconciler in the future. However, since we are trying to get rid of mixins in the internal codebase, and layered components are one of the biggest blockers to that, it’s lesser evil to temporarily make ref resolution order more strict until we have time to fix up the layer APIs to not rely on it, and are able to relax it again (which would be a breaking change).
* Use array instead of object to avoid lookups
(cherry picked from commit 83cbc3e5fb)
* Add failing test demonstrating a ReactPerf warning
* Make the failing ReactPerf test more precise
* Make ReactPerf.start() work during reconciliation
* Reorder lifecycle methods for greater clarity
* Fix memory leak
* Error boundaries should not break ReactPerf
* Put onBeginFlush/onEndFlush into transaction wrappers
This looks cleaner even though it is not strictly necessary.
We still call them manually for unmounting because it doesn't have a transaction.
(cherry picked from commit 1a0e3a3215)
* Add failing tests for #7187 and #7190
* Pass shouldHaveDebugID flag to instantiateComponent
This allows us to remove a hack that was added in #6770 and caused #7187 and #7190.
* Move logic for choosing whether to use debugID outside instantiate
(cherry picked from commit d2ff462b79)
The src/core folder moved while this PR was pending so this file
didn't move with it.
Let's get rid of this annoying top level folder.
(cherry picked from commit 4f7a38c3b7)
Touch behavior is inconsistent across different platforms, and ResponderTouchHistoryStore currently fatals when assumptions are broken. In addition, the behavior differs between development and production.
This pull request does a few things to make ResponderTouchHistoryStore easier to deal with:
Adds Flow to keep the TouchEvent, Touch, and TouchRecord types straight.
Changes behavior to be consistent across environments. This means either always throwing or never throwing (and making use of warning and console.error as appropriate).
When an orphaned move or end event is received, print debug information and ignore it instead of crashing and burning.
(cherry picked from commit 2b226f5fa6)
Summary:
I had to cast into any because flow doesn't think that checking the lowercase version of nodeName is a valid way to refine the variable from HTMLElement to HTMLInputElement. I'm also not confident enough in changing the implementation to an instanceof HTMLInputElement to please flow. It also takes care of the null check in the process.
The `nodeName &&` condition wasn't useful since the two branches are checking it against concrete values and actually makes the type different since nodeName is not a boolean per se. I replaced them with if conditions to make it clearer what it actually did instead of doing boolean logic tricks.
It is unclear why I had to type supportedInputTypes, see this internal post for a discussion: https://www.facebook.com/groups/flowtype/permalink/1084168611631753/
The only difference in behavior is that I now explicitely convert to boolean the object dereference via `!!`.
Test Plan:
npm run flow
Careful inspection of the code
Reviewers: @zpao @spicyj
(cherry picked from commit 309215fc40)
* Inline dev-only requires
This reduces the production bundled build size.
* Use new references after resetting module registry in tests
This fixes the tests which were broken due to inlining some requires.
(cherry picked from commit 8fe6b5fb46)
This commit fixes#5473: ReactDOMServer.renderToString: presence of onClick
handler causes errors on async update
This commit performs the following changes:
- Adds a getUpdateQueue method to ReactServerRenderingTransaction,
ReactReconcileTransaction, ReactNativeReconcileTransaction and
ReactTestReconcileTransaction
- Make the ReactCompositeComponent call this getUpdateQueue instead of using
ReactUpdateQueue that was unwanted at certain moments on server
- On ReactServerRenderingTransaction, dispatch ReactUpdateQueue's methods
while rendering and warning methods afterwards. This is done through the new
ReactServerUpdateQueue class
- Added a series of tests that mimics the case presented in #5473 with setState,
forceUpdate and replaceState
- Add flow typechecking on concerned files
(cherry picked from commit dbdddf1c82)
- Removed the prop transitionAppearTimeout from
addons/transitions/ReactTransitionGroup in order to remove a warning
when passing unknown props to DOM elements.
(cherry picked from commit 6e5dd8926c)
This moves some files out of shared that are not actually shared
with isomorphic. They're specific to the renderers.
(cherry picked from commit 4bc1048e0d)
* addresses issue #7065
* fix test to use new message
* fix string in tests
* fix test string
* Update error message and tests
(cherry picked from commit f94912516f)
* create failing test case
* Fix renderSubtreeIntoContainer to update context
Fixes#6599
* Also test re-rendering due to prop update
* Address review feedback
(cherry picked from commit 25f9f4563e)
Summary:
The only callsite of ReactStateSetters is in LinkedStateMixin which lives in addons/link. Better move it there to avoid cluttering the other folder.
Test Plan:
None
Reviewers: @zpao @spicyj
(cherry picked from commit b0732ef881)
* Standardise format of the three "state" questions.
The original format follows the template:
> 1. x? if `x` then probably isn't state
> 2. y? if `!y` then probably isn't state
> 3. z? if `z` then it's not state
This caused both me and a hallway tester to do a double take.
The proposed reformulation allows the answers to follow the same template.
In the same spirit, it uses the same contraction pattern in the last answer (`it's not state`-> `it isn't state`). This has the welcome side effect to make the lack of "probably" stand out more.
* Update phrasing in thinking in reacr
(cherry picked from commit 5bca3773ab)
* Workaround IE lacking innerHTML on SVG elements
* Add tests for setInnerHTML
* Correctly check if node has innerHTML property
* Ensure tests for setInnerHTML actually tests both codepaths
* Provide mock element for setInnerHTML tests
* Only use SVG setInnerHTML workaround for SVG elements
(cherry picked from commit 99d8524d23)
* Stop passing null as second argument to document.createElement()
* rewrap check for props.is to make it more readable
(cherry picked from commit 263615573c)
Previously, this threw:
```
FAIL src/test/__tests__/ReactTestUtils-test.js (7.291s)
● ReactTestUtils › it can fail context when shallowly rendering
- TypeError: Cannot read property '_source' of null
at describeID (src/renderers/shared/devtools/ReactComponentTreeDevtool.js:70:46)
at Object.ReactComponentTreeDevtool.getStackAddendumByID (src/renderers/shared/devtools/ReactComponentTreeDevtool.js:203:15)
at checkReactTypeSpec (src/isomorphic/classic/types/checkReactTypeSpec.js:76:58)
at ReactCompositeComponentMixin._checkContextTypes (src/renderers/shared/stack/reconciler/ReactCompositeComponent.js:668:5)
at ReactCompositeComponentMixin._processContext (src/renderers/shared/stack/reconciler/ReactCompositeComponent.js:607:14)
at ReactCompositeComponentMixin.mountComponent (src/renderers/shared/stack/reconciler/ReactCompositeComponent.js:191:30)
at ReactShallowRenderer._render (src/test/ReactTestUtils.js:483:14)
at _batchedRender (src/test/ReactTestUtils.js:460:12)
at ReactDefaultBatchingStrategyTransaction.Mixin.perform (src/shared/utils/Transaction.js:140:20)
at Object.ReactDefaultBatchingStrategy.batchedUpdates (src/renderers/shared/stack/reconciler/ReactDefaultBatchingStrategy.js:65:19)
at Object.batchedUpdates (src/renderers/shared/stack/reconciler/ReactUpdates.js:112:20)
at ReactShallowRenderer.render (src/test/ReactTestUtils.js:453:16)
at Spec.eval (src/test/__tests__/ReactTestUtils-test.js:289:34)
at jasmine.Block.execute (node_modules/jest-jasmine1/vendor/jasmine-1.3.0.js:1067:17)
at jasmine.Queue.next_ (node_modules/jest-jasmine1/vendor/jasmine-1.3.0.js:2100:31)
at jasmine.Queue.start (node_modules/jest-jasmine1/vendor/jasmine-1.3.0.js:2053:8)
at Spec.jasmine.Spec.execute (node_modules/jest-jasmine1/vendor/jasmine-1.3.0.js:2380:14)
at jasmine.Queue.next_ (node_modules/jest-jasmine1/vendor/jasmine-1.3.0.js:2100:31)
at onComplete (node_modules/jest-jasmine1/vendor/jasmine-1.3.0.js:2096:18)
at Spec.jasmine.Spec.finish (node_modules/jest-jasmine1/vendor/jasmine-1.3.0.js:2354:5)
at eval [as onComplete] (node_modules/jest-jasmine1/vendor/jasmine-1.3.0.js:2381:10)
at jasmine.Queue.next_ (node_modules/jest-jasmine1/vendor/jasmine-1.3.0.js:2110:14)
at eval (node_modules/jest-jasmine1/vendor/jasmine-1.3.0.js:2090:18)
at Timeout.e [as _onTimeout] (node_modules/jsdom/lib/jsdom/browser/Window.js:440:19)
at tryOnTimeout (timers.js:224:11)
at Timer.listOnTimeout (timers.js:198:5)
```
(cherry picked from commit 510155e027)
* Don't count the time inside flushes towards lifecycle hooks
Fixes#6842.
We keep the existing behavior of testing for matching `onBeginLifeCycleTimer`/`onEndLifeCycleTimer` calls, but we push the current timer onto the stack if we enter a flush.
This solves an issue with portals which cause updates while a lifecycle timer is already running.
I chose to subtract the time spent in the flush from the time counted towards the lifecycle method because it would artificially inflate the “total” time of the component due to all the components inside the portal, so it would skew the exclusive table.
* Fix up the comment
(cherry picked from commit 8d7161e004)
* Fix componentWillUnmount() not counted by ReactPerf
* Test that functional component render() time shows up in ReactPerf
* Test for setState() code path updates being included
(cherry picked from commit 9ba5668d18)
Test Plan: Changed the preprocessor to log the output of babel.transform and saw
```
var _jsxFileName = 'src/isomorphic/modern/element/__tests__/ReactJSXElementValidator-test.js';
```
in the resulting output, instead of an absolute path.
(cherry picked from commit 6afd51061a)
One of the ReactMultiChildText tests renders 2145 roots (and even more components) and unmounts none of them. Now we don't loop through them all a bunch of times so the test takes 20 seconds instead of 60.
We should clean up instantiateReactComponent somehow so that the onSetDisplayName call isn't produced for the TopLevelWrapper, which should allow us to just store an array of unmountedIDs instead of a hash map so we at least don't have double maps. This change mirrors the old logic though.
Reviewers: @gaearon, @sebmarkbage
(cherry picked from commit 3cc733add4)
Being able to get the source for your parent components seems useful, and ReactComponentTreeDevtool is best poised to be able to do that.
I'm also not sure it makes sense to have separate DOM-specific `onMountDOMComponent` and `onUpdateDOMComponent` events, so I removed them for now. Even if we want them, their timing seemed sort of arbitrary.
I also made it so DOM devtools can listen to non-DOM events too. Willing to change that if people think it's ugly though.
(cherry picked from commit 03f4ba260b)
For clarity.
I left "native event" as-is because there's a lot of it, it's not particularly ambiguous, and SimulateNative/nativeTouchData are public API in ReactTestUtils.
(cherry picked from commit ba9b985406)
This is an outline for the new reconciler infrastructure.
I created a noop renderer to have something to get started from.
I split the reconciler folder into old and new, as well as shared.
I put shouldUpdateReactComponent in shared as an example of a
utility that can easily be shared between both. I plan on breaking
out more utilities like these.
(cherry picked from commit cf157886e9)
* New approach for 6062 fix : Show source line number on unknown property warning
* WIP: ReactDebugToolEventForwarderDevTool
* Update event signature to debugID
* Trigger events in ReactDOMComponent
* Renamed to onMountDOMComponent; passing in element directly
* Added debugID; updated simple test
* Added test for multi-div JSX to ref exact line
* Added test for composite component
(cherry picked from commit 7cf61db257)
This just configures flow to be checked and fixes our existing
Flow typed files.
Possible enhancements:
Export .js.flow declarations from the build. Unclear whether this
will be a supported workflow in the future or not, so let's wait
on that.
We should fail builds and CI on Flow errors.
Ideally we should lint for Flow style guides (like no space before
colon).
(cherry picked from commit 771d938fc0)
Most people don't use the official Flux implementation or docs so I think this is likely to be more confusing than helpful. Maybe later we can add a better comparison of data management solutions.
(cherry picked from commit 9498747606)
I *think* this should refer to the second example, where the instance to the ref is stored. In any case please can someone confirm for my own understanding?
(cherry picked from commit 712b1f75bf)
This makes it easier to figure out where the docs live.
Googling for e.g. `react-addons-update` also works, but this should
make things easier for people that hyperclick directly to the source.
(cherry picked from commit db175052c0)
* Create 01-why-react.zh-TW.md
Translation for language code [zh-TW](https://en.wikipedia.org/wiki/Zh-TW)
* Update 01-why-react.zh-TW.md
change "封裝性非常好" to "封裝性高"
(cherry picked from commit 44f84634d7)
This is no longer needed on the native side.
This is also the last use of the Platform flag. React Core is now
platform agnostic with regard to React Native. So I'll remove
the mocks and dependency.
(cherry picked from commit 0e4b046634)
This can happen if something gets unmounted before the event gets
dispatched. I'm not sure how this works out exactly but this
preserves previous behavior in this scenario.
(cherry picked from commit 69b6869a3e)
There are two examples of a text input with initial value of "Hello!" on this page, a controlled and an uncontrolled. The explanation for the uncontrolled version mistakenly says it works much like the earlier "uncontrolled" example, but the earlier example was the controlled version.
* fix conor
* one fewer jonathan
* nakazye
* Third9 & translucens
* zjjw
* rebase on master to pick up recent changes
* rebase
* shogunsea
* couple names for mailmap
* iawia002
* rebase
* terry3, speedskater
* rebase, handle duplicate mark
* more
This PR is the first in a series of pull requests split from the new `ReactPerf` implementation in #6046.
Here, we introduce a new module called `ReactDebugInstanceMap`. It will be used in `__DEV__` and, when the `__PROFILE__` gate is added, in the `__PROFILE__` builds. It will *not* be used in the production builds.
This module acts as a mapping between “debug IDs” (a new concept) and the internal instances. Not to be confused with the existing `ReactInstanceMap` that maps internal instances to public instances.
What are the “debug IDs” and why do we need them? Both the new `ReactPerf` and other consumers of the devtool API, such as React DevTools, need access to some data from the internal instances, such as the instance type display name, current props and children, and so on. Right now we let such tools access internal instances directly but this hurts our ability to refactor their implementations and burdens React DevTools with undesired implementation details such as having to support React ART in a special way.[1]
The purpose of adding `ReactDebugInstanceMap` is to only expose “debug IDs” instead of the internal instances to any devtools. In a future RP, whenever there is an event such as mounting, updating, or unmounting a component, we will emit an event in `ReactDebugTool` with the debug ID of the instance. We will also add an introspection API that lets the consumer pass an ID and get the information about the current children, props, state, display name, and so on, without exposing the internal instances.
`ReactDebugInstanceMap` has a concept of “registering” an instance. We plan to add the hooks that register an instance as soon as it is created, and unregister it during unmounting. It will only be possible to read information about the instance while it is still registered. If we add support for reparenting, we should be able to move the (un)registration code to different places in the component lifecycle without changing this code. The currently registered instances are held in the `registeredInstancesByIDs` dictionary.
There is also a reverse lookup dictionary called `allInstancesToIDs` which maps instances back to their IDs. It is implemented as a `WeakMap` so the keys are stable and we’re not holding onto the unregistered instances. If we’re not happy with `WeakMap`, one possible alternative would be to add a new field called `_debugID` to all the internal instances, but we don’t want to do this in production. Using `WeakMap` seems like a simpler solution here (and stable IDs are a nice bonus). This, however, means that the `__DEV__` (and the future `__PROFILE__`) builds will only work in browsers that support our usage of `WeakMap`.
[1]: 577ec9b8d9/backend/getData.js
We move any spies on `console.error()` from `beforeEach()` to the individual `it()` tests. This means that if a new test is introduced in these suites, it does not ignore warnings by default, but fails on any unexpected warning, which is Jest's default behavior.
We also change a few old instances of direct `console.error = jest.genMockFn()` assignment to use `spyOn()` for consistency with the rest of the tests.
Adding a note in the ES6 class documentation about function binding. Recommending that you bind your handlers in the constructor so that they are referentially the same function every time render is invoked (helps with child components that might potentially call shouldComponentUpdate)
- Update commonjs example to use Babel 6
- Update click counter example to match other examples
- Update jquery example
- Stop shipping webcomponents.js in starter kit
Adds a test to prevent a regression of throwing an error when
calling `findDOMNode(this)` in a component's `componentWillMount`
function. This previously used to throw an invariant violation but
now does not any more.
Algolia adds two inline styles
```css
position: relative;
vertical-align: top;
```
to the element once the script inserted at the end of the page runs which super slightly moves the header. The fix is to always apply those two rules this way it doesn't jump. I did not notice it on my machine because it doesn't move when custom fonts are not being used.
Test Plan:
- Open two tabs: reactjs.com and localhost:4000/react
- Click around on reactjs.com to prime the cache with the fonts
- Switch tabs and click around on localhost (but do not force refresh!)
- Now you get custom fonts loaded locally and it doesn't jump when you change tabs
IE11 reports `testElement` as detached DOM node consuming memory. It is captured in closure of `setInnerHTML` function and could be safely cleared after feature test.
We intend to change the measurement format significantly in #6046. In order to introduce the new ReactPerf during 15.x release cycle, we are making the measurement structure opaque-ish in 15.0.
`ReactMarkupChecksum.addChecksumToMarkup()` should not add checksum to
comment markup, which is generated from components returns null. This
fixes#6209.
This fixes a bug introduced in #5714.
The code paths are now similar to web components where we worked around the same issue in #5093.
Additionally, we also skip dangerouslySetInnerHTML and suppressContentEditableWarning.
I propose to add a sentence to indicate the page is ready, and the next step (Separate File) is optional. IMMO, the quick-start guide should be really short so that readers can see the result asap. Furthermore, the "Separate File" might not work for readers using Chrome anyway.
Replace the code sample in all the languages.
But I leave below sample code because of wording relation.
* tutorial6:see 25ef456
* from tutorial16:see 3812b95
It's important that we keep these code paths working because they're the only comprehensive test of adopting server-rendered HTML that we have right now. This is terrible and hacky but I am hopeful that it will at least catch stuff.
This adds `ReactInstrumentation` for the isomorphic package that uses the same approach as `ReactDOMInstrumentation`. Currently it is gated behind `__DEV__` but we will likely change this later to a runtime flag determined by whether there are any active listeners.
The first few events we add here should be sufficient for React DevTools, as determined by the `hook.emit()` calls in d90c432016/backend/attachRenderer.js.
These events will also be useful for reconstructing the parent tree in the ReactPerf rewrite in #6046.
This is a little simpler (and a teeny tiny bit faster). The one in ReactCompositeComponent stays because of the way we create ReactCompositeComponentWrapper inside instantiateReactComponent.
ReactDOMSelect's _handleChange function tries to set
this._wrapperState.pendingUpdate = true after executing the onChange
function. However, if the select was removed as a result of said
fuction, this._wrapperState would be null. Resulting in an
Uncaught TypeError: Cannot set property 'pendingUpdate' of null.
added controlled key to DEV
warn for checkbox inputs
warn for radio inputs
compute controlled instead of value
displaying owner name in warning
displaying input type in warnings
1. Add a handleHidden method to the BootstrapModal component.
2. Add an event listener for 'hidden.bs.modal' on the modal root
3. Add a new onHidden prop to the BootstrapModal component.
4. Add a new 'handleModalDidClose' method to the Example component to be used as the onHidden prop of it's modal component.
Context was missing info on how to update the context after the initial render. Added a simple blurb and an example.
[Docs] 12-context.md code review changes
The code example in `Motivation: Separation of Concerns` now fetches the `Engineering` facebook page instead of the user `pwh`.
With the current version of the graph api, it is impossible to fetch the user picture from an username. However it is still doable for public pages.
See the new test for the scenario I am trying to fix; if you clone an
element in React.cloneElement, vs just returning it directly, you will
get a different key (with a slash in front) even though the two
children are identical.
* Add a null check to "A Complete Example".
* Fix outdated comment. (Found by @mjomble)
* Replace short dash - with longer dash –.
* Remove backticks from state, because it is not code.
This was a temporary hook needed for the DOM implementation. We no longer need it because we now necessarily load every node into cache (via calling getNativeNode on it) before manipulating any of its siblings.
This makes things easier if we ever want to use more than one DOM node for a component. Notably, this is more convenient if we want to remove the wrappers around text components (since text nodes can be split and joined however a browser feels like) or if we want to support returning more than one element from render (#2127).
I left the old indexes so that implementations aren't forced to use the node/image if they prefer indices, because I'm not sure yet whether the changes corresponding to my rewrite of DOMChildrenOperations are easy or hard yet in React Native. (The tests pass with and without the DOMChildrenOperations changes here.)
All attributes defined on SVG elements will now be passed directly regardless of the whitelist. The casing specified by user will be preserved, and setAttribute() will be used.
In the future we will remove support for the camel case aliases to the hyphenated attributes. For example, we currently map `strokeWidth` to `stroke-width` but this is now deprecated behind a warning. When we remove support for this we can remove some of the code paths introduced in this commit.
The purpose of this change is to stop maintaining a separate SVG property config. The config still exists for two purposes:
* Allow a migration path for deprecated camelcased versions of hyphenated SVG attributes
* Track special namespaced attributes (they still require a whitelist)
However it is no longer a blocker for using new non-namespaced SVG attributes, and users don't have to ask us to add them to the whitelist.
Fixes#1657
In IE11 (and below), if you run
```
var input = document.createElement('input');
input.value = 'wat';
input.type = 'radio';
console.log(input.value);
```
you get the string "on" logged. Because that makes sense.
So we set the type first.
They don't provide any value and since one of them isn't a valid config usage,
it blurs the line. Instead just store these pieces in the tasks and write them
to the temp config.
I've seen some people unaware about the fact that you can still specify `.propTypes` and `.defaultProps` when you are defining a functional component by setting them as properties of the function.
I thought clarifying this in the docs could help!
I'm trying to use React with otto
(https://github.com/robertkrimen/otto), which is implemented in Go and
does not support lookaheads or backreferences in regular expressions.
(Unfortunately that *does* mean that otto isn't fully compatible with
the ECMA5 spec; but since this is the only lookahead I am aware of in
the React codebase, this change makes React once again compatible with
otto, and any other JS implementation that may not be fully compliant on
regular expressions).
As far as I can tell, the previous code replaced a sequence of slash
characters with one more slash than before. The new code avoids the
negative lookahead by matching any sequence of slash characters and then
using the special `$&` placeholder to replace the matched sequence with
the original sequence, plus one more slash.
It's mentioned as a note in "JSX in Depth" however I think for clarity and ease of look-up, it would be a good idea to also include it in the JSX Gotchas list?
When referring to mixin, the rest of the comment is in lowercase; see line 36 and line 37.
This change helps with the consistency of the usage of "mixin", and not to confuse it with a variable name.
According to react documentation it is advised to:
NEVER mutate this.state directly, as calling setState() afterwards may replace the mutation you made. Treat this.state as if it were immutable.
https://facebook.github.io/react/docs/animation.html
In this particular case it is probably doesn't matter since setState is called directly after mutation, but it does provide a bad example of state mutation.
Another way of removing an item from an array can be `newItems = this.state.slice(0,i).concat(this.state.slice(i+1))` however the meaning can be less obvious to some.
> Out of the box Babel doesn't do anything. In order to actually do
> anything to your code you need to enable plugins.
> (https://babeljs.io/docs/plugins/)
Running this is left as an exercise for the reader, since my measure.py isn't designed for this at present. But something like this might work:
```diff
diff --git a/scripts/bench/measure.py b/scripts/bench/measure.py
index 4cedf47..627ec97 100755
--- a/scripts/bench/measure.py
+++ b/scripts/bench/measure.py
@@ -79,15 +79,12 @@ def _measure_ssr_ms(engine, react_path, bench_name, bench_path, measure_warm):
if (typeof React !== 'object') throw new Error('React not laoded');
report('factory_ms', END - START);
- globalEval(readFile(ENV.bench_path));
- if (typeof Benchmark !== 'function') {
- throw new Error('benchmark not loaded');
- }
+ globalEval("bm = (function(){" + readFile("bench-createclass-madman.js") + "})");
+ bm();
var START = now();
- var html = React.renderToString(React.createElement(Benchmark));
- html.charCodeAt(0); // flatten ropes
+ bm();
var END = now();
- report('ssr_' + ENV.bench_name + '_cold_ms', END - START);
+ report('cc_' + ENV.bench_name + '_cold_ms', END - START);
var warmup = ENV.measure_warm ? 80 : 0;
var trials = ENV.measure_warm ? 40 : 0;
@@ -119,7 +116,7 @@ def _main():
return 1
react_path = sys.argv[1]
- trials = 30
+ trials = 60
sys.stderr.write("Measuring SSR for PE benchmark (%d trials)\n" % trials)
for i in range(trials):
for engine in [
@@ -132,7 +129,7 @@ def _main():
sys.stderr.flush()
sys.stderr.write("\n")
- trials = 3
+ trials = 0#3
sys.stderr.write("Measuring SSR for PE with warm JIT (%d slow trials)\n" % trials)
for i in range(trials):
for engine in [
```
Eslint didn't catch this (we do have this rule turned on) because it's a
big. There are no other locations I think. Detected that when I minified
some code.
According to the http://www.2ality.com/2015/11/tc39-process.html it is
not a good idea to guess target ES version until the proposal reaches
later phases.
Even the proposal repository now states
> It is a Stage 2 proposal for ECMAScript. <
(it has been changed in e9813ac78a)
We were shallow-rendering a component that used refs at FB so this can't go in as-is. It's a little unclear what we _should_ do though, since there is nothing to hold a ref to (since we're shallowly rendering) and we generally promise that child refs are resolved before a parent's componentDidMount. Also, changing shallow rendering to use the original `_renderValidatedComponent` (instead of `_renderValidatedComponentWithoutOwnerOrContext`) breaks tests because now the `_owner` field doesn't match up for `toEqual` (non-null in `getRenderOutput` but null if constructed in a test).
This test relied on the fact that ReactDOMComponent still produced hierarchical IDs -- although this module could be used standalone, we're replacing it completely so it makes more sense to just move the tests over to test ReactDOMTreeTraversal.
New module! With this, we have a new module that uses the component tree to store DOM nodes. Most of the logic in this file relates to markup adoption -- if we were to drop that (along with server rendering) this file could just be a `return inst._nativeNode;`.
This works with useCreateElement only because we need to reference each node as it's created.
Events is now the only thing using ReactMount.getNode -- I'll introduce pointers back from the DOM nodes (and a `ReactDOMComponentTree.getInstanceFromNode`) and make that work.
Update changelog for 0.14.1
(cherry picked from commit aaf8f870cb)
Update readme for 0.14.1
(cherry picked from commit c2dde8df0b)
0.14.1 blog post
(cherry picked from commit 6e2450e8f2)
Update website for 0.14.1
(cherry picked from commit f0782e2b2e)
Fix for lint issues
Added the test cases for the issue 5189
Removing empty space
Removing the Eventplugin instrumentation code
Removing unwanted white space
In 5c5d2ec182 I accidentally introduced a dependency cycle:
AutoFocusUtils -> findDOMNode -> ReactDOMComponent -> AutoFocusUtils
This breaks some tools internally. We're not actually using findDOMNode in AutoFocusUtils any more so we can just delete it.
This makes both Firefox and IE 15-20% faster in initial render (!!). On my PE benchmark, createElement is now on par with HTML in Firefox and faster in IE11 (before, it was slower).
According to current React version, when I use `React.render`, console shows `React.render is deprecated. Please use ReactDOM.render from require('react-dom') instead.`.
So this PR is a tiny update for the README example.
Is this all of them? I hope so.
- Set text content after creating hierarchy, like the text is a child. I should've done this originally but I guessed it wouldn't matter. I was wrong (~20% perf difference in IE11).
- IE throws when setting an enum-like property to an invalid value. I tried setting every property to the string 'a' and changed the ones that threw to be MUST_USE_ATTRIBUTE. I think these are all correct -- encType is the most suspicious one based on the existing comments but I tested in IE8 and it works fine as an attribute.
The automatic updating really sucks here as bugs are fixed / behavior of rules changes. Local versions are updated, cached versions on Travis aren't. It's messy. Now we must explicitly update for any thing to change.
Just seen on Stack Overflow a question that suggests people may be
confused if they run across some of the old syntax in one of our old
blog posts:
http://stackoverflow.com/questions/33261751/why-does-relay-ql-result-in-unterminated-string-constant-error/
Ideally people would consult the (up-to-date) documentation instead, and
we don't want to have to maintain old blog posts, but in this case the
cost of updating the syntax was low so I just went ahead and did it.
while supported then Input event is too noisy in IE. Firing on
placeholder sets, and when an input is focused with a placeholder.
fixes#3377 and fixes#3484
Fixed the lint issues
Added logic for handling the warning only once and added the test cases for the same. Also moved the warning part to only DEV mode
Changed few lines related to the formatting issues
Removing the empty whitespace
These are now just testing the same as the array cases directly above. This should make this test a bunch faster because it (intentionally) has n^2 runtime.
This matches our old behavior. I was a little too aggressive in turning on this
error and it's still possible to trigger it (using the test added here).
My last strategy of getting each node recursively while unmounting was a pain to make work properly with ReactMount's confusing cache. Now, we get the node before unmounting anything in the subtree (and we don't try to find the nodes of descendants).
This is a temporary solution and can go away when we get rid of the giant ReactMount node hash map.
Fixes#5151.
Each script will execute at most once so we could also set `.textContent` to something like `;`, then add it to the document, then change the `.textContent`, but this seems like the simplest approach. See http://dev.w3.org/html5/spec-preview/the-script-element.html for details.
Now we don't repurpose context for our own secret needs (hi Dan). In this diff I avoid storing the native parent on native (DOM) components and store it only on composites, but we'll probably want to store it on native components too soon for event bubbling.
[docs] Amend wrong words in zh-CN
08.1-more-about-refs.zh-CN.md
Update zh-CN docs
add thinking-in-react.zh-CN.md
[docs] Update two zh-CN docs
new file: ref-01-top-level-api.zh-CN.md
new file: ref-02-component-api.zh-CN.md
The Default Value section in the forms docs says "This example will function much like the Controlled Components example above."
The example actually functions like the Uncontrolled Components example, not the Controlled Components example.
It never really made sense for us to have "invalid" nodes in the cache -- when we unmount things, we should always remove them from the cache properly. Now that swapping composite types doesn't repopulate the cache, we should be okay to now assume that everything in the cache is good.
This is probably slightly slower for unmounts in the case that no updates were ever performed, but caching the node on the instance should make updates faster. In any case, the more important consequence of this change is that we can fix the current memory leak that happens when swapping composite types.
Before, if you had
```
container = <div data-reactid=".0"><div data-reactid=".0.0" /></div>;
```
and did `ReactDOM.render(<span />, container)` you would get
```
<div data-reactid=".0"><span data-reactid=".0" /></div>;
```
(along with a warning not to replace React-rendered children with a new tree like that). But that makes no sense -- the span should have a new index, not truncate the ID of the old child it's replacing.
(Now tests pass again with useCreateElement on; before they threw a "valid but unequal" on our test for this warning.)
Works at least on a CentOS 7 machine after running `sudo yum install
webkitgtk webkitgtk-devel`.
The only globals you get are `print` and `PerfCounters`. No `console` nor the other globals provided by the `jsc` command-line tool (load, readFile, etc) though they're probably not hard to implement.
You can disable the JIT by setting the environment variable `JSC_useJIT=false`.
Test Plan:
```
~/local/react/scripts/perf-counters$ make
~/local/react/scripts/perf-counters$ build/jsc-perf <(echo 'PerfCounters.init(); var a = PerfCounters.getCounters().instructions; print("moo"); var b = PerfCounters.getCounters().instructions; print(b - a);')
moo
72182
~/local/react/scripts/perf-counters$
```
You could make the argument that this should be optional, but it doesn't
work without it so we might as well just enforce it.
Makes `jest` work by default.
Seems better to fail gracefully, especially now that we support inlining. If people do this by accident we can figure out how to add a helpful warning instead.
Fixes#3285.
Split {{ in example code to avoid an Exception in jekyll.
> Liquid Exception: Variable '{{' was not properly terminated with regexp: /\}\}/ in docs/10.1-animation.md
When calling ReactTestUtils.Simulate, sometimes you want to test that an exception is thrown by the event handler. This lets you do that without relying on the fact that old jsdom doesn't implement `Event`.
Fixes#3473
I tag each React element with `$$typeof: Symbol.for('react.element')`. We need
this to be able to safely distinguish these from plain objects that might have
come from user provided JSON.
The idiomatic JavaScript way of tagging an object is for it to inherent some
prototype and then use `instanceof` to test for it.
However, this has limitations since it doesn't work with value types which
require `typeof` checks. They also don't work across realms. Which is why there
are alternative tag checks like `Array.isArray` or the `toStringTag`. Another
problem is that different instances of React that might have been created not knowing about eachother. npm tends to make this kind of problem occur a lot.
Additionally, it is our hope that ReactElement will one day be specified in
terms of a "Value Type" style record instead of a plain Object.
This Value Types proposal by @nikomatsakis is currently on hold but does satisfy all these requirements:
https://github.com/nikomatsakis/typed-objects-explainer/blob/master/valuetypes.md#the-typeof-operator
Additionally, there is already a system for coordinating tags across module
systems and even realms in ES6. Namely using `Symbol.for`.
Currently these objects are not able to transfer between Workers but there is
nothing preventing that from being possible in the future. You could imagine
even `Symbol.for` working across Worker boundaries. You could also build a
system that coordinates Symbols and Value Types from server to client or through
serialized forms. That's beyond the scope of React itself, and if it was built
it seems like it would belong with the `Symbol` system. A system could override
the `Symbol.for('react.element')` to return a plain yet
cryptographically random or unique number. That would allow ReactElements to
pass through JSON without risking the XSS issue.
The fallback solution is a plain well-known number. This makes it unsafe with
regard to the XSS issue described in #3473. We could have used a much more
convoluted solution to protect against JSON specifically but that would require
some kind of significant coordination, or change the check to do a
`typeof element.$$typeof === 'function'` check which would not make it unique to
React. It seems cleaner to just use a fixed number since the protection is just
a secondary layer anyway. I'm not sure if this is the right tradeoff.
In short, if you want the XSS protection, use a proper Symbol polyfill.
Finally, the reason for calling it `$$typeof` is to avoid confusion with `.type`
and the use case is to add a tag that the `typeof` operator would refer to.
I would use `@@typeof` but that seems to deopt in JSC. I also don't use
`__typeof` because this is more than a framework private. It should really be
part of the polyfilling layer.
Should fix#1939.
Test Plan:
With two copies of React, render a div using React1 and use that as a container to render a div with React2. Add onMouseEnter/onMouseLeave to both divs that log. Mouse around and see correct logs (as if each React was isolated), no errors.
Previously, we fetched the node once for every changed attribute. In my createElement diff, I changed it to fetch the node (once) regardless of if there were changes -- fetching it once only if there are changes is even better.
React components can be assigned a special property named `key`. Therefore, it's helpful to avoid the phrase "key property" unless you're talking about the `key` property :)
I'm not sold on the replacement phrase, though... I think it's solid, but two fancy words like "fundamental" and "invariant" next to each other just seem a bit unwelcoming xP then again, we're talking about some heavy technical stuff; if there aren't any lighter words that are equally precise, then these should probably stand.
Changed: createFragment no longer includes nulls in its output (since toArray doesn't and they share code).
Changed: React.Children.map no longer warns for clashing keys; traverseAllChildren will later when rendering.
Also change the generated key format around to accomodate. My keys are probably not bulletproof but should definitely be safe against accidental collisions.
"This ensures that" sounds a better than "That ensures that." This change is just my personal opinion, so I totally understand my change doesn't get merged.
As discussed in issue 1326
(https://github.com/facebook/react/issues/1326) transitionend events are
unreliable; they may not fire because the element is no longer painted,
the browser tab is no longer focused or for a range of other reasons.
This is particularly harmful during leave transitions since the leaving
element will be permanently stuck in the DOM (and possibly visible).
The ReactCSSTransitionGroup now requires timeouts to be passed in
explicitly for each type of animation. Omitting the timeout duration
for a transition now triggers a PropTypes warning with a link to the
updated documentation.
Turns out jest is _incredibly_ slow at resolving require paths like `require('fbjs/lib/foo')`. Like several milliseconds per require. Really adds up when all our files require `invariant` and `warning`. Here's a temporary hack to make things fast again.
Test Plan:
```
npm test src/renderers/shared/reconciler/__tests__/ReactCompositeComponent-test.js
```
has a self-proclaimed runtime of ~8 seconds now instead of ~35 seconds.
Behind a feature flag. This is a relatively simple change; adopting this strategy universally would mean that we could clean up a lot of code but this doesn't attempt to restructure more than necessary.
As of this commit, we still support objects as maps so if anyone has an object with keys 'type' and 'props' this will change behavior, but otherwise this should be pretty safe.
This simplifies event dispatching by removing the `return false` special
case for the SimpleEventPlugin which allow us to inline much more here
and the code becomes easier to follow.
This wraps a proper guard around event dispatching so that errors doesn't
interupt other event callbacks.
Instead we rethrow the first error after all callbacks have been invoked.
For DEV mode we use native event dispatching if available. This has the
benefit that caught exceptions show up in the dev tools even without caught
exceptions being turned on. Yet, all callbacks are guaranteed to fire.
Stateless pure-function components give us more opportunity to make performance optimizations. For now, we'll do a minimal implementation which has similar performance characteristics to other components in the interests of shipping 0.14 and allowing people to begin writing code using this pattern; in the future we can refactor to allocate less and avoid other unnecessary work.
```reactComponentExpect``` fails silently when passed an undefined value. It calls ```ReactTestUtils.isCompositeComponent``` with the undefined value, in which a ```render``` property is accessed, throwing a prop on undefined not found error which isn't surfaced to jest.
```
TypeError: Cannot read property 'render' of undefined
at Object.ReactTestUtils.isCompositeComponent (./react/test/ReactTestUtils.js:127:23)
at new reactComponentExpect (./react/test/reactComponentExpect.js:46:20)
at reactComponentExpect (./react/test/reactComponentExpect.js:40:12)
```
Expecting the passed-in instance to not be undefined surfaces this issue in the test runner.
Or the alternative:
`REST is an acronym for Representational State Transfer, which is an architectural style rather than a formal protocol`.
Sorry , I'am not a native speaker:)
ReactTools is deprecated, it doesn't belong at the root of the project. We'll remove it after 0.14 but for now this moves it so that it's contained and not intermixed with the rest of the project. The currect behavior of copying src/ into the package is maintained.
This ensures that we can consume code from npm that has our process.env pattern. Unfortunately we'll run the same transform on minified builds but it's pretty quick.
This reworks a few things in building and distributing React. The biggest change is using fbjs to share dependencies with other libraries. We're also using Gulp for some build steps.
With this, ReactMultiChild handles all of the children-related operations for ReactDOMComponent so that we don't process operations out of order. This is necessary because ReactMultiChild does its own batching so there's no way without its cooperation to get the timing right here.
Ideally we'll factor this logic out a bit better in subsequent updates but this is the simplest way to fix#1232 which has embarrassingly been open for over a year.
I'm proposing these changes because I found some repetition / lack of
clarity and some language that suggested that you could mutate
`this.state` directly.
Rely on jest for now until we get a better and less hacky solution to running tests in the browser, probably a totally different test suite with different behavior/goals.
I came across an issue on a React project where I needed to programatically set the default value of an input as the result of an async call. (I was prepopulating a zip code field from the Google Maps Geocoding API). It didn't work when I passed in an updated defaultValue prop, until I came across this StackOverflow: http://stackoverflow.com/questions/30146105/react-input-defaultvalue-doesnt-update-with-state. I was able to get it to do what I wanted by passing in the value prop instead.
The addons module warning is currently causing issues with babel/JSPM due to the warning message getting parsed as a require statement. Adding a break using string concatenation appears to prevent any issues.
Example error using JSPM:
```
Error loading "react-addons-{addon}" from...
```
- Add missing object-assign dependency
- Add batchedUpdates to ReactDOMClient, rename the two addons to `unstable_`
- Delete react/addons/* (leaving react/addons with a slightly updated warning)
- Add README.md, LICENSE, PATENTS to each addons package
Changes:
- moves after_script to script
- adds `set -e`
- creates a seperate matrix 'build'
Way at the bottom of the travis output:
```
1571: curl: (26) couldn't open file "build/react.tgz"
```
This seems to be broken since 12c9fee94e
No reason to limit at 100. I can't imagine a reasonable tree with depth over 10,000 but that should still be small enough to "catch infinite loops" quickly.
This hack allow us to get rid of the stateful module ReactLifeCycle since
we can infer the value of isMounted even without it. This gets rid of
the try/catch which is deopting all mountComponent calls.
As a next step we could deprecate isMounted completely and avoid stateful
APIs. Since it can be easily simulated if you truly need it.
Since I fixed the server-side rendering it is now possible to trigger these
callbacks on the client alone. They will still be queued up on the server
but they are never executed.
This allows updates to be enqueued during render. setState in
componentWillMount will still be collected as part of the first pass so
if nothing else get added as pending, they won't trigger a second rerender.
This allow us to get rid of one more stateful special case.
This simply ignores any enqueued actions. This means that we don't have to have special logic for componentWillMount. It is just that those updates are never enqueued.
This was used for any invariant that was subsequently removed. It turns
out that this is completely unnecessary now. Any setState calls will
enqueue and update and the component added to the update queue. However,
since the pending fields are reset after componentWillUnmount, any update
will still be ignored.
It was impossible to get here because if you enqueue something
Also ensure that they're only used in DEV because we will be reading
state that is DEV only here.
This should only be used for tracking string refs. For that purpose, we
need a single central stateful module that is coupled to createElement.
Which is why it needs to live in isomorphic.
Eventually this will go away completely.
This decouples the stateful imperative API from the class creation.
Instead, they get injected into the class from the renderer. Stateful
modules should always be injected.
As a convenience, just like props/context/refs, we set it up after
construction using mutation. That way it is optional to pass it along
the super call constructor chain.
We won't be able to support this after DOM-components-as-refs but we don't expect many people to be passing DOM components to this function anyway, and it should be fairly straightforward for people to clean up failing unit tests using this function.
(This module also isn't public API and never has been.)
We won't be able to support this after DOM-components-as-refs but we don't expect many people to be passing DOM components to this function anyway, and it should be fairly straightforward for people to clean up failing unit tests using this function.
Squashed commit:
[4564e55] Ensures we don't need to update this page for every release.
[b0d60f9] update script sources to be even with the example file in reactjs/react-tutorial repo
This is kind of a confusing place for it but it is intimitely tied to the
update life cycle which is what the update queue is about.
This kills some dependencies from isomorphic to the renderer.
We keep track of the fact that something is rendering for a bunch of
warnings. (ReactCurrentOwner.current !== null)
Once we get rid of owner for string refs, I'll convert those to something
like "isRendering" instead. The interesting part is that feature `__DEV__`
only. It is only used for warnings. Except for this case.
This means that we can get rid of the special case for the isRendering
stack on in prod.
- babel-eslint ^3.1.14 fixesbabel/babel-eslint#120
- babel updated from ^5.3.3 to ^3.5.5, which changes stuff, I guess
- eslint updated from ^0.21.2 to ^0.22.1, which makes `no-shadow` also
check class declarations
In xml node name casing is exactly the same as the node was originally named.
Make sure to convert node and tag names to lower case before making any node
and tag name checks.
Fixes#3960.
spicyj noticed newer versions of babel-eslint seemed not to error on
no-unused-vars, and I was able to repro. It seems like something broke
between 3.1.9 and 3.1.10. (Smaller repro case and babel-eslint bug
report to come)
His commit failed on travis, but not on his local machine:
https://travis-ci.org/facebook/react/jobs/65468729
> The two callers of this function have different warning configs
> internally (static_upstream/core/createWarning.js) so we can't sync it
> like this without changing behavior. We should just split this out
> into two separate warning calls probably – this code is a little
> overabstracted.
https://github.com/facebook/react/pull/4021#discussion_r31690020
@spicyj
I think completely removing warnAndMonitorForKeyUse is a bit difficult, without
duplicating a ton of code. This at least ensures that the format string passed
to `warning` is unique. Plus, because the FB internal code in question only
matches the beginning of the format string, I think there should be zero
internal changes that need to be made to support this refactor.
The `warning` implementation checked that the message is long enough to
be useful. See commit f5038829d for more information.
It makes more sense to move this into a lint rule, and also to apply it
for both `warning` and `invariant`. We can safely remove stuff from the
`warning` implementation as we replace the function internally anyways.
https://github.com/facebook/react/pull/4021#issuecomment-108694976
@spicyj
The wording for an incorrect number of arguments based on counting %s
substitutions. The previous wording was backwards and a bit yoda-like
leading to possible ambiguity.
This should contain all the rules we probably want to use, except
react/wrap-multilines, which requires a larger codemod, and would
clutter this commit.
See #2869
Checks that the *second* argument of warning and invariant are a literal
string, or a concatination of literal strings, and that the number of
arguments is correct based on the number of %s substrings.
This commit also fixes a few places where the existing code had broken
error messages!
The rule itself is pretty straightforward, although adding the tests
ended up being a bit painful, as eslint-tester depends on mocha, and
therefore needs to be run in a separate grunt task.
This is a machine-generated codemod, but it's pretty safe since it was
generated by hooking into eslint's own report.
A few files had to be touched up by hand because there were existing
formatting issues with nested arrays/objects:
src/shared/utils/__tests__/OrderedMap-test.js
src/shared/utils/__tests__/Transaction-test.js
src/shared/utils/__tests__/traverseAllChildren-test.js
src/isomorphic/children/__tests__/ReactChildren-test.js
Introducing: a really lame version of composite components, right inside of ReactDOMComponent!
Now ReactDOMInput isn't an actual component. This brings us closer to exposing DOM nodes as refs.
Closes#3971.
> After #3968, the next thing we should do is start linting our tests.
> Historically we've ignored them due to lack of parser compatibility.
> But that shouldn't be a problem anymore. We may want to integrate
> https://www.npmjs.com/package/eslint-plugin-react to more aggressively
> lint our JSX in tests.
I understand this diff touches a lot of stuff, so I tried to keep it to
a near-minimal set of changes to make eslint happy.
- Removes esprima-fb dependency
- Tightens up eslintrc with some minor rules we were pretty-much
following anyways.
- Adds pretty colors to the `grunt lint` output
- Breaks block-scoped-var :(
Follow-up to #3963. (Returning an Error wasn't useful; it just caused a later error when actually using it because type checkers need to be functions.)
Chrome allowed some of these to be 'null' (allow `node.challenge` etc),
but FF didn't work. This will tell React to use node.setAttribute() to
set these values.
Tested in FF, Chrome, Safari. <keygen> isn't supported on IE.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/keygen
The code sample in tip 18 in the docs contained a call to the
.getDOMNode() method which has been deprecated. The method call was
replaced with a call to React.findDOMNode(), which is the preferred way
of getting DOM nodes from a ref.
This heuristic isn't great because it relies on inspecting deep children which aren't guaranteed to be React elements. In particular, this was causing stack overflows in a component we had that used a *DOM node* as children, like `<DOMContainer>{node}</DOMContainer>`.
This reverts commits:
0a3aa8493a64c9d9d7620c58f4f6b18cf226e442086636747f
The new folder structure is organized around major packages that are expected to ship separately in some form.
`/isomorphic`
I moved classic/modern and children utils into a directory called "isomorphic" with the main export being ReactIsomorphic. This will eventually become the "react" package.
This includes all the dependencies that you might need to create a component without dependencies on the renderer/reconciler.
The rest moves into decoupled renderers.
`/renderers/dom/client` - This is the main renderer for DOM.
`/renderers/dom/server` - This is the server-side renderer for HTML strings.
`/addons` and `/test` - Same as before for now.
You're not supposed to take on a dependency inside another package.
Shared code is organized into a "shared" directory which is intended to support all the packages in that subdirectory. Meaning that once we swap to CommonJS modules, the only time you should use `..` is to target `../shared/` or `../../shared`.
E.g. `/shared/` is common utils that are used by everything.
`/renderers/shared/` is code that is shared by all renderers, such as the main reconciliation algorithm.
Shared code will likely be copied into each package rather than referenced. This allow us to have separate state and allow inlining and deadcode elimination.
Size comparison:
```
raw gz Compared to master @ 6ed98ec0c8
= = build/JSXTransformer.js
-15736 -3247 build/react-with-addons.js
+287 +7 build/react-with-addons.min.js
-14412 -2887 build/react.js
+274 +15 build/react.min.js
```
Differences mostly look to be various bits of whitespace that Babel ends up removing during its transforms (https://gist.github.com/spicyj/21ef31f4d95fb7a58daf). In minified files, mostly additions of `"use strict";`.
My old code here didn't work properly -- for a string child, getIteratorFn would return an iterator that gave each character as its own string, and we'd attempt to loop over that too.
Tests now work in Chrome again.
Also when reusing elements in multiple contexts -- before we were mutating each element to indicate its validity; now we mutate the array containing it (which we create, in the case of rest-arg children).
Fixes#2496. Fixes#3348.
Updated documentation to reflect that using React.cloneElement is the new way to copy an element and preserve `key` and `ref`.
Fixes#3432, closes#3447.
Update links to use https:// where it is supported. There's probably a lot
more that could be fixed, but these are the core ones I found (especially
the download links in order to prevent MITM attacks). Note that there are
some fb.me links that will redirect to http:// even while accessed over
https://, but this seemed like the best way to fix those for now.
NOTE: Only non-third-party files were modified. There are references to
http:// URLs in vendored/third-party files, but seems appropriate to fix
upstream for those rather than editing the files.
Also, copy one image locally to the blog, as it was hotlinking to a site
that did not support https://.
Last, use youtube-nocookie.com instead of youtube.com for video embeds,
as the former doesn't try to set a cookie on load (privacy enhancement).
I'm not super attached to this, but this feels cleaner to me. Might even be faster since flattenChildren doesn't use the index. Probably no change though.
If there are no listeners for `onSelect` yet, do not extract events. This way we can avoid issues where listeners have been set up for some event dependencies for `SelectEventPlugin`, but not all.
For instance, if `topMouseDown` has been registered but not `topMouseUp`, event extraction will set the `mouseDown` flag to true but never unset it. This leads to bugs when `onSelect` is registered and should be firing during normal key behavior. Since no `topMouseUp` has yet occurred to unset the flag, `onSelect` fails to fire.
When the style property existed, but was set to null, `this._previousStyleCopy`
was not set back to `null` causing an old value to persist. This broke setting
the style to `null` the next time.
Fixes#3606.
As far as I can tell, this is almost equivalent and is simpler. When a component's componentDidMount is called, all the listeners for that subtree will have been attached which I think is all that matters.
All testes successfully completed.
- for-in in browsers is slow, i replaced him by Object.keys + for(array)
- simple check of lengths let us not iterate if not same
- now we dont need to test for B's keys missing from A, because if length's is same and prev check success - objB hasn't more keys
- micro optimize: calling objB.hasOwnProperty
- micro optimize: replaced !objA || !obj for more speedy check === null
#inspiredby https://github.com/jurassix/react-immutable-render-mixin/pull/4
$REACT_WEBSITE_BRANCH in https://travis-ci.org/facebook/react/settings/env_vars now needs to point to the stable branch (currently 0.13-stable). I haven't tested the commit-and-push part of this but everything else works so I'm hopeful.
I ended up needing to add this attribute to work around a common IE bug, that clicking on a scrollbar gives focus to the scroll container. I needed to set it as MUST_USE_ATTRIBUTE or the attribute would not be passed through by React successfully.
remove trailing spaces
The current documentation states that the `<select>` tag supports `defaultChecked`, but it actually doesn't. I believe this documentation was meant to be written in the proposed order.
Non-working fiddle using `defaultChecked`: http://jsfiddle.net/jqs1hsLr/1/
Working fiddle using `defaultValue`: http://jsfiddle.net/nv7z0yzL/1/
Turns out lots of people write invalid HTML all the time and no one, including your browser or React, cares. Most invalid HTML combinations don't cause magic reparented nodes; only some do. The HTML5 parsing spec (https://html.spec.whatwg.org/multipage/syntax.html) specifies which tag combinations cause strange parsing behavior. I did my best to encode the logic here. It's more lenient than before in some cases, but more strict in others (before we didn't look at the whole stack of tags; now we warn with deeply nested `p` or `form` or `a` tags).
Rendering to `document.body` in the examples is conveniently short, but it can
be misleading at the same time, especially for newcomers.
While it's possible to render React components to `document.body`, any 3rd
party scripts can also mess up with it, and it can have unintended consequences
and be source of difficult-to-trace bugs.
Now that #1169 is fixed, the only thing this is used for is to determine whether `onTouchTap` causes touch listeners to be added. The only internal uses of TapEventPlugin are where touch events are already initialized (so this doesn't make a difference) and we don't support `onTouchTap` as part of the public API so this should be safe.
This reverts an early commit that made it so that elements from two
different owner in the same slot wouldn't share state.
That behavior was helpful, and we did hit a case which was solved by this.
However, this pattern is extremely uncommon. I've yet to even find the
original case, let alone any existing cases in our codebase.
Therefore, we're dropping this to simplify elements and enable new
optimizations.
We currently override a couple DOM components. We need to ensure everything we
override is still treated as a DOM component, even if it has a composite
component wrapper.
_mountImageIntoNode moved into ReactMount and wasn't being counted where it was supposed to be. In addition, all DOM elements are now wrapped in a composite wrapper but for the perf tools we want to skip over those or else we'll double-count (at least with the current accounting -- and that's effectively what we did before so this brings us back up to parity).
Fixes#3407.
Test Plan:
Used the jsbin from #3407 and saw similar output from this branch and 0.12:

$TRAVIS_COMMIT_RANGE was broken but it seems what we're doing is worse and
resulting in false negatives.
The result of the bad range was that we weren't running lint or tests for
things we should have been. It actually looks like $TRAVIS_COMMIT has been
wrong and it's not clear why this has been working at all.
ReactDOMComponent maintains a copy of the previous style
object to support in-place mutations of props.style.
This cached object was not cleared when the style
property was removed in a props update.
Fixes#3409
There is an exception when value or defaultValue is set but there are no
children as ReactDOMSelect tries to mark the first children as selected
even if there are no children.
I mis-parsed 'shallow copies' as adjective noun, instead of as a compound verb. I've adjusted the text to make it easier to parse on the first read, which should also help ESL learners to be able to parse it easier.
Summary:
Right now, if a component specifies a propType as, for example,
`myProp: React.PropTypes.shape`, without an actual shape
parameter, any prop type will be accepted, because
`React.PropTypes.shape` returns a function (the actual validator),
not an Error, currently indicating that propType checking passed.
This can create an unfortunate situation where a component looks
like it has fully specified `propTypes`, but in fact does not.
This commit addresses this by warning if a propType checker returns
anything non-falsy that is not an Error (currently all the library
PropTypes return null or an Error).
Test Plan:
Added a unit test; ran `jest` in the root repo directory.
Also ran `grunt lint` and `grunt test`
If either argument is not an object and unequal, then shallowEqual should return false.
If only one argument is an object, then shallowEqual should return false.
Fixes#3369
This is in response to #3207 to address concerns regarding third-party
scripts and browser plugins potentially altering DOM nodes within
document.body, causing problems with reconciliation.
Closes#3211.
The only substantial difference here is that I made the harmony example use ES6
classes. The server rendering example was pretty wacky and hard to run but
I did confirm that it works.
Console is undefined in earlier versions of IE when it is not open. This causes an uncaught exception, and breaks applications in these versions of IE when attempting to warn when the console is closed.
Admittedly, console will usually be open when testing in development, but still React should not break the application when it is not.
We added this test internally and it never got added here. We haven't broken it
with any transforms *yet* but it's still good to actually run all of our tests
here too.
These are the only places that seems to be including environment specific
variables in the message format.
By ensuring that they're static, we make it easier to group logs by
format. I also ensure that I keep each addendum separate so that they can
be filtered/grouped separately.
This is a new version of cloneWithProps but this one is moving out of
add-ons. Unlike cloneWithProps, this one doesn't have special logic for
style, className and children.
This one also preserves the original ref. This is critical when upgrading
from a mutative pattern where a child might have a ref on it.
It also preserves context, which is similar to how context would work when
it is parent based. It also ensures that we're compatible with the old
mutative pattern which makes updates easier.
Note: we need to manually specify date in these files so that the sort order is
correct (2 posts on the same day). Otherwise it will just be ABC order, which
is wrong.
Closes: #3256
Without this, transitioning from `<div onClick={null} />` to `<div />` triggered `willDeleteListener` to delete the `click` handler which caused problems; now, we only call `putListener` and `deleteListener` when we have an actual listener.
I now also clean up the `onClickListeners` map upon deletion and don't double-listen when updating the event listener.
* 'master' of https://github.com/facebook/react: (30 commits)
Expose --target flag on jsx executable
Contributing: cleanup quote style
Add Relay blog post
Fix long lines in vendor/fbtransform/visitors
lint vendor/*.js
fix .eslintignore
remove ballmer example
Fix a doc. cloneWithProps clones a ReactElement.
lint from root
Fixed mistake in jsdocs types for cloneWithProps
Put deprecation warning for classSet
Lint vendor/fbtransform as well
More warnings to ReactFragment.create
Warn when using constructor function directly
Move option parsing into react-tools proper.
Remove lodash devDependency
Added the immutability talk to the React.js Conf update.
Use same pathways for browser transforms as we use in react-tools
lint: remove spaces from array brackets
lint: remove spaces from object braces
...
Valid values are 'es3' and 'es5'.
es3: perform reserved words quoting, don't use defineProperty
es5: default, don't do the above, class methods non-enumerable
Apparently I could've used these too because if you accept an arbitrary
node, then these could end up being objects, but those objects might
also be arrays or elements.
We no longer support the legacy factory style of calling component constructors
directly. We only support createElement or the wrapping of classes with
createFactory. Instead of letting this fail in a gross way as we try to run,
add a nice warning that shows up before the gross TypeError.
We were doing some preprocessing for module options in the command line. Since
we also expose the same API via react-tools (and JSXTransformer), we need to do
the same processing from the API. So just move it all to the same place.
This makes sure we can use the same options everywhere, even from react-rails,
without having to specify each one separately in JSXTransformer as well.
When animating the max-height property in Safari, entering the leave state would trigger an animation to `max-height: 0`. Then when the active state kicked in, it would jump and didn't really look right. Moving the `transition` css property to the active version fixed the issue for me and worked on Safari, Chrome and Firefox. Unfortunately I'm not in a position to test in IE at the moment, but I'll do that at my first convenience tomorrow.
This is an anti-pattern that can be easily avoided by putting the logic
in componentDidMount and componentDidUpdate instead.
It creates a dependency on stale data inside render without enforcing
a two-pass render.
We're not sure if this is the way we want to support this API. It creates
two ways of doing things.
It is convenient to avoid needing to explicitly redefine the key of Maps.
However, this use case isn't as common as having an iterable where the
key is on the value, not the key.
This was an important convenience as an upgrade path but shouldn't be
necessary if you're using best-practice of calling createFactory in the
consuming component.
Summary:
This section was confusing. I reworded it from:
"JSX is completely optional. You don't have to use JSX with React.
You can create these trees through `React.createElement`. The first
argument is the tag, pass a properties object as the second
argument and children to the third argument."
to:
"JSX is completely optional; you don't have to use JSX with React.
You can create React elements in plain JavaScript using
`React.createElement`, which takes a tag name or component, a
properties object, and variable number of optional child
arguments."
and additionally added another child element to the example code.
Test Plan:
Read the new paragraph!
Fixes#1297.
onMouseEnter and onMouseLeave shouldn't *actually* use direct dispatch, but doing so is more useful than doing nothing (and I don't think it precludes adding proper enter/leave dispatching later, either).
Test Plan:
grunt test
Previously, `checkAndWarnForMutatedProps` would flag `NaN` props as
having been mutated, because `NaN !== NaN`. This prevents that warning
from being emitted by explicitly checking for `NaN`s.
This ensures that we have a prefix that can be easily identified in logs
so that we can filter out warnings based on their prefix.
This also turns the remaining two monitorCodeUse callers into warnings.
We'll probably still use monitorCodeUse until we know if we want to
deprecate but most releases should only have warnings.
Updated the mention of "facebook.com" on line 3 of the CONTRIBUTING.md file to link to Facebook. Previously, this mention was just in plain text.
Changed from `facebook.com` to `[facebook.com](https://facebook.com)`
No other content has been changed. Content has not been removed from this file in any way.
I made this mistake while upgrading a few callers.
I'm leaving this as warning so that it is always safe to wrap any existing
child in React.addons.createFragment without breaking prod.
This makes upgrading easier.
Currently we use an invariant to prevent this code pattern. That is really
aggressive for something that doesn't actually put React in a bad state. This
diff replaces invariants with warnings and makes those code paths no-ops.
Eslint now allows us to use a different parser, which allows us to use
esprima-fb explicitly. This means we don't have to wait for espree to add
things like rest-param parsing. Though we do need eslint to upgrade its rules
to handle that AST.
I had hoped to enable parsing of our tests but we can't do that until we
change esprima-fb's XJS nodes to JSX.
While I was here, I also enabled the no-unused-vars rule since eslint
understands template strings. I also made the single quote enforcement
actually fail instead of just warn.
This triggers a warning if you try to pass a keyed object as a child.
You now have to wrap it in React.addons.createFragment(object) which
creates a proxy (in dev) which warns if it is accessed. The purpose of
this is to make these into opaque objects so that nobody relies on its
data structure.
After that we can turn it into a different data structure such as a
ReactFragment node or an iterable of flattened ReactElements.
We've actually diverged more with some modules, but we don't want
a cascade of dependencies out here. Mostly, the changes internally that
we don't want are tied to FB infrastructure but otherwise are
functionally equivalent (usually around error reporting, code monitoring).
This diff enables setState to accept a function in addition to a state partial. If you provide a function, it will be called with the up-to-date `state, props, context` as arguments.
This enables some nicer syntax for complex setState patterns:
If setState is doing an increment and wants to guarantee atomicy, you need a function:
```
this.setState(state => ({ number: state.number + 1 }));
```
This atomicy is particularly important if setState is called multiple times in a single frame of execution as the result of complex user actions. It's a tricky bug to chase down and difficult to determine how to fix when you find it. The current pattern of reaching into _pendingState relies on an implementation detail.
In this example: props.doAction() may result in your ancestor re-rendering and providing you with new props. If setState is called directly with an object literal referencing `this.props`, it will use the *old* version of props, not the new value. Using a function solves for this case:
```
this.props.doAction();
this.setState((state, props) => ({ number: state.number * props.multiplier }));
```
enqueueCallbackInternal forgot to schedule an update.
We could rely on the implicit contract of enqueueElement to do it. However,
if we're currently outside a transaction, it'll flush synchronously. Before
we enqueue the callback. We could also enqueueCallback before we
enqueueElement, but that causes a fragile relationship between them. E.g.
enqueueElement should not need to schedule an update if it is the same
element.
In 1.4.0 we can use the TypeScript API directly to preprocess our files.
This lets us get rid of a dependency.
https://github.com/Microsoft/TypeScript/wiki/Using-the-Compiler-API
We can also use this to provide our default libraries so that we don't
need to keep the references in the test file.
This is to make sure we don't end up with differences in our different
testing methods. We may switch out the failure allowances later (maybe
just jest will be good enough and we can let phantom fail for a little
bit).
It's possible to configure Jest to not dump the module cache between
specs. This makes it tricky when we silence warnings one a 2nd call.
In this case, the same message was getting logged so when we expected
the count of warning calls to increment, it didn't.
This makes it more difficult to find bugs in mixins both dynamically
and using a static type system.
We also don't have a way to find these to be upgraded to a new mixin
syntax if we needed to.
This hook is currently an optional noop but could be made required to
create a mixin class.
We freed up this internal name by removing the internal base class.
We're now free to use this name as it was intended.
ReactDOMComponent and ReactCompositeComponent are still confusing as
they're internal but we'll rename them later.
All entry points are for reconciliation are within batching strategies.
Since we don't have any batching strategies with synchronous updates,
there can't be more than one life-cycle method on the stack at any given
time.
Therefore, it's safe to move the composite life cycle flag to a singleton.
This saves us some memory management.
I think that we can get rid of these life cycle states completely in the
future.
Currently, the first setState that happens during initial render will
start a new batch. Any subsequent updates will be batched. That means that
the first setState is synchronous but any subsequent setStates are
asynchronous.
This commit makes it so that the batching starts at the root. That way all
the setStates that happen within life-cycle methods are asynchronous.
I originally did this work so that we could allow setState to be called
before the internal ReactCompositeComponent was constructed. It's unlikely
that we'll go down that route now but this still seems like a better
abstraction. It communicates that this is not immediately updating an
object oriented class. It's just a queue which a minor optimization.
It also avoids bloating the ReactCompositeComponent file.
Since they both depend on the life cycle I break that out into a common
shared dependency. In a follow up I'll refactor the life-cycle management.
We need to move instantiation into the mount phase for context purposes.
To do this I moved the shallow rendering stuff into ReactTestUtils and
reused more of the existing code for it by instantiating a noop child.
Everywhere we refer to the "type" we should pass it to ReactNativeComponent
to resolve any string value into the underlying composite.
As part of the new class effort it is now possible to define React
Components using any type of generic JavaScript class syntax.
This includes TypeScript classes. This test ensures that we don't regress
that support, and also serves as an example for using React in TypeScript.
TypeScript provides a good demo of where we think property initializers
are going.
We don't have any official *type* support for TypeScript yet.
This test trails the ReactES6Class-test file. Some manual tweaking is
required when converting tests.
This adds a matcher called toEqualSpecsIn which executes two test suites,
without reporting the result. It then compares the specs and the number
of expects executed by each spec.
This will be used to ensure that tests written in other languages test the
same thing as the base line, ES6 classes.
Sets up CoffeeScript equivalence test.
As part of the new class effort it is now possible to define React
Components using any type of generic JavaScript class syntax.
This includes CoffeeScript. This test ensures that we don't regress that
support, and also serves as an example for using React in CoffeeScript.
This test fail trails the ReactES6Class-test file. Some manual tweaking is
required when converting tests.
There is no way to queue an update to a context so there is no need for
this field. The only way to get a new context is from above.
Soon _pendingElement will get the same treatment. Once _setPropsInternal
can be removed.
Instead of putting the shared code in a base class method, we use a wrapper
call around all invokations. That way they're free to add code before AND
after the non-shared code.
That way we ensure that component extensions don't need to implement
ReactComponentMixin and do super() calls into it. This helps to create a
tighter API for custom component extensions.
This provides the first step towards moving these methods to static
methods which allows to use a different dispatch mechanism instead of
virtual method calls. E.g. pattern matching.
We need to move instantiation into the mount phase for context purposes.
To do this I moved the shallow rendering stuff into ReactTestUtils and
reused more of the existing code for it by instantiating a noop child.
Everywhere we refer to the "type" we should pass it to ReactNativeComponent
to resolve any string value into the underlying composite.
You can only get a ref to a ReactCompositeComponent, so move the ref code here which gives us more flexibility to put it at the correct time in the lifecycle.
There should be no behavior change in this commit.
Test Plan: jest
This will be based on the site generation time, making doc generation
slightly less deterministic but that's ok. Now we won't depend on
helpful community members updating it for us (#2874) when we forget,
it'll just happen naturally the next time the site is generated.
Summary:
If `getDOMNode()` returns null in `LocalEventTrapMixin`, `listener` will also be null and `accumulateInto` will throw. This changes `LocalEventTrapMixin` to throw a more helpful error message.
Test Plan:
Ran unit test successfully:
```
npm test LocalEventTrapMixin-test.js
```
document.createElement throws an error if you don't pass it any
arguments. Neither PhantomJS nor jest (via jsdom at version jest is
using) behave as browsers do now so this went unnoticed.
This allows state to be set up in the constructor instead of through
getInitialState. getInitialState is now considered part of "classic".
Therefore, they move into ReactClass's constructor.
As a consequence of this, we no longer have a mapping between the internal
representation and the public instance during the mounting process.
Because the constructor hasn't returned yet.
We used to have a special case for calling setState in getInitialState
which was just ignored. This makes that throw and the component is
considered unmounted during the construction phase.
We added a bind to the public instance, but instead we can just pass the
public instance as the context when we execute.
This avoids a warning that fires when we call bind on auto-bound methods.
I don't agree with 80 on principal but it's what we have for now.
This fixes the reasonable cases. Most of the long lines are in docblocks
with long type information or containing links.
These rules are very close to what we have internally. We may still miss
a couple things (jsdoc params being a big one) but it's good enough.
This is also more restrictive than what we enforce internally, but it's
for the best.
In ReactClass we use early validation to warn you if a accidentally defined
propTypes in the wrong place or if you mispelled componentShouldUpdate.
For plain JS classes there is no early validation process. Therefore, we
wait to do this validation until the component is mounted before we issue
the warning.
This should bring us to warning-parity with ReactClass.
This is the base class that will be used by ES6 classes.
I'm only moving setState and forceUpdate to this base class and the other
functions are disabled for modern classes as we're intending to deprecate
them. The base classes only have getters that warn if accessed. It's as if
they didn't exist.
ReactClass now extends ReactComponentBase but also adds the deprecated
methods. They are not yet fully deprecated on the ReactClass API.
I added some extra tests to composite component which we weren't testing
to avoid regressions.
I also added some test for ES6 classes. These are not testing the new
state initialization process. That's coming in a follow up.
Fix outdated copyright year (update to 2015)
The copyright year was out of date. Copyright notices must reflect the current year. This commit updates the listed year to 2015.
ES6 classes won't have an early validation step. Therefore I added some
extra validation later on in the process. These would've normally have
been caught by createClass in classic React.
This throws an error that is immediately caught. This allows you to use the
debugger's "break on caught exception" feature to break on warnings.
This should help with tracking down these warnings using the stack.
However, it could also add more noise to other debugging pattern.
This essentially copies all classic element creation tests to the modern
JSX tests. The classic tests doesn't use JSX and modern tests do.
The idea is that the JSX tests can start dropping dynamic checks once
we have Flow support for those features. JSX won't be necessary for
dropping dynamic checks. Plain object will also work. Flow will also not
be necessary for JSX. However, the tests should test for the suggested
combination (JSX + Flow).
This also moves some misplaced tests to ReactDOM and Validator.
Note that the modern tests uses ES6 classes. I will add separate tests for
those. However, these are not guaranteed to have .displayName so all our
error messages should check .name if available instead. This should be
better abstracted but I just adhoc fix this for now.
This should make it more clear that even though `$` is used in 4 methods, only 2 of them are crucial for integrating the modal into the components lifecycle methods and the other 2 are just helpers.
This adds a warning to React.createElement in __DEV__ about using null
or undefined. This is technically valid since element creation can be
considered safe and usable in multiple rendering environments. But
rendering in a DOM environment with an element with null/undefined type
is not safe.
Update tutorial.md to improve grammatical parallelism in features list. Also added periods to follow first item's syntax.
BEFORE: "Live updates: as other users comment we'll pop them into the comment view in real time"
AFTER: "Live updates: other users' comments are popped into the comment view in real time."
BEFORE: "Markdown formatting: users can use Markdown to format their text"
AFTER: "Markdown formatting: users can use Markdown to format their text."
This moves ReactClass, ReactElement and ReactPropTypes into a legacy folder
but since it's not quite legacy yet, I call it "classic".
These are "classic" because they are decoupled and can be replaced by
ES6 classes, JSX and Flow respectively.
This also extracts unit tests from ReactCompositeComponent, which was
terribly overloaded, into the new corresponding test suites.
There is one weird case for ReactContextValidator. This actually happens in
core, and technically belongs to ReactCompositeComponent. I'm not sure
we will be able to statically validate contexts so this might be a case
for dynamic checks even in the future. Leaving the unit tests in classic
until we can figure out what to do with them.
In order to improve support for Chinese and Japanese IME input in
Internet Explorer, use a fallback composition state to determine
inserted text. IE composition events are mostly okay, except for
certain punctuation characters that are ignored. Using the fallback, we
can detect these characters.
The fallback is also useful for emitting `beforeInput` events, so it
makes sense to simply combine these plugins.
This change also incorporates a recent change to the Google Input Tools
browser extension that exposes a `data` field via the `detail` object
on the custom composition events it emits.
IE9+ has support for window.getSelection, but we’re still using
document.selection for IE9/10. Only use the old IE selection API if the
modern one is unavailable.
Based on conversation in https://github.com/facebook/react/pull/2501. A good place to guide people further in finding the complete set of tools needed to build an application.
This was a file we probably never should have synced out in the first
place. We don't use it and it provides the same basic functionality that
bin/jsx provides.
ART, just like MultiChild adds an expando property to manage it's diffing
state. This is ugly and bad. We should be moving this state outside the
component for use by the diffing algorithm. This state is not needed by
components nested in composites, and varies by diffing algorithm.
It sucks that I have to add it to every component just to support ART,
but that's the quickest solution, other than disabling preventExtensions.
At least now we know that it sucks.
This separates the reconciliation step of children into a separate module.
This is the first step towards prerendering.
The stateful instances are reconciled and put into a "rendered children"
set. Updates creates a new of these sets. These two sets are then diffed
to create insert/move/remove operations on the set.
The next step is to move the ReactChildReconciler step to before the
native DOM component. That way it's possible to rely on child
reconciliation without relying on diffing.
Summary:
After #2570, `mountDepth` is only used to enforce that `setProps` and `replaceProps` is only invoked on the top-level component. This replaces `mountDepth` with a simpler `isTopLevel` boolean set by `ReactMount` which reduces the surface area of the internal API and removes the need to thread `mountDepth` throughout React core.
Reviewers: @sebmarkbage @zpao
Test Plan:
Ran unit tests successfully:
```
npm run jest
```
Currently, `ReactUpdates` updates dirty components in increasing order of mount depth. However, mount depth is only relative to the component passed into `React.render`. This breaks down for components that invoke `React.render` as an implementation detail because the child components will be updated before the parent component.
This fixes the problem by using the order in which components are mounted (instead of their depth). The mount order transcends component trees (rooted at `React.render` calls).
Reviewers: @sebmarkbage @zpao
Test Plan:
Ran unit tests successfully:
```
npm run jest
```
Summary:
Changes the way we instrument methods for `ReactPerf` so that developer tools can assign implicit method names to measured functions.
Reviewers: @zpao @sebmarkbage
Update to the animation documentation for ReactTransitionGroup to clear the air on where one can use it.
If someone tries to use it off of React.addons.ReactTransitionGroup, which is undefined, instead of its real location, React.addons.TransitionGroup, they get a vague error about being unable to set defaultProps of undefined in the React createElement body.
Summary:
Currently, `ReactClass` mutates values returned by `getDefaultProps`, `getInitialState`, and `getChildContext`. This is bad because the objects may, for example, be cached and re-used across instances of a React component.
This changes `ReactClass` to instead create a new object. In return for allocating a new object, I've replaced `mapObject` with a `for ... in` so that we are no longer allocating an unused object.
Fair trade, IMO.
Test Plan:
Ran unit tests successfully:
```
npm run jest
```
Conflicts:
src/core/ReactCompositeComponent.js
Conflicts:
src/class/ReactClass.js
The word "Friends" does establish a relationship however it does not fit in the vernacular of react.
This change makes the phrase more explicit and more familiar.
We currently have three DOM specific hooks that get injected. I move those
out to ReactComponentEnvironment. The idea is to eventually remove this
injection as the reconciler gets refactored.
There is also a BackendIDOperation which is specific to the DOM component
itself so I move this injection to be more specific to the DOMComponent.
E.g. it makes sense for it to be injectable for cross-worker DOM operations
but it doesn't make sense for ART components.
If several children complete leaving before rendering TransitionGroup,
only the last one was removed. This could easily happen if
callback in componentWillLeave is called synchronously and several items
are removed from array. The other case is when ReactCSSTransitionGroup
has transitionLeave={false} and array is also cleaned up.
The bug was happening because this.state.children was used as a base for
children removal and it wasn't updated until the render, so only the last
removal was actually happening.
Fix involves keeping the updated children state between invocations of
_handleDoneLeaving. After updating this.state and rendering,
updatedState is cleaned up and ready for subsequent array modifications.
Test case included.
This is part of moving more logic out of the base classes.
setProps, replaceProps etc. are not accessible from anything other than
ReactClass so we can safely move it to ReactCompositeComponent.
mountComponentIntoNode is tightly coupled to ReactMount. It's part of the
outer abstraction, the mount point, not the individual component.
The _owner field is unnecessary since it's reachable from _currentElement.
The _lifeCycle field is unnecessary because an internal component should
not even need to exist at all if it's unmounted. It should be dereferenced
internally, and never exposed externally.
The only case where it's important is for batching updates where we
currently avoid calling performUpdateIfNecessary if it's mounted. However,
this function is already only executed "if necessary" so we just make sure
that it's not necessary after unmount by resetting all the pending fields.
We currently make a copy of .style because we support mutating the style object in place. Instead of storing it back on props, store it separately on the component instance so that we don't mutate props anywhere. This is gross but should all be cleaned up after #2008 is resolved.
Test Plan: jest
createFullPageComponent doesn't reference ReactBrowserComponentMixin directly so the mixin should get injected before the components are created. Previously, this test failed because getDOMNode wasn't present on the component instance.
Test Plan: jest
...unless they already have a wrapper. Also, add tagName to every wrapper.
This ensures that refs are consistent. They always look like composite
components. This effectively hides the internal implementation details of
real DOM components since you can no longer get a ref to one.
In the future we might want to drop this wrapper and have refs refer
directly to the DOM node.
I currently use a hacky way of auto-wrapping inside of ReactNativeComponent
so that any given string can be wrapped. Better suggestions are welcome.
Fixes#2493, also closes#2353 as it incorporates a variant of that fix.
- Instead of having getEmptyComponent return `<noscript />` directly, wrap it in a class that we can easily identify later as being an empty component
- Cache the empty component element instead of recreating one each time
- Avoid touching the nullComponentIdsRegistry dictionary at all when not dealing with empty components
- Move empty-component tests to a separate file
Test Plan: jest
ReactTextComponent's implementation is DOM-specific; instead of flattenChildren creating the ReactTextComponent instances, ReactNativeComponent now takes care of having ReactTextComponent injected and creating the component instance. I also renamed ReactTextComponent to ReactDOMTextComponent and moved it to browser/ui/ where it belongs. ReactDOMTextComponent no longer inherits directly from ReactComponent and instead implements construct and {mount,receive,unmount}Component directly.
This diff removes `ReactTestUtils.isTextComponent` which should have previously never returned true when using public APIs.
Test Plan: jest, use ballmer-peak example.
"appear" differs from "enter" in that all children of a transition group at mount time will "appear" but will not "enter". All children later added to an existing transition group will "enter" but not "appear".
This extra transition phase allows for animation-on-mount effects.
A mirroring "appear" prop has been added to ReactCSSTransitionGroup, however for reverse-compatibility (and because "appear" is less common) it defaults to false.
Thanks to @afa for his work investigating the possible ways to implement this.
monitorScrollValue is only called with `ViewportMetrics.refreshScrollValues` (https://github.com/facebook/react/blob/master/src/browser/ReactBrowserEventEmitter.js#L333-L334) and the window scroll properties (scrollTop and scrollLeft) don't change on resize (from my testings), so there is no need to listen for window resizes.
I also tried to see why the resize listener was added from the history but it was introduced on the initial commits.
I created a simple page that shows that http://jsbin.com/nuhice, open the console.
While working on #2382, I accidentally broke this behavior (causing text components to get unmounted and remounted for any update) but we didn't have any unit test for it. Now we do.
Test Plan: jest TextComponent
ReactClass is now composed by ReactCompositeComponent rather than
inherit from it.
The state transition functions currently use ReactInstanceMap to map an
instance back to an internal representation.
I updated some tests to use public APIs. Other unit tests still reach into
internals but now we can find them using ReactInstanceMap.
I will do more cleanup in follow ups. The purpose of this diff is to
preserve semantics and most of the existing code.
This effectively enables support for ES6 classes. All you would need to
expose is ReactClassMixin.
The use of the conjunction "and" leads to an improper assertion about what should/shouldn't be done. Using a semicolon resolves this by indicating the contrasting alternative.
* master: (113 commits)
Remove esprima-fb and use Syntax from jstransform
Update React.renderToString argument type in docs
[traverseAllChildren] fix out-of-scope var use.
Use double quote for transformed `displayName` and `data-*`
Remove unrelated comment
Fix typo in If/Else JSX doc.
Cleanup a couple unused variables
Use dump cache and remove factory from ReactElement-test
Update deprecated propTypes
Bring in jsfiddle integration script, add harmony
Extending period in which click events are ignored
React.renderComponent --> React.render
Followup fix for React.PropTypes.node
Add comma for readability in tutorial
Drop internal uses of .type on the class
Drop Legacy Factories Around Classes
Drop ReactDOM from internal DOM extensions
Added comma to increase readability.
Add 0.12 starter kit
Change the date and the link url to match the proper roundup
...
Conflicts:
docs/docs/02.1-jsx-in-depth.md
Dear ES6 gods, bring us `let` soon.
This fixes an issue where non-keyed iterables are used as children and the value of `i` would be undefined because its used out of scope. This adds a separately scoped iteration index value and appropriately increments it as iteration continues. Doi.
While I'm in there, make the usage of falsey `nameSoFar` more obvious and more consistent with the existing usage on L115
Test plan: first wrote a test covering this previously untested path. Saw an identical issue as was experienced in development environment. Then ensured test passed after this diff.
JSX currently transforms everything to double quote except these two. This way, it's at least consistent and will satisfy half of the people who do put a strict quotation linting on their project.
Test: `jest`, check the double quoted transformed `data-bla="something"`.
We need to use dump cache because we don't enable it by default internally.
While I'm at it, I might as well kill the ComponentFactory variable which
is now just an alias.
Classes are now pure classes without a legacy factory around them.
Since classes will become just any function that returns a valid instance,
let's drop isValidClass.
There's some hacks in here for auto-mocking frameworks (jest) that mock the
prototype of these classes. These hacks allow these classes to be mounted.
On ios device, browser simulates mouse events, but does that with
a delay, because of double tap gesture. The problem is that
TapEventPlugins listens to both types of events, so it fires twice
Everytime there is a touch event, we should ignore mouse events that
follow it. This way, we still respond to both mouse and touch events,
just ignore the device generated ones.
For example, warning might be replaced with a module that throws errors,
as is the case internally when running tests. Previously we were
whitelisting this test to provide time to update callsites. Now we
aren't and it fails.
Hi in chrome debugger, the files that use sourcemaps from the transformer get "null" as the filename during debug, https://github.com/facebook/react/blob/master/main.js#L15 "sourceFilename" is used instead of "filename" to specify the filename in the sourcemap.
This prevents feature tests like:
var ReactElement = React.createElement(...).constructor;
if (element.constructor === ReactElement)
This is intentional so that we have the option to make these plain objects.
E.g. for direct inlining or replacing them with value types.
This prevents feature tests like:
var ReactElement = React.createElement(...).constructor;
if (element.constructor === ReactElement)
This is intentional so that we have the option to make these plain objects.
E.g. for direct inlining or replacing them with value types.
This moves logic responsible for class creation and mixins into
the ReactClass module. This currently creates a class that extends
the ReactCompositeBase but in the future, this will be decoupled as
ReactCompositeComponent will compose these classes.
This is just a cut/paste.
Fixes#1392.
Previously, ReactComponent.updateComponent set the new props and owner and updated the component's refs. Because it did the actual props assignment, it had to be called by ReactCompositeComponent between componentWillMount and componentDidMount, meaning that it was skipped if shouldComponentUpdate returned false. Now, updateComponent takes the old and new descriptors and only updates refs, allowing a subclass to call updateComponent at a convenient time (specifically, it can be before `this._descriptor` is updated if the subclass also overrides performUpdateIfNecessary).
The new update cycle for composites is:
- receiveComponent is called which stores `this._pendingDescriptor` and calls performUpdateIfNecessary directly or a state update is enqueued, in which case ReactUpdates will call performUpdateIfNecessary
- performUpdateIfNecessary ensures that an update is still pending (which might no longer be the case if an update is queued for a subcomponent that was updated through a parent's reconciliation) and calls updateComponent with the old and new descriptors
- updateComponent calls super to update refs, then calls componentWillReceiveProps (if applicable) and shouldComponentUpdate -- if shouldComponentUpdate returns false, `this._descriptor`, `this.props`, and `this.state` are updated and the update is skipped; else, _performComponentUpdate is called
- _performComponentUpdate calls componentWillUpdate and _updateRenderedComponent, and enqueues the componentDidUpdate call (in that order)
- _updateRenderedComponent calls render and updates the rendered component appropriately
For DOM components (essentially unchanged):
- receiveComponent is called which does a short-circuit check for descriptor equality and delegates to super (which stores `this._pendingDescriptor` and calls performUpdateIfNecessary)
- performUpdateIfNecessary (not overridden) sets new values for `this.props`, etc. and calls updateComponent
- updateComponent does the DOM property and children updates (some synchronously, some queued for the transaction close)
For text and ART components (unchanged):
- receiveComponent updates the DOM or ART directly based on the new props
- updateComponent is never called
Notable changes:
- When shouldComponentUpdate returns false, refs are still updated
- ReactDefaultPerf now includes lifecycle methods in component timings
- updateComponent's signature changed (technically this is part of the public API, though we've never documented it)
Test Plan: jest
Same for <pre> and <listing>. Browsers are crazy.
Test Plan: jest, verify in Chrome that starting textareas with a value starting with two newlines renders both newlines instead of one newline, as it did before.
This lets you use any kind of iterable as a container of react child elements. It also preserves keys when possible if the iterable is keyed.
* Use an ES6 Map or Set to hold children.
* Use an Immutable-js collection to hold children.
* Use a function* which yields children.
Concretely, this removes the necessary conversion to JS objects if you're mapping over Immutable-js collections to get children, i.e.:
```
<div>
{myImmutable.map(val => <span>{val}</span>).toJS()
</div>
```
Now we can remove the `toJS()` and the intermediate allocation along with it.
This also cleans up the traverseAllChildrenImpl method.
I kept some places intact (search for @jsx) because they require other bigger changes:
- ref-01-top-level-api.md
- grunt/tasks/npm.js
- old blog posts (don't change those)
- examples/ folder, as they have their own package.json that rely on old dependencies (node-jsx, reactify) that haven't upgraded to 0.12
Add note about ReactTransitionGroup, that any additional, user-defined, properties will be become properties of the rendered component.
And example how to render a `<ul>` with css class.
Because the JS community's polyfilling infrastructure sucks and we'll
have to fix it for them before we require this.
JSX spread uses React.__spread
(which might get special behavior for key/ref, not sure yet)
This never uses the native implementation and throws for prototype chains.
Once the native implementations are faster, we'll start using them.
Hello,
I was just reading through your post and noticed a minor change. The sentence originally read, "It's scaled very well for us...". I thought it was a little unclear since it's can mean "it has" or "it is", which can make this sentence take on a whole different meaning.
The URL already made its way around so we can't just break it. We might
want to just live with it instead of even doing this redirect.
2b225446c0 (commitcomment-8176218)
People may have a bad time if they're depending on these but we can
delay that a little bit. Unless they're using directly and not
polyfilling Object.assign.
Because we're using innerHTML to generate DOM Elements, we need to make
sure that the tag is sane and doesn't try to do injection.
This wouldn't be an issue if we used document.createElement instead.
* ReactComponents aren't really the thing we need, ReactElements are
* Remove the deprecation notice that we've had in there for a long time
Test Plan: build, jest
This makes it easier to contribute without having to learn a bunch of
slightly different helpers and remember their slightly different
signatures and semantics.
We'll probably start using ES7 spread properties instead of merge in the
future when at least one more transpiler supports it.
React.DOM is becoming helper factories to generate ReactElements. They're not
classes. It will be ok to call them directly as functions, but not to use them
where a class is expected.
I grepped for uses of React.DOM. This is going to be a set of helper functions
to generate ReactElements without JSX.
They're not classes so they cannot be used where a React class is expected.
Since we always use JSX, we should have no internal use for these helpers.
We can use strings instead.
We're trying to move to a convention where lower-case variables on JSX are always HTML/SVG tags rather than variables in scope. See:
http://fb.me/react-jsx-lower-case
Therefore, this diff renames existing uses to upper case variables.
This throws an error on all these files, so I manually go rename all the variables. I then run lint to ensure that the rename doesn't leave any undeclared variables.
This makes ReactDOM a simple helper for creating ReactElements with the string tag as the type. The actual class is internal and created by instantiateReactComponent. Configurable using injection.
There's not a separate class for each tag. There's just a generic ReactDOMComponent which could take any tag name.
Invididual tags can be wrapped. When wrapping happens you can return the same tag again. If the wrapper returns the same string, then we fall back to the generic component. This avoids recursion in a single level wrapper.
This doesn't actually remove the pages, just the main content. Sidebar
items now link offsite. The pages doesn't automatically redirect, but we
could do that if we really wanted.
Fixes#2229
You have to instantiate a Dispatcher to use it, not just grab the prototype or it will fail when trying to grab instance properties like: this.$Dispatcher._callbacks.
IE9+ supports `window.getSelection()` but `SelectEventPlugin` gives precedence to `document.selection` instead. `document.selection` is still available in later versions of IE, but the modern Selection object is preferable. Swap the two.
The second argument of mockComponent was listed as tagName, but referred to in the description as mockTagName. I changed the first one to mockTagName to be consistent.
The first sentence had an unnecessary semicolon which made the whole thing difficult to read. The new syntax is not only easier to read but also more exciting.
The previous wording could be interpreted to mean sub-trees moving from
within one sibling to within another, rather than the shuffling of siblings on
a single level as intended
Edit the description of componentDidMount() to make clear that the function is called only once during the lifecycle of the component, after only the initial render() call. The description is now similar to that for componentWillMount(). The existing wording does not make it clear that the function is called only after the initial render. (Granted, it is possible to infer this from descriptions of the component lifecycle found elsewhere in the documentation, but I think explicit is better than implicit in this case).
The HTMLtoJSX file is really a part of the React-Magic project, and should belong there rather than here:
- It doesn't really follow the release cycle of React at all
- It is totally standalone with no dependency on React
- The only usage of this script is in React-Magic and on the HTML to JSX page on the React website (http://facebook.github.io/react/html-jsx.html)
I've hotlinked it from the Github site for that project since this was the easiest way to pull it in.
Due to the fact that Github Pages lacks redirects (among other basic web hosting functionality), I've replaced the `html-jsx-lib.js` file with a comment explaining where the file has moved to, just in case anyone was hotlinking it from the React site.
I traced the current logo in Illustrator to get a good version. And with
SVG we don't need any 2x magic because it's already vector. I should
probably care about IE8, but I don't.
We currently automatically render empty components in place of mocks. However,
we were accidentally transferring the props from the mocked descriptor to the
empty component placeholder. Even children.
This change just cleans that up and should only affect unit tests.
Trying to make the event a bit more performant for events.
Feel free to reject this because the API inevitably isn't great. It's good for perf though, and since we're only using `accumulate` in very restrained places, I think we're fine.
`accumulateInto` is `accumulate` that mutates more and allocates less. I kept `accumulate` in case we want that in the future.
The spec changed to allow null & undefined sources without throwing.
Now our code depends on this new behavior. The only browser that
implements Object.assign has also updated its native implementation to
this behavior (Firefox Nightly).
The biggest change: instead of calling functions directly, we now use
React.createElement to wrap.
The other big change: this removes the need for the @jsx pragma.
Instead we'll parse everything, assume React is in scope,
and only look for the actual XJS parts in the AST (as opposed to only
runing the transform when @jsx was specified in the docblock).
Note: this is actually a series of commits internally and should have
been syned out in pieces over the past several weeks.
This fixes some log spew since this pattern is deprecated. This doesn't use
the validator in the descriptor creation so there's no prop type checks here.
I guess that's fine because we still have the second prop type checks.
We need to use ReactLegacyDescriptor because the constructor here will be a
legacy factory that we need to unwrap.
constructAndRenderComponent should be deprecated.
Replace plain function calls to legacy factories with createFactory or
createElement. For ReactDOMComponents the type should be replaced with
strings.
Because we don't have easy access to ReactLegacyDescriptor from within
React, we need to use the .type property to extract the real class.
This will go away later and is covered by unit tests.
This moves all logic around legacy descriptors to ReactLegacyDescriptor. This
is responsible for the layer that knows that createClass exports a legacy
factory. When passed one of these classes, it unwraps it to be a real class.
If it is passed a non legacy factory, it is assumed to be a non-react component
that needs to be invoked as a plain function.
The semantic change is that a descriptor is now always returned if passed a
legacy factory. Even if that factory is a mock. A mock would previously return
undefined.
For mocks, I treat the factory as the authoritative function. I call it to extract
the instance or fill it with an empty component placeholder.
Additionally, I make the classes take props as the first argument to the
constructor. This is what the new class system will do.
We currently need to set up some internals by calling the internal construct
method. Instead of doing that automatically in the constructor, I now move that
to a second pass so that mocks can get the plain props.
This means that we can assert that a mock has been called once it's mounted
with it's final props. Instead of the descriptor factory being called.
The reason I chose to submit this is because it was initially unclear from the docs that the transition group needed to already be mounted in order for it to work properly.
I dropped the part of constants.js that we weren't using (namely the
part where we insert constants) but left it open to do that. It should
be trivial, we just aren't using it.
Fixes#1824
Added docs for `React.isValidClass` and `React.isValidComponent`.
Still missing top level api:
* `constructAndRenderComponent`
* `constructAndRenderComponentById`
* `withContext`
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).
Depends on #1758.
Fixes#1698.
Previously, controlled components would update too soon when using something like ReactLayeredComponentMixin (i.e., before the layer's updates could propagate from the parent), causing the cursor to jump even when always updating the new model value to match the DOM state. With this change, we defer the update until after all nested updates have had a chance to finish, which prevents the cursor from misbehaving.
Also cleaned up the logic around updating a bit -- the .value and .checked updates in ReactDOMInput weren't being relied on at all so I removed them and opted for a simple forceUpdate instead. I also got rid of _isChanging which hasn't been necessary since the introduction of update batching.
Test Plan: Tested the example in http://jsfiddle.net/Bobris/ZZtXn/2/ and verified that the cursor didn't jump. Changed the code to filter out numbers and verified that the field prevents typing numbers (attempting to do so still causes the cursor to jump to the end). Also verified that controlled and uncontrolled radio buttons, textareas, and select boxes work.
Callbacks passed to this setImmediate function are called at the end of the current update cycle, which is guaranteed to be asynchronous but in the same event loop (with the default batching strategy).
This is useful for new-style refs (#1373, #1554) and for fixing #1698.
Test Plan: jest
This isn't a good final solution but it makes React actually usable on
its own.
This also makes tests runnable, though only via jest
(./node_modules/.bin/jest)
The `mockTagName` parameter was always optional, and so probably was not
used very often. If you tried to use it, it would be shadowed by the
`var mockTagName` declaration in the `render` method, so only
`module.mockTagName` or `"div"` were ever possible values.
Relax the argument type checks. Currently we throw for non-objects and terminals
but Object.assign does a coercion to Object instead. It also allows merging
Arrays as if they are objects.
This also relaxes the check for dependents such as ImmutableObject. This sucks
but it will allow us to use a fast code path to native Object.assign.
We always have the option of adding warnings to Object.assign or static type
checks.
I'm keeping the null check. Object.assign throws for null checks.
We'll also start returning the result of coercions just like Object.assign.
This detail is going to become more important once the idiom
`className={joinClasses(this.props.className, newClass)}` becomes more
common, as it will when we move away from `this.transferPropsTo`.
Breaking changes
- key/ref are no longer accessible on props but they are accessible on the
descriptors. This means that parents/owners can access it but not the
component itself.
- Descriptor factories are now plain functions and you can't rely on the
prototype or constructors of descriptors to identify the component type.
Existing descriptor factories are now wrapped in a legacy factory. Currently it
does nothing but it will give us a hook to track callers to factories that are
not using JSX but just invoking the function directly. It also proxies static
methods/properties to the underlying class. The newer factories don't have this
feature.
ReactTextComponent has it's own little factory because it's props is not an
object. This is a detail and will go away once ReactTextComponent no longer
needs descriptors.
Whilst this is intentional behaviour (see #1274), it is not documented anywhere, so it is worth mentioning.
It would also be nice if React issued a warning to console if a cloned component loses its key (as this will silently break reconciliation?)
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/
We now forbid calling setState or forceUpdate if any component's render function is higher in the stack, not just the component you're trying to update. (We do this already now for React.renderComponent and React.unmountComponentAtNode.)
This also has the advantage that we can now remove CompositeLifeCycle.RECEIVING_STATE, making _compositeLifeCycleState easier to reason about (not to mention that RECEIVING_STATE was a confusing name) and making it possible to remove a try/finally from the render path which might help with perf.
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.
This way it doesn't end when some random element elsewhere on the page has an ending transition.
It must be noted that this is not a complete fix. If you have multiple transitions on the element, it still ends when the first ends.
I ran into this not working (the transition ends almost immediately, because some unrelated transition ends). This fixes it for me, but I was wondering whether this cornercase was considered, and whether the other cornercase (multiple transitions) was considered.
I think it's very hard to get this correct, and think it might be better to make the timeout explicit, or at least allow to set it explicit, and fall back to this behaviour. But I'm really interested in feedback on this one.
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
1302 changed files with 197637 additions and 35889 deletions
React is one of Facebook's first open source projects that is both under very active development and is also being used to ship code to everybody on facebook.com. We're still working out the kinks to make contributing to this project as easy and transparent as possible, but we're not quite there yet. Hopefully this document makes the process for contributing clear and preempts some questions you may have.
Want to contribute to React? There are a few things you need to know.
## Our Development Process
Some of the core team will be working directly on GitHub. These changes will be public from the beginning. Other changesets will come via a bridge with Facebook's internal source control. This is a necessity as it allows engineers at Facebook outside of the core team to move fast and contribute from an environment they are comfortable in.
### `master` is unsafe
We will do our best to keep `master` in good shape, with tests passing at all times. But in order to move fast, we will make API changes that your application might not be compatible with. We will do our best to communicate these changes and always version appropriately so you can lock into a specific version if need be.
### Pull Requests
The core team will be monitoring for pull requests. When we get one, we'll run some Facebook-specific integration tests on it first. From here, we'll need to get another person to sign off on the changes and then merge the pull request. For API changes we may need to fix internal uses, which could cause some delay. We'll do our best to provide updates and feedback throughout the process.
*Before* submitting a pull request, please make sure the following is done…
1. Fork the repo and create your branch from `master`.
2. If you've added code that should be tested, add tests!
3. If you've changed APIs, update the documentation.
4. Ensure the test suite passes (`grunt test`).
5. Make sure your code lints (`grunt lint`) - we've done our best to make sure these rules match our internal linting guidelines.
6. If you haven't already, complete the CLA.
### Contributor License Agreement ("CLA")
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>
## Bugs
### Where to Find Known Issues
We will be using GitHub Issues for our public bugs. We will keep a close eye on this and try to make it clear when we have an internal fix in progress. Before filing a new task, try to make sure your problem doesn't already exist.
### Reporting New Issues
The best way to get your bug fixed is to provide a reduced test case. jsFiddle, jsBin, and other sites provide a way to give live examples. Those are especially helpful though may not work for `JSX`-based code.
### Security Bugs
Facebook has a [bounty program](https://www.facebook.com/whitehat/) for the safe disclosure of security bugs. With that in mind, please do not file public issues and go through the process outlined on that page.
## How to Get in Touch
* IRC - [#reactjs on freenode](http://webchat.freenode.net/?channels=reactjs)
* Mailing list - [reactjs on Google Groups](http://groups.google.com/group/reactjs)
## Coding Style
* Use semicolons;
* Commas last,
* 2 spaces for indentation (no tabs)
* Prefer `'` over `"`
*`"use strict";`
* 80 character line length
* "Attractive"
## License
By contributing to React, you agree that your contributions will be licensed under the [Apache License Version 2.0 (APLv2)](LICENSE).
We wrote a **[contribution guide](https://facebook.github.io/react/contributing/how-to-contribute.html)** to help you get started.
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.
* **Declarative:** React makes it painless to create interactive UIs. Design simple views for each state in your application, and React will efficiently update and render just the right components when your data changes. Declarative views make your code more predictable, simpler to understand, and easier to debug.
* **Component-Based:** Build encapsulated components that manage their own state, then compose them to make complex UIs. Since component logic is written in JavaScript instead of templates, you can easily pass rich data through your app and keep state out of the DOM.
* **Learn Once, Write Anywhere:** We don't make assumptions about the rest of your technology stack, so you can develop new features in React without rewriting existing code. React can also render on the server using Node and power mobile apps using [React Native](https://facebook.github.io/react-native/).
[Learn how to use React in your own project.](http://facebook.github.io/react/docs/getting-started.html)
[Learn how to use React in your own project](https://facebook.github.io/react/docs/getting-started.html).
## Examples
We have several examples [on the website](http://facebook.github.io/react). Here is the first one to get you started:
We have several examples [on the website](https://facebook.github.io/react/). Here is the first one to get you started:
```js
/** @jsx React.DOM */
varHelloMessage=React.createClass({
render:function(){
return<div>{'Hello '+this.props.name}</div>;
classHelloMessageextendsReact.Component{
render(){
return<div>Hello{this.props.name}</div>;
}
});
}
React.renderComponent(
ReactDOM.render(
<HelloMessagename="John"/>,
document.getElementById('container')
);
@@ -28,69 +27,39 @@ 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](https://facebook.github.io/react/docs/introducing-jsx.html). JSX is not required to use React, but it makes code more readable, and writing it feels like writing HTML. We recommend using [Babel](https://babeljs.io/) with a [React preset](https://babeljs.io/docs/plugins/preset-react/) to convert JSX into native JavaScript for browsers to digest.
## Installation
The fastest way to get started is to serve JavaScript from the CDN:
React is available as the `react` package on [npm](https://www.npmjs.com/). It is also available on a [CDN](https://facebook.github.io/react/docs/installation.html#using-a-cdn).
React is flexible and can be used in a variety of projects. You can create new apps with it, but you can also gradually introduce it into an existing codebase without doing a rewrite.
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.
The recommended way to install React depends on your project. Here you can find short guides for the most common scenarios:
If you'd like to use [bower](http://bower.io), it's as easy as:
* [Trying Out React](https://facebook.github.io/react/docs/installation.html#trying-out-react)
* [Creating a Single Page Application](https://facebook.github.io/react/docs/installation.html#creating-a-single-page-application)
* [Adding React to an Existing Application](https://facebook.github.io/react/docs/installation.html#adding-react-to-an-existing-application)
```sh
bower install --save react
```
## Contributing
## 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, check out our [contribution guide](https://facebook.github.io/react/contributing/how-to-contribute.html).
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.
### [Code of Conduct](https://code.facebook.com/codeofconduct)
### Building Your Copy of React
Facebook has adopted a Code of Conduct that we expect project participants to adhere to. Please read [the full text](https://code.facebook.com/codeofconduct) so that you can understand what actions will and will not be tolerated.
The process to build `react.js` is built entirely on top of node.js, using many libraries you may already be familiar with.
### Good First Bug
#### Prerequisites
To help you get your feet wet and get you familiar with our contribution process, we have a list of [good first bugs](https://github.com/facebook/react/labels/good%20first%20bug) that contain bugs which are fairly easy to fix. This is a great place to get started.
* You have `node` installed at v0.10.0+ (it might work at lower versions, we just haven't tested).
* You are familiar with `npm` and know whether or not you need to use `sudo` when installing packages globally.
* You are familiar with `git`.
### License
#### Build
React is [BSD licensed](./LICENSE). We also provide an additional [patent grant](./PATENTS).
Once you have the repository cloned, building a copy of `react.js` is really easy.
React documentation is [Creative Commons licensed](./LICENSE-docs).
```sh
# grunt-cli is needed by grunt; you might have this installed already
npm install -g grunt-cli
npm install
grunt build
```
Examples provided in this repository and in the documentation are [separately licensed](./LICENSE-examples).
At this point, you should now have a `build/` directory populated with everything you need to use React. The examples should all work.
### Grunt
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
grunt test
# Lint the core library code with JSHint
grunt lint
# Lint package code
grunt lint:package
# Wipe out build directory
grunt clean
```
### More…
There's only so much we can cram in here. To read more about the community and guidelines for submitting pull requests, please read the [Contributing document](CONTRIBUTING.md).
## Troubleshooting
See the [Troubleshooting Guide](https://github.com/facebook/react/wiki/Troubleshooting)
// use a warning instead of an _invariant so components
// don't show up in prod but only in __DEV__
process.env.NODE_ENV!=='production'?warning(typeoftypeDef[propName]==='function','%s: %s type `%s` is invalid; it must be a function, usually from '+'React.PropTypes.',Constructor.displayName||'ReactClass',ReactPropTypeLocationNames[location],propName):void0;
// Disallow overriding of base class methods unless explicitly allowed.
if(ReactClassMixin.hasOwnProperty(name)){
_invariant(specPolicy==='OVERRIDE_BASE','ReactClassInterface: You are attempting to override '+'`%s` from your class specification. Ensure that your method names '+'do not overlap with React methods.',name);
}
// Disallow defining methods more than once unless explicitly allowed.
if(isAlreadyDefined){
_invariant(specPolicy==='DEFINE_MANY'||specPolicy==='DEFINE_MANY_MERGED','ReactClassInterface: You are attempting to define '+'`%s` on your component more than once. This conflict may be due '+'to a mixin.',name);
}
}
/**
* Mixin helper which handles policy validation and reserved
process.env.NODE_ENV!=='production'?warning(isMixinValid,'%s: You\'re attempting to include a mixin that is either null '+'or not an object. Check the mixins included by the component, '+'as well as any mixins they include themselves. '+'Expected object but got %s.',Constructor.displayName||'ReactClass',spec===null?null:typeofSpec):void0;
}
return;
}
_invariant(typeofspec!=='function','ReactClass: You\'re attempting to '+'use a component class or function as a mixin. Instead, just use a '+'regular object.');
_invariant(!isValidElement(spec),'ReactClass: You\'re attempting to '+'use a component as a mixin. Instead, just use a regular object.');
varproto=Constructor.prototype;
varautoBindPairs=proto.__reactAutoBindPairs;
// By handling mixins before any other properties, we ensure the same
// chaining order is applied to methods with DEFINE_MANY policy, whether
// mixins are listed before or after these methods in the spec.
_invariant(!isReserved,'ReactClass: You are attempting to define a reserved '+'property, `%s`, that shouldn\'t be on the "statics" key. Define it '+'as an instance property instead; it will still be accessible on the '+'constructor.',name);
varisInherited=nameinConstructor;
_invariant(!isInherited,'ReactClass: You are attempting to define '+'`%s` on your component more than once. This conflict may be '+'due to a mixin.',name);
Constructor[name]=property;
}
}
/**
* Merge two objects, but throw if both contain the same key.
*
* @param {object} one The first object, which is mutated.
* @param {object} two The second object
* @return {object} one after it has been mutated to contain everything in two.
_invariant(one[key]===undefined,'mergeIntoWithNoDuplicateKeys(): '+'Tried to merge two objects with the same key: `%s`. This conflict '+'may be due to a mixin; in particular, this may be caused by two '+'getInitialState() or getDefaultProps() methods returning objects '+'with clashing keys.',key);
one[key]=two[key];
}
}
returnone;
}
/**
* Creates a function that invokes two functions and merges their return values.
*
* @param {function} one Function to invoke first.
* @param {function} two Function to invoke second.
* @return {function} Function that invokes the two argument functions.
* @private
*/
functioncreateMergedResultFunction(one,two){
returnfunctionmergedResult(){
vara=one.apply(this,arguments);
varb=two.apply(this,arguments);
if(a==null){
returnb;
}elseif(b==null){
returna;
}
varc={};
mergeIntoWithNoDuplicateKeys(c,a);
mergeIntoWithNoDuplicateKeys(c,b);
returnc;
};
}
/**
* Creates a function that invokes two functions and ignores their return vales.
*
* @param {function} one Function to invoke first.
* @param {function} two Function to invoke second.
* @return {function} Function that invokes the two argument functions.
* @private
*/
functioncreateChainedFunction(one,two){
returnfunctionchainedFunction(){
one.apply(this,arguments);
two.apply(this,arguments);
};
}
/**
* Binds a method to the component.
*
* @param {object} component Component whose method is going to be bound.
// User is trying to bind() an autobound method; we effectively will
// ignore the value of "this" that the user is trying to use, so
// let's warn.
if(newThis!==component&&newThis!==null){
process.env.NODE_ENV!=='production'?warning(false,'bind(): React component methods may only be bound to the '+'component instance. See %s',componentName):void0;
}elseif(!args.length){
process.env.NODE_ENV!=='production'?warning(false,'bind(): You are binding a component method to the component. '+'React does this for you automatically in a high-performance '+'way, so you can safely remove this call. See %s',componentName):void0;
* Checks whether or not this composite component is mounted.
* @return {boolean} True if mounted, false otherwise.
* @protected
* @final
*/
isMounted:function(){
if(process.env.NODE_ENV!=='production'){
process.env.NODE_ENV!=='production'?warning(this.__didWarnIsMounted,'%s: isMounted is deprecated. Instead, make sure to clean up '+'subscriptions and pending requests in componentWillUnmount to '+'prevent memory leaks.',this.constructor&&this.constructor.displayName||this.name||'Component'):void0;
// This constructor gets overridden by mocks. The argument is used
// by mocks to assert on what gets mounted.
if(process.env.NODE_ENV!=='production'){
process.env.NODE_ENV!=='production'?warning(thisinstanceofConstructor,'Something is calling a React component directly. Use a factory or '+'JSX instead. See: https://fb.me/react-legacyfactory'):void0;
}
// Wire up auto-binding
if(this.__reactAutoBindPairs.length){
bindAutoBindMethods(this);
}
this.props=props;
this.context=context;
this.refs=emptyObject;
this.updater=updater||ReactNoopUpdateQueue;
this.state=null;
// ReactClasses doesn't have constructors. Instead, they use the
// getInitialState and componentWillMount methods for initialization.
// This is probably bad practice. Consider warning here and
// deprecating this convenience.
initialState=null;
}
}
_invariant(typeofinitialState==='object'&&!Array.isArray(initialState),'%s.getInitialState(): must return an object or null',Constructor.displayName||'ReactCompositeComponent');
_invariant(Constructor.prototype.render,'createClass(...): Class specification must implement a `render` method.');
if(process.env.NODE_ENV!=='production'){
process.env.NODE_ENV!=='production'?warning(!Constructor.prototype.componentShouldUpdate,'%s has a method called '+'componentShouldUpdate(). Did you mean shouldComponentUpdate()? '+'The name is phrased as a question because the function is '+'expected to return a value.',spec.displayName||'A component'):void0;
process.env.NODE_ENV!=='production'?warning(!Constructor.prototype.componentWillRecieveProps,'%s has a method called '+'componentWillRecieveProps(). Did you mean componentWillReceiveProps()?',spec.displayName||'A component'):void0;
}
// Reduce time spent doing lookups by setting these on the prototype.
// Prop type validation may throw. In case they do, we don't want to
// fail the render phase where it didn't fail before. So we log it.
// After these have been cleaned up, we'll let them throw.
try{
// This is intentionally an invariant that gets caught. It's the same
// behavior as without this statement except with a better message.
invariant(typeoftypeSpecs[typeSpecName]==='function','%s: %s type `%s` is invalid; it must be a function, usually from '+'React.PropTypes.',componentName||'React class',location,typeSpecName);
process.env.NODE_ENV!=='production'?warning(!error||errorinstanceofError,'%s: type specification of %s `%s` is invalid; the type checker '+'function must return `null` or an `Error` but returned a %s. '+'You may have forgotten to pass an argument to the type checker '+'creator (arrayOf, instanceOf, objectOf, oneOf, oneOfType, and '+'shape all require an argument).',componentName||'React class',location,typeSpecName,typeoferror):void0;
process.env.NODE_ENV!=='production'?warning(false,'You are manually calling a React.PropTypes validation '+'function for the `%s` prop on `%s`. This is deprecated '+'and will not work in production with the next major version. '+'You may be seeing this warning due to a third-party PropTypes '+'library. See https://fb.me/react-warning-dont-call-proptypes '+'for details.',propFullName,componentName):void0;
manualPropTypeCallCache[cacheKey]=true;
}
}
}
if(props[propName]==null){
if(isRequired){
if(props[propName]===null){
returnnewPropTypeError('The '+location+' `'+propFullName+'` is marked as required '+('in `'+componentName+'`, but its value is `null`.'));
}
returnnewPropTypeError('The '+location+' `'+propFullName+'` is marked as required in '+('`'+componentName+'`, but its value is `undefined`.'));
// `propValue` being instance of, say, date/regexp, pass the 'object'
// check, but we can offer a more precise error message here rather than
// 'of type `object`'.
varpreciseType=getPreciseType(propValue);
returnnewPropTypeError('Invalid '+location+' `'+propFullName+'` of type '+('`'+preciseType+'` supplied to `'+componentName+'`, expected ')+('`'+expectedType+'`.'));
returnnewPropTypeError('Invalid '+location+' `'+propFullName+'` of type '+('`'+propType+'` supplied to `'+componentName+'`, expected a single ReactElement.'));
returnnewPropTypeError('Invalid '+location+' `'+propFullName+'` of type '+('`'+actualClassName+'` supplied to `'+componentName+'`, expected ')+('instance of `'+expectedClassName+'`.'));
}
returnnull;
}
returncreateChainableTypeChecker(validate);
}
functioncreateEnumTypeChecker(expectedValues){
if(!Array.isArray(expectedValues)){
process.env.NODE_ENV!=='production'?warning(false,'Invalid argument supplied to oneOf, expected an instance of array.'):void0;
returnnewPropTypeError('Invalid '+location+' `'+propFullName+'` of value `'+propValue+'` '+('supplied to `'+componentName+'`, expected one of '+valuesString+'.'));
// when when somebody has screwed with setTimeout but no I.E. maddness
returncachedSetTimeout(fun,0);
}catch(e){
try{
// When we are in I.E. but the script has been evaled so I.E. doesn't trust the global object when called normally
returncachedSetTimeout.call(null,fun,0);
}catch(e){
// same as above but when it's a version of I.E. that must have the global object for 'this', hopfully our context correct otherwise it will throw a global error
returncachedSetTimeout.call(this,fun,0);
}
}
}
functionrunClearTimeout(marker){
if(cachedClearTimeout===clearTimeout){
//normal enviroments in sane situations
returnclearTimeout(marker);
}
// if clearTimeout wasn't available but was latter defined
// when when somebody has screwed with setTimeout but no I.E. maddness
returncachedClearTimeout(marker);
}catch(e){
try{
// When we are in I.E. but the script has been evaled so I.E. doesn't trust the global object when called normally
returncachedClearTimeout.call(null,marker);
}catch(e){
// same as above but when it's a version of I.E. that must have the global object for 'this', hopfully our context correct otherwise it will throw a global error.
// Some versions of I.E. have different rules for clearTimeout vs setTimeout
returncachedClearTimeout.call(this,marker);
}
}
}
varqueue=[];
vardraining=false;
varcurrentQueue;
varqueueIndex=-1;
functioncleanUpNextTick(){
if(!draining||!currentQueue){
return;
}
draining=false;
if(currentQueue.length){
queue=currentQueue.concat(queue);
}else{
queueIndex=-1;
}
if(queue.length){
drainQueue();
}
}
functiondrainQueue(){
if(draining){
return;
}
vartimeout=runTimeout(cleanUpNextTick);
draining=true;
varlen=queue.length;
while(len){
currentQueue=queue;
queue=[];
while(++queueIndex<len){
if(currentQueue){
currentQueue[queueIndex].run();
}
}
queueIndex=-1;
len=queue.length;
}
currentQueue=null;
draining=false;
runClearTimeout(timeout);
}
process.nextTick=function(fun){
varargs=newArray(arguments.length-1);
if(arguments.length>1){
for(vari=1;i<arguments.length;i++){
args[i-1]=arguments[i];
}
}
queue.push(newItem(fun,args));
if(queue.length===1&&!draining){
runTimeout(drainQueue);
}
};
// v8 likes predictible objects
functionItem(fun,array){
this.fun=fun;
this.array=array;
}
Item.prototype.run=function(){
this.fun.apply(null,this.array);
};
process.title='browser';
process.browser=true;
process.env={};
process.argv=[];
process.version='';// empty string to avoid regexp issues
process.versions={};
functionnoop(){}
process.on=noop;
process.addListener=noop;
process.once=noop;
process.off=noop;
process.removeListener=noop;
process.removeAllListeners=noop;
process.emit=noop;
process.binding=function(name){
thrownewError('process.binding is not supported');
};
process.cwd=function(){return'/'};
process.chdir=function(dir){
thrownewError('process.chdir is not supported');
};
process.umask=function(){return0;};
},{}],2:[function(require,module,exports){
(function(process){
/**
* Copyright 2015-present, Facebook, Inc.
* All rights reserved.
*
* This source code is licensed under the BSD-style license found in the
* LICENSE file in the root directory of this source tree. An additional grant
* of patent rights can be found in the PATENTS file in the same directory.
This package is deprecated and will no longer work with React 16+. We recommend you use `CSSTransitionGroup` from [`react-transition-group`](https://github.com/reactjs/react-transition-group) instead.
(function(f){if(typeofexports==="object"&&typeofmodule!=="undefined"){module.exports=f()}elseif(typeofdefine==="function"&&define.amd){define([],f)}else{varg;if(typeofwindow!=="undefined"){g=window}elseif(typeofglobal!=="undefined"){g=global}elseif(typeofself!=="undefined"){g=self}else{g=this}if(typeofg.React==="undefined"){throwError("React module should be required before PureRenderMixin")}elseif(typeofg.React.addons==="undefined"){g.React.addons={}}g.React.addons.PureRenderMixin=f()}})(function(){vardefine,module,exports;returnfunctione(t,n,r){functions(o,u){if(!n[o]){if(!t[o]){vara=typeofrequire=="function"&&require;if(!u&&a)returna(o,!0);if(i)returni(o,!0);varf=newError("Cannot find module '"+o+"'");throwf.code="MODULE_NOT_FOUND",f}varl=n[o]={exports:{}};t[o][0].call(l.exports,function(e){varn=t[o][1][e];returns(n?n:e)},l,l.exports,e,t,n,r)}returnn[o].exports}vari=typeofrequire=="function"&&require;for(varo=0;o<r.length;o++)s(r[o]);returns}({1:[function(require,module,exports){"use strict";varshallowEqual=require("fbjs/lib/shallowEqual");module.exports={shouldComponentUpdate:function(nextProps,nextState){return!shallowEqual(this.props,nextProps)||!shallowEqual(this.state,nextState)}}},{"fbjs/lib/shallowEqual":2}],2:[function(require,module,exports){"use strict";varhasOwnProperty=Object.prototype.hasOwnProperty;functionis(x,y){if(x===y){returnx!==0||y!==0||1/x===1/y}else{returnx!==x&&y!==y}}functionshallowEqual(objA,objB){if(is(objA,objB)){returntrue}if(typeofobjA!=="object"||objA===null||typeofobjB!=="object"||objB===null){returnfalse}varkeysA=Object.keys(objA);varkeysB=Object.keys(objB);if(keysA.length!==keysB.length){returnfalse}for(vari=0;i<keysA.length;i++){if(!hasOwnProperty.call(objB,keysA[i])||!is(objA[keysA[i]],objB[keysA[i]])){returnfalse}}returntrue}module.exports=shallowEqual},{}]},{},[1])(1)});
(function(f){if(typeofexports==="object"&&typeofmodule!=="undefined"){module.exports=f()}elseif(typeofdefine==="function"&&define.amd){define([],f)}else{varg;if(typeofwindow!=="undefined"){g=window}elseif(typeofglobal!=="undefined"){g=global}elseif(typeofself!=="undefined"){g=self}else{g=this}if(typeofg.React==="undefined"){throwError("React module should be required before shallowCompare")}elseif(typeofg.React.addons==="undefined"){g.React.addons={}}g.React.addons.shallowCompare=f()}})(function(){vardefine,module,exports;returnfunctione(t,n,r){functions(o,u){if(!n[o]){if(!t[o]){vara=typeofrequire=="function"&&require;if(!u&&a)returna(o,!0);if(i)returni(o,!0);varf=newError("Cannot find module '"+o+"'");throwf.code="MODULE_NOT_FOUND",f}varl=n[o]={exports:{}};t[o][0].call(l.exports,function(e){varn=t[o][1][e];returns(n?n:e)},l,l.exports,e,t,n,r)}returnn[o].exports}vari=typeofrequire=="function"&&require;for(varo=0;o<r.length;o++)s(r[o]);returns}({1:[function(require,module,exports){"use strict";varhasOwnProperty=Object.prototype.hasOwnProperty;functionis(x,y){if(x===y){returnx!==0||y!==0||1/x===1/y}else{returnx!==x&&y!==y}}functionshallowEqual(objA,objB){if(is(objA,objB)){returntrue}if(typeofobjA!=="object"||objA===null||typeofobjB!=="object"||objB===null){returnfalse}varkeysA=Object.keys(objA);varkeysB=Object.keys(objB);if(keysA.length!==keysB.length){returnfalse}for(vari=0;i<keysA.length;i++){if(!hasOwnProperty.call(objB,keysA[i])||!is(objA[keysA[i]],objB[keysA[i]])){returnfalse}}returntrue}functionshallowCompare(instance,nextProps,nextState){return!shallowEqual(instance.props,nextProps)||!shallowEqual(instance.state,nextState)}module.exports=shallowCompare},{}]},{},[1])(1)});
This package is deprecated and will no longer work with React 16+. We recommend you use `TransitionGroup` from [`react-transition-group`](https://github.com/reactjs/react-transition-group) instead.
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.