Toggling tabBarHidden destroys the tab's SwiftUI identity, dismissing presented sheets
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 2/5
- Tiempo estimado
- 1-3 horas
- Aptitud para principiantes
- 75/100
- Tipo de issue
- Error
- Claridad
- Bien especificado
- Estado de actividad
- Activo
- Stack tecnológico
- react-native, swift, typescript
Línea de trabajo
El problema está en el código Swift para iOS. Examine la función hideTabBar en ios/TabViewImpl.swift alrededor de las líneas 537-553. La solución es cambiar la lógica condicional para usar self.toolbar(flag ? .hidden : .automatic, for: .tabBar) para iOS 16+ y preservar la identidad de SwiftUI. Pruebe el cambio utilizando el gist de reproducción de SwiftUI proporcionado para verificar que alternar la bandera ya no restablece el estado ni descarta las hojas. El cambio debe aplicarse tanto en NewTabView.swift como en LegacyTabView.swift donde se llama a la función.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Before submitting a new issue
- I tested using the latest version of the library (1.4.0 is both
latestand what we ship) - I tested using a supported version of react native (0.86.3)
- I checked for possible duplicate issues
Bug summary
Toggling tabBarHidden at runtime tears down the tab's content and rebuilds it. A sheet presented from inside that tab is dismissed, and any @State in the subtree is lost.
We hit this on the common pattern of hiding the tab bar while the keyboard is up: a user typing in a sheet raises the keyboard, the app sets tabBarHidden, and their sheet disappears mid-edit.
Cause. hideTabBar is a @ViewBuilder whose branch depends on flag:
// ios/TabViewImpl.swift:537-553 @ 1.4.0
@ViewBuilder
func hideTabBar(_ flag: Bool) -> some View {
#if !os(macOS)
if flag {
if #available(iOS 16.0, tvOS 16.0, *) {
self.toolbar(.hidden, for: .tabBar)
} else {
// We fallback to isHidden on UITabBar
self
}
} else {
self
}
#else
self
#endif
}
A @ViewBuilder if/else compiles to _ConditionalContent<A, B>. Flipping flag swaps which branch is taken, which changes the view's type, which changes its structural identity. SwiftUI answers an identity change by discarding the subtree and building a new one — taking @State and any anchored presentation with it.
flag is a JS-driven prop, so this happens at runtime rather than once at setup:
ios/TabView/NewTabView.swift:45 .hideTabBar(props.tabBarHidden)
ios/TabView/LegacyTabView.swift:33 .hideTabBar(props.tabBarHidden)
Suggested fix
Take one branch, decided by availability — which is constant at runtime — and let only the toolbar value depend on flag:
@ViewBuilder
func hideTabBar(_ flag: Bool) -> some View {
#if !os(macOS)
if #available(iOS 16.0, tvOS 16.0, *) {
// Keep the tab content's SwiftUI identity when tab-bar visibility changes.
// Switching between a modified view and `self` tears down presentations
// anchored in that tab.
self.toolbar(flag ? .hidden : .automatic, for: .tabBar)
} else {
// We fallback to isHidden on UITabBar.
self
}
#else
self
#endif
}
.automatic is the documented default for a toolbar's visibility, so the flag == false case keeps its current behaviour while the view keeps its identity. The pre-iOS-16 fallback is unchanged and still cannot hide the bar this way; that branch is now chosen by availability alone, so it no longer participates in identity changes either.
This is the diff we currently carry as a patch:
@ViewBuilder
func hideTabBar(_ flag: Bool) -> some View {
#if !os(macOS)
- if flag {
- if #available(iOS 16.0, tvOS 16.0, *) {
- self.toolbar(.hidden, for: .tabBar)
- } else {
- // We fallback to isHidden on UITabBar
- self
- }
+ if #available(iOS 16.0, tvOS 16.0, *) {
+ // Keep the tab content's SwiftUI identity when keyboard visibility
+ // changes. Switching between a modified view and `self` tears down
+ // presentations anchored in that tab, including Expo UI sheets.
+ self.toolbar(flag ? .hidden : .automatic, for: .tabBar)
} else {
+ // We fallback to isHidden on UITabBar.
self
}
#else
Happy to open a PR.
Library version
1.4.0
Environment info
react-native: 0.86.3
expo: 57.0.20
react: 19.2.3
react-native-bottom-tabs: 1.4.0
platform: iOS (real device and simulator)
architecture: Fabric (New Architecture)
Steps to reproduce
The reproduction is pure SwiftUI — no React Native and no dependency on this library, which is what shows the cause is the @ViewBuilder branch rather than anything about the bridge, the props, or the app.
- Download
IdentityRepro.swiftfrom the gist below - Drop it into an iOS app target, or open it in an Xcode Preview
- Increment both counters, and/or tap "present sheet" on either side
- Flip the
tabBarHiddentoggle
Expected: both columns keep their state.
Actual: the UPSTREAM column resets its counter to 0 and dismisses its sheet; the FIXED column keeps both.
The file defines hideTabBar_upstream (verbatim from TabViewImpl.swift) and hideTabBar_fixed (the suggestion above) side by side over identical subtrees.
iOS/tvOS only — .toolbar(_:for: .tabBar) is unavailable on macOS, which is why the library's own function is wrapped in #if !os(macOS).
Reproducible sample code
https://gist.github.com/pawarren/56cbb014c18150e67995bf6f11ff8168
- Lenguaje dominante
- TypeScript
- Estrellas
- 1.5k
- Forks
- 108
- Merge medio
- 12 h 42 min
- PR fusionados (30 d)
- 9
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-bottom-tabs
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
-
Dificultad 4/5 3-5 días Aptitud para principiantes 48/100
-
Dificultad 4/5 3-5 días Aptitud para principiantes 68/100
callstack/react-native-bottom-tabs#591 · 1 comentario ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 58/100
-
bug
Dificultad 4/5 3-5 días Aptitud para principiantes 48/100
Todos los issues de callstack/react-native-bottom-tabs
Issues similares
-
VerificationGate: ATTRIBUTION quote guard never matches a normal quotation (\b around the quote) Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
danielmiessler/LifeOS#2234 ·
-
T: Bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 85/100
-
Mend: dependency security vulnerability untriaged
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100