this was a surprise to me because the docs seemed to indicate that when
using an updater, the result _needed_ to be a new state object. I was
[not alone](https://twitter.com/ken_wheeler/status/857939690191806464)
i think in discovering this as a result of the previous tweet in the
thread.
* Add guide on integrating with non-react code
* Capitalize guide title
* Make links to other docs relative
* Rephrase 'What it does do'
* Remove experimental syntax
* Capitalize Backbone
* Remove empty lifecycle method in generic jQuery example
* Use shouldComponentUpdate() not componentWillUpdate()
* Prefer single quotes
* Add cleanup to generic jQuery example
* Capitalize React
* Generalize the section on Backbone Views
* Generalize the section on Backbone Models, a little
* Add introduction
* Adjust wording
* Simplify ref callbacks
* Fix typo in generic jQuery example
* Fix typos in Backbone models in React components
* Fix more typos in Backbone models in React components
* Add generic section on integrating with other view libraries
* Stress the benefits of an unchanging React element
* Small changes to introduction
* Add missing semicolon
* Revise generic jQuery wrapper section
Moved the section on using empty elements to prevent conflicts above the
code example and added brief introduction to that example.
* Add usage example for Chosen wrapper
* Prevent Chosen wrapper from updating
* Note that sharing the DOM with plugins is not recommended
* Mention how React is used at Facebook
* Mention React event system in template rendering section
* Remove destructuring from function parameters
* Do not name React components Component
* Elaborate on unmountComponentAtNode()
* Mention preference for unidirectional data flow
* Rename backboneModelAdapter
* Replace rest syntax
* Respond to updated model in connectToBackboneModel
* Rewrite connectToBackboneModel example
* Rework connectToBackboneModel example
* Misc changes
* Misc changes
* Change wording
* Tweak some parts
* Add reference to the Hyperscript libraries
I feel these should be mentioned as they provide terser syntax than using `R.createElement` directly, even with a shorthand.
* Rephrase
- Update examples to no longer use React.DOM
- Add package and documentation entries for react-addons-dom-factories
- Update dom-factories readme
- Set up proxy to intercept React.DOM usage
- Update ReactDOM children tests to use createElement
- Add more specific warning assertion for React DOM factories
- Do not use expectDev in ReactDOMFactories tests
* [Docs: Installation] Fix tabs responsive layout
* Move tabs a pixel down
* Remove left margin on first tab
* Remove the long line
* Fix mobile styles
* Add tabs to installation page (#9275, #9277)
This adds tabs for create-react-app and existing apps to the installation section of the docs. The tab implementation is a simplified version of React Native's installation page.
Fixes#9275.
* Use classList instead of className
* Use same implementation as in RN
* Clarification of setState() behavior
`setState()` is a frequent source of confusion for people new to React, and I believe part of that is due to minimization of the impact of the asynchronous behavior of `setState()` in the documentation. This revision is an attempt to clarify that behavior. For motivation and justification, see [setState Gate](https://medium.com/javascript-scene/setstate-gate-abc10a9b2d82).
* Update reference-react-component.md
* Signature fix
* Update to address @acdlite concerns
* Add more details
* 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!
* 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
* 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
* 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
* Add onToggle event to details tag
Fixes#8761
* Map onToggle event on ReactDOMFiberComponent
* Tweak doc
* Trap events on setInitialProperties for details tag
* 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
Addy Osmani
Dan Abramov
Marcos Ojeda
wacii
chocolateboy
Dmitri Zaitsev
Frankie Bagnardi
Nathan Hunzaker
David Hu
Almero Steyn
Filip Hoško
Jayen Ashar
Fraser Haer
NE-SmallTown
Marks Polakovs
Eric Elliott
hanumanthan
Dominic Gannaway
Denis Pismenny
Aaron Ackerman
Flarnie Marchan
Ben Alpert
Aaron Cannon
Damian Nicholson
Johan Tinglöf
CodinCat
Dima Beznos
Sunny Ripert
Vesa Laakso
Stephie
Roman Matusevich
DanZeuss
Jiminikiz
Moacir Rosa
Dhyey Thakore
KB
Dmitry Zhuravlev-Nevsky
Diego Muracciole
Omid Hezaveh
Vladimir Kovpak
MICHAEL JACKSON