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.