* Add check for string and null 'rootElement' in ReactDOMFiber
**what is the change?:**
Before we call 'rootElement.getAttribute' we check that the method is
defined.
**why make this change?:**
There is an internal use case I found where 'rootElement' is a string
and null at different points as the page is rendered.
It looks like this method was added as part of support for re-hydration
of server-side rendered content. I can't imagine we would want to reuse
content if the rootnode is a string or null. Not sure if we want an
earlier check that it's an element before this point.
**test plan:**
`yarn test`
and I manually tested this fix in the internal case where it was
breaking
* Add test and improve check for non-element rootElement
**what is the change?:**
We use the nodeType to check that we have the correct type of
rootElement, and we added a unit test.
**why make this change?:**
Improve this solution to the problem.
**test plan:**
`yarn test`
* run ./scripts/fiber/record-tests
* Don't hydrate any properties other than event listeners and text content
This strategy assumes that the rendered HTML is correct if the tree lines
up. Therefore we don't diff any attributes of the rendered HTML.
However, as a precaution I ensure that textContent *is* updated. This
ensures that if something goes wrong with keys lining up etc. at least
there is some feedback that the event handlers might not line up. With
what you expect. This might not be what you want e.g. for date formatting
where it can different between server and client.
It is expected that content will line up. To ensure that I will in a follow
up ensure that the warning is issued if it doesn't line up so that in
development this can be addressed.
The text content updates are now moved to the commit phase so if the tree
is asynchronously hydrated it doesn't start partially swapping out. I use
the regular update side-effect with payload if the content doesn't match up.
Since we no longer guarantee that attributes is correct I changed the
bad mark up SSR integration tests to only assert on the textContent
instead.
* Hydrate text node if possible
Currently we're never matching text nodes so we need to properly branch.
* Tweak syntax in rollup build script
@bvaughn and I already discussed this.
**test plan:**
`yarn build`
* Remove JSDoc comments
**what is the change?:**
removing some comments
**why make this change?:**
The code is basically self explanatory and these comments could get out
of sync.
**test plan:**
Visual inspection, `yarn build` and `yarn test`
**issue:**
https://github.com/facebook/react/issues/9398
According to #9836 we're intentionally chosing to not support this until
we have better proof of this being a big need. E.g. to protect against
extensions. In a way that it's not better to push extensions to be fixed.
* Avoid adding trailing semicolons to inline styles.
* Prettify.
* For sake of performance, avoid messing around with arrays.
* Change approach to avoid calling .substring.
While reading the page, the "chain of thought" is broken by stating that the `tempertature` and `onTemperatureChange` don't have any special meaning. Making this a blockquote makes that note look more like a comment and keep the "chain of thought" intact.
* bump flow to 0.47
* Fix variadic function flow issues in fiber
* Fix variadic function flow issues in ReactFiberNative
* fix ReactDOM type issues with flow 0.47
* getChildHostContext *does* take an `instance` argument
* change recently added anys to mixedies
* HydrationContext needs a handle on the rootContainerInstance
* prettier
This was mostly used for timing of initial mounts. However, we haven't
implemented that in Fiber and yet nobody has complained despite running
without it. Further more the update tracks any update within the tree,
not just updates to the props of the top level. This is much less useful
due to the variation.
I could make this track initial mounts too but it's a bit awkward so I'd
rather just delete it if possible. We can run the full profiling mode if
we want more coverage.
* Update CHANGELOG for unreleased 15.6 branch
**what is the change?:**
Added entries for the latest changes.
**why make this change?:**
We are about to do an RC release and folks can look at these notes to
see what is in the planned release.
**test plan:**
Visual inspection
**issue:**
https://github.com/facebook/react/issues/9398
* Update changelog regarding `createClass` dep. warning
**what is the change?:**
We decided to strike through the previous changelog item and add it to
the more recent changelog section, since this is the release where the
deprecation warning will actually go out.
**why make this change?:**
To make things clear for everyone using 15.6
**test plan:**
Visual inspection
**issue:**
https://github.com/facebook/react/issues/9398
This creates `ReactNativeComponent`, the modern replacement for `NativeMethodsMixin`.
This class is going to allow us to start migrating React Native off `React.createClass(...)` into a typesafe, class-based brave new world.
This also introduces `IReactNativeComponent`, an interface that enforces consistency between `ReactNativeComponent` and `ReactNativeFiberHostComponent`.
This is a follow-up on
https://github.com/facebook/react/pull/9584#discussion_r115642293. There
is no need to assign the value property of an input if the value
property of the React component changes types, but stringifies to the
same value. For example:
```javascript
DOM.render(<input value="true" />, el)
DOM.render(<input value={true} />, el)
```
In this case, the assignment to `input.value` will always be
cast to the string "true". There is no need to perform this
assignment. Particularly when we already cast the value to a string
later:
```javascript
// Cast `value` to a string to ensure the value is set correctly. While
// browsers typically do this as necessary, jsdom doesn't.
node.value = '' + value;
```
This isn't necessarily what we want long-term especially with more async, but currently we crash in jsdom in some cases when an img load event gets dispatched synchronously. (Needed for FB-internal D5060180.)
**what is the change?:**
- Add two more special cases for 'lowPriorityWarning' in 'modules.js',
treating it the same as 'ReactCurrentOwner'.
**why make this change?:**
Without this, the build was including 'lowPriorityWarning' seemingly both as an external module and as part of the bundle.
**test plan:**
Ran `yarn build` and inspected the `React-dev` build. `lowPriorityWarning` did not get bundled in this time.
**issue:**
None yet - @gaearon flagged this for me directly.
* Add back caught error and other checks to 'lowPriorityWarning'
**what is the change?:**
This change makes 'lowPriorityWarning' an exact copy of 'warning.js' from
https://github.com/facebook/fbjs/blob/e66ba20ad5be433eb54423f2b097d829324d9de6/packages/fbjs/src/__forks__/warning.js
where before we had skipped some checks from that module.
- Adds an error which we catch, in order to let people find the error and resulting stack trace when using devtools with 'pause on caught errors' checked.
- Adds check that 'format' argument is passed
**why make this change?:**
- To maintain a closer fork to 'warning.js'
- To allow easier debugging using 'pause on caught errors'
- To validate inputs to 'lowPriorityWarning'
**test plan:**
`yarn test`
**issue:**
* Update 'print-warnings' script to include 'lowPriorityWarning' output
**what is the change?:**
We print the logs from 'lowPriorityWarning' as well as 'warning' from the 'print-warnings' script.
NOTE: This PR is branching off of https://github.com/facebook/react/pull/9754
**why make this change?:**
We want to use the same process of white/blacklisting warnings with 'lowPriorityWarning' that we do with 'warning'.
**test plan:**
This is not super easy to test unless we are doing a sync with FB afaik. I plan on running a sync in the next few days, or next week at latest, for the sake of not landing big things on a Friday. That will be the actual test of this.
**issue:**
https://github.com/facebook/react/issues/9398
* Add 'Test Utils' docs back to main navigation
**why make this change?:**
We accidentally removed this - still supporting the use of Test Utilities, so we should have them in the docs.
**test plan:**
Manually tested the website - will insert a screenshot.
**issue:**
https://github.com/facebook/react/issues/9651
* Move test-utils docs to reference section
**what is the change?:**
Moved from 'advanced guides' to 'reference'
**why make this change?:**
It makes more sense as a reference
**test plan:**
Visual inspection (flarnie may add a screenshot)
**issue:**
* Add back the shallow renderer docs and remove outdated docs
**what is the change?:**
- Remove outdated 'shallow renderer' docs on 'test utils' page, and point to the updated 'shallow renderer' docs.
- Re-add a link to the updated 'shallow renderer' docs on the main navigation.
**why make this change?:**
This was already approved in https://github.com/facebook/react/pull/9331 which was then cherry-picked to https://github.com/facebook/react/pull/9359/commits and landed on master.
I'm not sure why some of these changes didn't persist. For now just adding back the changes we need.
**test plan:**
Manually inspected website - will insert screenshots.
**issue:**
* Further improvements to 'shallow rendering' and 'test utils' docs
Thanks @gaearon for the improvements!
**what is the change?:**
- Remove <hr/> from end of 'shallow rendering' docs
- 'documents' -> 'documentation'
- Move 'shallow rendering' redirection section to top of 'test utils' docs
- Add intro sentence about testing to 'shallow rendering' docs
**why make this change?:**
Documentation helps people learn.
**test plan:**
Visual inspection
* Update 2015-12-16-ismounted-antipattern.md
In case anybody else stumbles across this old blog post, I wanted to submit a patch to help with unhandled rejections.
`#then` and `#catch` each return new Promise instances, so here we actually create two new promises (that aren't assigned). If the argument promise to `#makeCancelable` rejects, the promise created by `#then` will be an unhandled rejection, which in Node 7 will be an uncaught error.
By using the second argument of `#then` to handle rejections instead, we don't need to worry about the runtime finding any unhandled rejections here.
* Style updates
* Add update notice
* Don't double validate the DOM container
The warnings need to check a valid container but that should happen in
unstable_renderSubtreeIntoContainer too so might as well move it in.
* Hydrating DOM
Hydrates a server-rendered DOM tree by traversing it and connecting up the nodes if they match. Attributes are not diffed. They're assumed to be accurate on matching nodes.
* Remove meta data filtering from test
Because the current server renderer includes the meta data, it remains in a revived tree.
* Annotate because Flow
* Don't track insertion effects if we're going to hydrate
During initial mount, we should not track Placement
* Fix up test cases to ignore errors that we no longer throw
TODO make these warnings instead.
* Correctly track hydration state inside a newly inserted tree
When we don't match the first hydration node, we'll do an insertion.
Currently we keep the next hydratable sibling so that we know where to
pick up once we're done with the insertion. Unfortunately this makes the
nodes inside the insertion think that there's a node to hydrate.
I used to check for the direct parent but that doesn't work on nested host components.
We need to instead keep track of that we're in an hydration context but
we're not currently hydrating. Once we pop passed the inserted node can
we resume hydrating.
* Hacky fix to isMounted
isMounted checks whether a component is inside a Placement. During
hydration we ideally don't do any Placements if hydration matches the tree.
To work around this I use the Placement flag on the root, which isn't used
for anything else. But only temporarily while we're hydrating. Then reset
it before committing.
* Record tests
* Comments
