* 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.
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.
"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."
- Reverts change to use sectionid on layouts (was unreliable), using config to make sure that's specified on all pages that need it
- Adds permalinks to all other pages so that og data is correct
- Corrects some permalinks that were in correct (translations)
* 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
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.
Paul O’Shannessy
Dan Abramov
Dustan Kasten
Keyan Zhang
Cheng Lou
Jackson Huang
Ben Alpert
Patrick Finnigan
Gert Hengeveld
Amjad Masad
scloudyy
Veljko Tornjanski
Keyan Zhang
Nathan Hunzaker
Seyi
Steven Syrek
Alex Zherdev
Daniel Lo Nigro
Sassan Haradji
Fernando Alex Helwanger
Troy DeMonbreun
segmentationfaulter
Mert Kahyaoğlu
Brandon Dail
Kent C. Dodds