React Riot is the first online worldwide hackathon for React! No cost to enter and teams can win some cool prizes. It's a community event to build the best React app in 48 hours.
* 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
Sakina Crocker
Victoria Quirante
Dan Abramov
Flarnie Marchan
Sebastian Markbåge
Brian Vaughn
Kurt Furbush
Garmash Nikolay
Ben Alpert
Arthur Gunn
Fernando Montoya
Lipis
Ricardo
cjshawMIT
António Nuno Monteiro
Edvin Erikson
Dustan Kasten
Nathan Hunzaker
Timothy Yung
Dan Abramov
Dominic Gannaway
Erik Hellman