Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49262
Changelog: [General][Breaking] Deep imports into `react-native/virtualized-lists` with require syntax may need to be appended with `.default`
Reviewed By: huntie
Differential Revision: D69308532
fbshipit-source-id: 6de15d46e0931616bc9849edbccb7cf745e15dd5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48975
After cutting 0.78-stable, we need to bump the monorepo packages to `0.79.0-main`
## Changelog:
[Internal] - Bump monorepo packages to `0.79.0-main`
Reviewed By: cortinico, huntie
Differential Revision: D68715005
fbshipit-source-id: cb5abbf05e8638683687be8d61d66b3037111572
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48819
Currently, `VirtualizedList-test.js` has a subtle dependency on how asynchronous operations are queued. Specifically, it depends on...
- `Batchinator` to use `setTimeout` for...
- `InteractionManager` to use `setImmediate` for...
- `InteractionManager` to resolve a promise via microtask.
As a consequence, any changes to this queueing logic (e.g. eliminating the unnecessary `setImmediate` and microtask) unnecessarily breaks these unit tests.
This changes the Jest unit tests to instead use `jest. advanceTimersToNextTimer(<step>)` instead of `jest.runOnlyPendingTimers()` so that the unit tests are no longer dependent on these specific queueing logic.
Changelog:
[Internal]
Reviewed By: NickGerleman
Differential Revision: D68449850
fbshipit-source-id: 382b1c0a0d8fade873ccf17a9deb3622a83b8163
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48292
These dependencies are making the CI on main to fail.
## Changelog:
[General][Fixed] - Fix peer dependencies on React types
Reviewed By: javache, hoxyq
Differential Revision: D67283609
fbshipit-source-id: b325246f5de654a9ccbf7f96eec24434047a38ee
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47965
Changelog: [General] [Changed] - fix item disappearing with scroll in VirtualizedList
It was caused because the function `computeWindowedRenderLimits` collapsed the current window size to just 1 element. So, users start scroll current window increase from {left:0, right:5 } -> {left:0, right:6 } and after some edge cases the window collapsed to `{left:6, right:6 }` which cause to remove all elements and recreate them later. As a result users have a lot of lags and blank pages.
The diff fixes the collapsing window size to 1 element. Also fix other decreasing `left` position even if windowSize more than current amount of elements.
Reviewed By: NickGerleman
Differential Revision: D66334188
fbshipit-source-id: 2162d00d03d64ab6325c0492d87449051e68a4e9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47690
Creates a feature flag to evalute the impact of disabling `InteractionManager` in `Batchinator` and synchronously invoking callbacks after the timeout.
This also deletes the `dispose` arguments in `Batchinator` that were unused.
Changelog:
[Internal]
Reviewed By: bvanderhoof
Differential Revision: D66139643
fbshipit-source-id: d17bab0cd25c0c69779686cb435c063f707255e4
Summary:
While we're waiting for 19 stable, let's bring main back to 18.3.1 ahead of the 0.77 branch cut. We'll land this change just after 19 stable lands.
This is a cherry pick of b93b378fa0 which landed in 0.76 already
bypass-github-export-checks
## Changelog:
[INTERNAL] - Revert React 19RC to React 18.3.1
Pull Request resolved: https://github.com/facebook/react-native/pull/47380
Test Plan: CI
Reviewed By: cipolleschi
Differential Revision: D65430775
Pulled By: cortinico
fbshipit-source-id: f0f211754c8ffe5d037fd299e4de52c29d1d7913
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47463
Note this is just a temporary approach which will be cleaned up later.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D65514902
fbshipit-source-id: f722031c5cd34eb1400b3f732fd94c0b03d5434d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47340
This diff cleans up some problematic `React.ElementRef<T>` when T is generic type.
Changelog: [Internal]
Reviewed By: alexmckenley
Differential Revision: D65280467
fbshipit-source-id: 71172b16320a10cbc7a8b46dae5d3dd0eb00ba0c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47109
Fixes the `lint/sort-imports` errors that are now surfaced after fixing the lint configuration.
For a couple files, I added lint suppressions instead because the unsorted import ordering is important due to interleaved calls with side effects.
Changelog:
[Internal]
Reviewed By: GijsWeterings
Differential Revision: D64569485
fbshipit-source-id: 26415d792e2b9efe08c05d1436f723faae549882
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46990
This is a reattempt land D63643856 to fix the scroll onendreached event not firing.
Changelog:
[General][Fixed] - Fix onEndReached not being called when getItemLayout is present and we scroll past render window
Reviewed By: NickGerleman
Differential Revision: D64222424
fbshipit-source-id: 7e22f377d2f754beb39fff2b5c097cea350daa7e
Summary:
This diff reverts D63643856
`_highestMeasuredFrameIndex` is not properly invalidated causing issues with previous logic when data size shrinks.
bypass-github-export-checks
Changelog:
[General][Changed] - Revert "Fix onEndReached not being called when getItemLayout is present and we scroll past render window"
Reviewed By: NickGerleman
Differential Revision: D64009287
fbshipit-source-id: 8a21b57f5247fc743e65f9a730ff33a9a89d2bc1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46736
Copying the comment in code:
> We only call `onEndReached` after we render the last cell, but when getItemLayout is present, we can scroll past the last rendered cell, and never trigger a new layout or bounds change, so we need to check again after rendering more cells.
Changelog:
[General][Fixed] - Fix onEndReached not being called when getItemLayout is present and we scroll past render window
Reviewed By: yungsters
Differential Revision: D63643856
fbshipit-source-id: 9c53789cb15b225ceac353c37cbb67f7beeaf4fb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46487
Changelog: [General][Fixed] Fixed accuracy of FlatList estimations to determine what elements are visible in the rendering window.
This fixes a bug in FlatList where it thinks that some elements are visible in the rendering window, when they're not. Specifically, if a cell hasn't been laid out yet, it ignores all the information it already has on the ones that had, and estimates its position and offset based on the estimated size of the cells. In this case, if the first element has a larger offset because the list has a header, that offset is ignored in this case.
One observed result of this is that in a list where there's a header and a single cell that occupy the whole rendering window, FlatList thinks it needs to pre-render an additional element because the header is ignored.
Reviewed By: NickGerleman
Differential Revision: D62649060
fbshipit-source-id: 437bae79916707ca1d08784190508a9f7e36688e
Summary:
This change bumps the React Native version in main to 0.77
bypass-github-export-checks
## Changelog:
[General][Changed] - Bump main to 0.77-main
## Facebook:
generated by running `js1 publish react-native 0.77.0-main`
Reviewed By: cortinico
Differential Revision: D62575939
fbshipit-source-id: 6d239fca2eed6cfe51f8c37f78d8dc8730c18b8c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46103
Reducing the boundary of rerender of virtual lists. Previously with prop: "strictMode={true}" the VirtualizedList still re rendered each CellRenderer component. Because method getDerivedStateFromProps generated every time a new uniq state and the cells didn’t have a PureComponent. It helps to improve react performance for lists which have 5+ elements.
I reused recomended approach from react doc https://legacy.reactjs.org/blog/2018/06/07/you-probably-dont-need-derived-state.html#what-about-memoization
changelog: [internal]
Optimizing CellRenderer of VirtualizedList
Reviewed By: NickGerleman, sammy-SC
Differential Revision: D61493434
fbshipit-source-id: 917a33e48bd2f18e8ac150e5701d2e7c45dbe879
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45998
The exact `React.Element` type is deprecated and will be removed in a future version of Flow.
Changelog: [Internal]
Reviewed By: gkz
Differential Revision: D61205640
fbshipit-source-id: a029a3a46c7d8d9f94b0b931b991b2ce461151b2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45904
Flow will error on these dollar types soon. For all the ones changed here, they can all be further simplified.
Changelog: [Internal]
Reviewed By: gkz
Differential Revision: D60786768
fbshipit-source-id: e26bf0be1c4a933fc0bd8b59827e10cbd7242a83
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44990
Upgrades React Native and Relay to depend on React 19, which is currently published as release candidates. This is in preparation for React Native 0.75.
This will depend on updating open source renderers after [facebook/react#29903](https://github.com/facebook/react/pull/29903) is merged.
Changelog:
[General][Changed] - Upgrade to React 19
Reviewed By: robhogan
Differential Revision: D58625271
fbshipit-source-id: f9ad95b18716a9ce02f7cfbcc7248bdfb244c010
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45002
There are a couple Jest unit test cases for `VirtualizedList-test.js` that require further investigation.
We believe that these are problems with Jest fake timers in the test and not with the component itself, so for now let's skip them so as to unblock the upgrade to React 19.
Changelog:
[Internal]
Reviewed By: robhogan
Differential Revision: D58656948
fbshipit-source-id: d52f3ad8277def6eae20cbbc11751d73b769d929
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44997
Wrap `VirtualizedList-test` uses of `react-test-renderer` in `act` as appropriate, so as to pass under current React and mostly pass under React 19, with further fixes to come.
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D58649295
fbshipit-source-id: 5e0fa791d581fbf004a2ca7eaa5c4b4d9a15ddfe
Summary:
Migrate `VirtualizedSectionList-test` to use `act`-wrapping in prepation for React 19.
Avoid the `react-native/jest/renderer` abstractions as this is a separate package.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D58653558
fbshipit-source-id: 0e19fff5c3998fb00b71c3d07100a2064682cb4c
Summary:
Stacked on top of #28498 for test fixes.
### Don't Rethrow
When we started React it was 1:1 setState calls a series of renders and
if they error, it errors where the setState was called. Simple. However,
then batching came and the error actually got thrown somewhere else.
With concurrent mode, it's not even possible to get setState itself to
throw anymore.
In fact, all APIs that can rethrow out of React are executed either at
the root of the scheduler or inside a DOM event handler.
If you throw inside a React.startTransition callback that's sync, then
that will bubble out of the startTransition but if you throw inside an
async callback or a useTransition we now need to handle it at the hook
site. So in 19 we need to make all React.startTransition swallow the
error (and report them to reportError).
The only one remaining that can throw is flushSync but it doesn't really
make sense for it to throw at the callsite neither because batching.
Just because something rendered in this flush doesn't mean it was
rendered due to what was just scheduled and doesn't mean that it should
abort any of the remaining code afterwards. setState is fire and forget.
It's send an instruction elsewhere, it's not part of the current
imperative code.
Error boundaries never rethrow. Since you should really always have
error boundaries, most of the time, it wouldn't rethrow anyway.
Rethrowing also actually currently drops errors on the floor since we
can only rethrow the first error, so to avoid that we'd need to call
reportError anyway. This happens in RN events.
The other issue with rethrowing is that it logs an extra console.error.
Since we're not sure that user code will actually log it anywhere we
still log it too just like we do with errors inside error boundaries
which leads all of these to log twice.
The goal of this PR is to never rethrow out of React instead, errors
outside of error boundaries get logged to reportError. Event system
errors too.
### Breaking Changes
The main thing this affects is testing where you want to inspect the
errors thrown. To make it easier to port, if you're inside `act` we
track the error into act in an aggregate error and then rethrow it at
the root of `act`. Unlike before though, if you flush synchronously
inside of act it'll still continue until the end of act before
rethrowing.
I expect most user code breakages would be to migrate from `flushSync`
to `act` if you assert on throwing.
However, in the React repo we also have `internalAct` and the
`waitForThrow` helpers. Since these have to use public production
implementations we track these using the global onerror or process
uncaughtException. Unlike regular act, includes both event handler
errors and onRecoverableError by default too. Not just render/commit
errors. So I had to account for that in our tests.
We restore logging an extra log for uncaught errors after the main log
with the component stack in it. We use `console.warn`. This is not yet
ignorable if you preventDefault to the main error event. To avoid
confusion if you don't end up logging the error to console I just added
`An error occurred`.
### Polyfill
All browsers we support really supports `reportError` but not all test
and server environments do, so I implemented a polyfill for browser and
node in `shared/reportGlobalError`. I don't love that this is included
in all builds and gets duplicated into isomorphic even though it's not
actually needed in production. Maybe in the future we can require a
polyfill for this.
### Follow Ups
In a follow up, I'll make caught vs uncaught error handling be
configurable too.
---------
DiffTrain build for commit https://github.com/facebook/react/commit/6786563f3cbbc9b16d5a8187207b5bd904386e53.
Changelog:
[Internal]
Reviewed By: kassens
Differential Revision: D55408481
Pulled By: yungsters
fbshipit-source-id: 598aa306369e21cb3e93ad6041a87bfbaa9eef9e
Co-authored-by: Ricky Hanlon <rickhanlonii@gmail.com>
Summary:
Now that RN is providing TS type information, many of those .d.ts files depend on types from react. In modern packagemanagers (Ex: pnpm) types/react will not be available to RN since it does not declare it as a dependency.
I also noticed that the types for react-native-popup-menu-android appear to be pointing to the wrong location.
Add types/react as a peerDependency on the packages that have .d.ts files that import from React.
Add types/react to peerDependencyMeta with optional:true to prevent users not using TS from requiring types/react.
## Changelog:
[GENERAL] [ADDED] Added types/react as an optional peerDependency
Pull Request resolved: https://github.com/facebook/react-native/pull/43509
Reviewed By: cortinico
Differential Revision: D55225940
Pulled By: NickGerleman
fbshipit-source-id: 4cbab071928cb925baec45f55461559acc9a54e6
Summary:
Minor fix to package.json which newer version of npm warn about when publishing, after running `npm pkg fix -ws` on the workspace.
{F1470070110}
## Changelog: [Internal] npm pkg fix -ws
Pull Request resolved: https://github.com/facebook/react-native/pull/43519
Test Plan: eyescloseddog
Reviewed By: cortinico
Differential Revision: D55012872
Pulled By: blakef
fbshipit-source-id: ff3c63a3eefaf56d369219a3d4b32d44d6d842c9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43458
The React sync in D54783723 was failing because some tests were relying on `console.error` being called as `console.error('Some message')` but it was refactored as `console.error('%s..', 'Some message')`, making them fail.
This fixes the tests by formatting the arguments passed to the console functions and checking against that instead.
Changelog: [internal]
Reviewed By: sammy-SC
Differential Revision: D54849485
fbshipit-source-id: 0648263614725ea3f9c95b9f9bb13005adae46eb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43377
Fixes `VirtualizedList-test.js`, which assumes fake timers (e.g. using `jest.runAllTimers()` and `jest.runOnlyPendingTimers()`) but did not actually use fake timers.
Changelog:
[Internal]
Reviewed By: yungsters
Differential Revision: D54668281
fbshipit-source-id: b14757744bb7a21a4e5573053549c36178826021
Summary:
In setups with `pnpm` `react-native/virtualized-lists` gets bundled incorrectly because of the following error:
`Module not found: Error: Can't resolve 'react'`
As 'react' is used inside of the package, it should declared explicitly, instead of being a phantom dependency.
## Changelog:
[GENERAL] [FIXED] - Declare missing peer dependency `react`
Pull Request resolved: https://github.com/facebook/react-native/pull/42947
Test Plan: not needed
Reviewed By: NickGerleman
Differential Revision: D53617462
Pulled By: cortinico
fbshipit-source-id: 19a8fed94263646b0af93339d5c014e629dfa6b1
Jakub Piasecki
Riccardo Cipolleschi
Tim Yung
Dawid Małecki
Sam Zhou
Andrei Marchenko
Nicola Corti
Liron Yahdav
YunPeng Chong
generatedunixname89002005232357
Nick Gerleman
Rubén Norte
Blake Friedman
Alex Hunt
Rob Hogan
Fabrizio Cucci
sebmarkbage
Andrew Coates
Rick Hanlon
Biki-das
Jakub Romanczyk
