UIKit host views attach after first React paint
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 45/100
- Tipo di issue
- Bug
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Tranquilla
- Stack tecnologico
- react-native
- Ambito
- frontend, mobile-dev
Direzione di ricerca
Inizia tracciando defineUIKitHost e il relativo percorso useEffect, inclusi runOnUI e la pubblicazione di nativeViewHandle, childrenViewHandle e controllerHandle. Verifica come l’host nativo condiviso riceve questi handle durante il commit iniziale, quindi usa una piccola riproduzione con defineUIKitView, defineUIKitContainer o defineUIViewController per verificare che il contenuto UIKit venga collegato al primo paint senza workaround di temporizzazione.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Summary
When using @nativescript/react-native UIKit host helpers (defineUIKitView, defineUIKitContainer, and defineUIViewController), the React Native host view can appear on the first paint before the NativeScript-created UIKit subtree/controller is attached. The UIKit content then appears on a later paint.
This makes app startup look two-staged: the React Native shell is visible first, then native nav/tab/accessory/card views pop in. In our app we ended up hiding the root with a double requestAnimationFrame until the native views appear, which feels like the wrong layer for the fix.
Observed behavior
In a React Native/Expo app using @nativescript/[email protected]:
- UIKit components are defined at module load with
defineUIKitView/defineUIKitContainer/defineUIViewController. - On initial render, the RN host commits without the native UIKit view/controller handle.
- The actual UIKit subtree appears on the next render/paint.
- A native tab/navigation shell therefore needs a timing workaround to avoid visible first-paint flicker.
Expected behavior
If the component is already defined before app render, UIKit-backed host views/controllers should be attachable in the initial host commit, or the package should expose a deterministic precreate/ready mechanism so apps do not need timing hacks.
Likely cause
From reading the package source, defineUIKitHost creates the native UIKit object from a React useEffect. That means the initial render starts with nativeViewHandle, childrenViewHandle, and controllerHandle undefined. After runOnUI() resolves, the package calls setNativeViewHandle, setChildrenViewHandle, and/or setControllerHandle, causing a second React commit where the shared native host finally receives the handles.
So defining the component earlier does not help, because the native object creation/handle publication still happens after the first commit.
Why this matters
Native shell UI such as UITabBarController, UINavigationController, tab bar accessories, and native cards should feel present on the first frame. The current behavior forces app code to either accept a visible two-stage paint or hide the whole shell with timing-based workarounds.
Possible directions
- Create/publish UIKit handles before the initial React Native host commit when possible.
- Provide an explicit precreate API for startup-critical native hosts.
- Provide a deterministic
onReady/mounted signal from the package, so apps can hide only until the actual native handle is attached rather than guessing with animation frames.
Happy to provide a small repro if useful.
- Lingua principale
- C++
- Stelle
- 25
- Fork
- 4
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di NativeScript/runtimes
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
NativeScript/runtimes#42 ·
-
Swift Binding GeneratorAperta
Difficoltà 5/5 Più di una settimana Idoneità per principianti 30/100
NativeScript/runtimes#41 ·
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 30/100
NativeScript/runtimes#40 ·
-
Smart Metadata AnalysisAperta
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
NativeScript/runtimes#39 ·
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
NativeScript/runtimes#38 ·
Tutte le issue di NativeScript/runtimes
Issue simili
-
UPC C++ link do not workAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
-
CI tracking issue
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 78/100
espressif/esp-matter#1874 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
KavrakiLab/vamp#126 ·
-
cudev: Fix MSVC build failures with 64-bit integers (int64_t/uint64_t) in vec_traits.hppForse già presa Una pull request collegata a questa issue è aperta o già unita. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
opencv/opencv_contrib#4231 ·
I maintainer di solito rispondono entro 1 giorno