UIKit host views attach after first React paint
Les mainteneurs répondent en général sous 1 jour
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Accessibilité débutants
- 45/100
- Type d'issue
- Bug
- Clarté
- Plutôt claire
- Activité
- Calme
- Stack technique
- react-native
- Domaine
- frontend, mobile-dev
Piste de recherche
Commencez par suivre defineUIKitHost et son chemin useEffect, notamment runOnUI et la publication de nativeViewHandle, childrenViewHandle et controllerHandle. Vérifiez comment l’hôte natif partagé reçoit ces handles lors du commit initial, puis utilisez une petite reproduction avec defineUIKitView, defineUIKitContainer ou defineUIViewController afin de vérifier que le contenu UIKit est attaché dès le premier paint, sans contournement de timing.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
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.
- Langage dominant
- C++
- Étoiles
- 27
- Forks
- 4
- Merge moyen
- 16 h 48 min
- PR mergées (30 j)
- 4
Préparer son environnement
- Aucun Dockerfile ni fichier Docker Compose
- Aucun modèle de pull request
- Lire le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de NativeScript/runtimes
-
bug
Difficulté 4/5 3-5 jours Accessibilité débutants 48/100
NativeScript/runtimes#100 ·
Les mainteneurs répondent en général sous 1 jour
-
bug
Difficulté 4/5 3-5 jours Accessibilité débutants 45/100
NativeScript/runtimes#99 ·
Les mainteneurs répondent en général sous 1 jour
-
bug
Difficulté 4/5 1-2 jours Accessibilité débutants 55/100
NativeScript/runtimes#98 ·
Les mainteneurs répondent en général sous 1 jour
-
bug
Difficulté 4/5 3-5 jours Accessibilité débutants 53/100
NativeScript/runtimes#97 · 1 commentaire ·
Les mainteneurs répondent en général sous 1 jour
-
bug
Difficulté 4/5 3-5 jours Accessibilité débutants 48/100
NativeScript/runtimes#94 ·
Les mainteneurs répondent en général sous 1 jour
Toutes les issues de NativeScript/runtimes
Issues similaires
-
bug priority: low
Difficulté 2/5 1-3 heures Accessibilité débutants 68/100
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 86/100
chipsalliance/verible#2644 ·
-
Difficulté 2/5 1-3 heures Accessibilité débutants 74/100
grafana/pyroscope-dotnet#470 ·
Les mainteneurs répondent en général sous 1 jour
-
documentation P5 XS
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100
open-astro/AlpacaBridge#1848 ·
Les mainteneurs répondent en général sous 1 jour
-
DiskANN AnnIterator returns unconverted IP distances after the graph walk runs out of candidatesOuverte
Difficulté 2/5 1-3 heures Accessibilité débutants 75/100
zilliztech/knowhere#1933 ·
Les mainteneurs répondent en général sous 1 jour