[Android/Fabric] setPageWithoutAnimation from useLayoutEffect is ignored when targeting a newly added page
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 1-2 días
- Aptitud para principiantes
- 58/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- android, react-native, typescript
- Área
- mobile
Línea de trabajo
Start with the reproduction source’s App.tsx and the Android implementation of PagerView’s setPageWithoutAnimation command; trace how the command is handled when children are added. Compare the reported retry behavior with the command-only deferred patch in the archive. Done means the first request selects page D after adding pages, without a retry, and the existing pager behavior remains intact.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Description
Calling setPageWithoutAnimation(3) from useLayoutEffect immediately after expanding the pager from one page to four can leave the pager on page 0.
I reproduced this on a physical Android device using a standalone app with synthetic pages. The pager remains on page A for more than five seconds after requesting page D. Repeating the same command afterward switches to D successfully.
Environment
- react-native-pager-view: 9.0.7
- React Native: 0.88.0
- React: 19.3.0
- Architecture: Fabric
- Device: V2509A, physical device, arm64-v8a
- Android: 16 / API 36
- Build: Android debug native build with bundled JS (
dev=false), developer support disabled, no Metro connection
The baseline uses pager-view 9.0.7 with diagnostic logging only, without behavior-changing pager patches.
Steps to reproduce
- Render a
PagerViewcontaining only page A, withinitialPage={0}. - Wait for a nonzero layout and the initial
onPageSelectedevent reporting index 0. - Press Add pages & select D. This appends pages B, C, and D.
- In the
useLayoutEffectassociated with that update, callsetPageWithoutAnimation(3). - Observe that the pager remains on A.
- Wait several seconds, then press Retry select D, which repeats the same command without changing the children.
- The pager now switches to D and reports index 3.
The relevant update logic is:
const pager = useRef<PagerView>(null);
const [count, setCount] = useState(1);
useLayoutEffect(() => {
if (count === 4) {
pager.current?.setPageWithoutAnimation(3);
}
}, [count]);
// "Add pages & select D"
setCount(4);
// "Retry select D"
pager.current?.setPageWithoutAnimation(3);
The rendered children are PAGES.slice(0, count), with stable keys and collapsable={false}. The pager has a fixed positive height. No artificial mounting delays are introduced.
Expected behavior
The command selects the newly added page D once the corresponding child update has mounted, without requiring another command.
Actual behavior and device recording
https://github.com/user-attachments/assets/e859a058-98a2-4598-9d10-8374c806d5b8
In the baseline recording:
- At approximately 3.10 seconds, the React child count becomes 4 and the requested index is 3 (D), but the visible page and last
onPageSelectedvalue remain A / 0. - This mismatch persists for approximately 5.5 seconds.
- After pressing Retry select D, the visible page changes to D at approximately 8.58 seconds, and
onPageSelectedreports index 3 at approximately 8.60 seconds.
The “React children” counter reflects the React render state; it does not measure the number of children already mounted natively.
Command-only comparison
https://github.com/user-attachments/assets/77a4eb37-794d-4da9-ba99-dcec21c77830
I also tested a local change that defers command processing with View.post and validates the target index when the deferred command runs.
With that change, the same operation on the same device reaches D without pressing Retry. The comparison does not include measurement, page identity, or reattachment changes.
This supports a possible command-versus-child-mount timing issue. However, I could not obtain useful native logs from the device, so the exact native dispatch order has not been directly confirmed. The comparison demonstrates a fix for this reproduction, rather than establishing a complete solution for all command-ordering cases.
These recordings specifically test setPageWithoutAnimation; animated setPage was not tested on the device.
Reproduction source
The archive includes the tested App.tsx, build instructions, and the command-only comparison patch. Its README documents the build setup and verification scope.
- Lenguaje dominante
- TypeScript
- Estrellas
- 3.4k
- Forks
- 488
- Merge medio
- 2 d 7 h
- PR fusionados (30 d)
- 29
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de callstack/react-native-pager-view
-
Dificultad 3/5 1-2 días Aptitud para principiantes 67/100
callstack/react-native-pager-view#1205 ·
Los mantenedores suelen responder en 1 día
-
[iOS] Page is blank after setPage when the screen re-renders on pager eventsPosiblemente ocupada @KisaneNeko la tomó hoy. Abierto
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
callstack/react-native-pager-view#1202 ·
Los mantenedores suelen responder en 1 día
-
[Android] v9: a swipe reports idle when the finger lifts, before the page settles (settling is never sent)Posiblemente ocupada @mozzius la tomó hoy. Abierto
Dificultad 4/5 1-2 días Aptitud para principiantes 25/100
callstack/react-native-pager-view#1199 · 1 reacción ·
Los mantenedores suelen responder en 1 día
-
[iOS] Focused TextInput keeps focus and keyboard after switching pages (v9)Posiblemente ocupada @TaduJR la tomó hace 7 días. Abierto
Dificultad 4/5 1-2 días Aptitud para principiantes 69/100
callstack/react-native-pager-view#1192 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 3/5 1-2 días Aptitud para principiantes 73/100
callstack/react-native-pager-view#1191 ·
Los mantenedores suelen responder en 1 día
Todos los issues de callstack/react-native-pager-view
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 79/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 79/100
galaxyproject/loom#616 ·
Los mantenedores suelen responder en 1 día
-
e2e-failure ready-to-code
Dificultad 2/5 1-3 horas Aptitud para principiantes 79/100
redhat-developer/rhdh-plugin-export-overlays#4580 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 1/5 1-3 horas Aptitud para principiantes 84/100
eknowledger/toolbench#266 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
devdotfast/whiteboard#1415 · 1 comentario ·
Los mantenedores suelen responder en 1 día