asBaseComponent: stale module-level colorScheme prevents re-render on scheme switch back
Los mantenedores suelen responder en 1 día
@huytdps13400 ya está trabajando en esto.
Desde el 4/10/2026.
Evaluación
- Dificultad
- 2/5
- Tiempo estimado
- 1-3 horas
- Aptitud para principiantes
- 85/100
- Tipo de issue
- Error
- Claridad
- Bien especificado
- Estado de actividad
- Estancado
- Stack tecnológico
- javascript, react-native
- Área
- frontend, mobile-dev
Línea de trabajo
Empieza en src/commons/asBaseComponent.js e inspecciona cómo BaseComponent inicializa su estado colorScheme y registra appearanceListener. Reproduce la secuencia de cambio light-to-dark-to-light con componentes montados después del primer cambio. Se considera terminado cuando los componentes RNUI afectados se vuelven a renderizar correctamente en ambas direcciones sin conservar colores obsoletos.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Description
asBaseComponent HOC captures colorScheme as a module-level constant at import time. Since BaseComponent extends React.PureComponent (via UIComponent), components mounted after a scheme change hold a stale state.colorScheme that matches the original scheme. When switching back to that original scheme, the appearanceListener guard (this.state.colorScheme !== colorScheme) evaluates to false, skipping setState and preventing re-render.
Related to
- Components
- Demo
- Docs
- Typings
Steps to reproduce
- App starts in light mode → module-level
colorSchemeis captured as'light' - Go to a settings/appearance screen and switch to dark mode → all RNUI components re-render correctly
- Navigate to any screen — new components mount during dark mode with
state.colorScheme = 'light'(stale module-level value) - Switch back to light mode →
Scheme.broadcastSchemeChange('light')fires - Stale components check
'light' !== 'light'→false→setStateis never called → no re-render
Expected behavior
All RNUI components (Text, View, Button, Switch, etc.) should re-render with the updated color scheme when switching in both directions (light → dark AND dark → light).
Actual behavior
Components mounted after the first scheme change do not re-render when switching back to the original scheme. They retain the previous scheme's colors (e.g., light gray text on a light background) because BaseComponent (a PureComponent) skips rendering — both props and state appear unchanged.
More Info
Code snippet
The bug is in src/commons/asBaseComponent.js:
// Line 8 — evaluated ONCE at module load, never updated
const colorScheme = Scheme.getSchemeType();
function asBaseComponent(WrappedComponent, options = {}) {
// BaseComponent extends UIComponent which extends React.PureComponent
class BaseComponent extends UIComponent {
state = {
error: false,
colorScheme // All instances get the stale module-level value
};
appearanceListener = colorScheme => {
// This guard fails for stale instances when switching back to the original scheme
if (this.state.colorScheme !== colorScheme) {
this.setState({ colorScheme });
}
};
}
}
Fix — evaluate Scheme.getSchemeType() per instance instead of once at module level:
const EMPTY_MODIFIERS = {};
-const colorScheme = Scheme.getSchemeType();
function asBaseComponent(WrappedComponent, options = {}) {
class BaseComponent extends UIComponent {
state = {
error: false,
- colorScheme
+ colorScheme: Scheme.getSchemeType()
};
Screenshots/Video
N/A — the visual symptom is dark-theme text colors (e.g., #C9D6DF) rendered on a light-theme background (#F0F5F9), causing text to blend/disappear.
Environment
- React Native version: 0.83
- React Native UI Lib version: 8.3.4
Affected platforms
- Android
- iOS
- Web
- Lenguaje dominante
- TypeScript
- Estrellas
- 7.2k
- Forks
- 749
- Merge medio
- 29 min
- PR fusionados (30 d)
- 1
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 wix/react-native-ui-lib
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
wix/react-native-ui-lib#4022 ·
Los mantenedores suelen responder en 1 día
-
SortableGridList does not forward props to its inner ScrollView (inconsistent with SortableList)Posiblemente ocupada @yinminqian la tomó hace 172 días. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
wix/react-native-ui-lib#4002 ·
Los mantenedores suelen responder en 1 día
-
RN 0.85.0 StyleSheet.absoluteFillObject is removedPosiblemente ocupada @ChrisJamesC la tomó hace 79 días. Abiertobug
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
wix/react-native-ui-lib#3965 · 3 comentarios · 1 reacción ·
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
wix/react-native-ui-lib#4044 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
wix/react-native-ui-lib#4043 · 1 reacción ·
Los mantenedores suelen responder en 1 día
Todos los issues de wix/react-native-ui-lib
Issues similares
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
shoelace-style/webawesome#2979 ·
Los mantenedores suelen responder en 1 día
-
Chip source filter and denial markers miss Storage rows when a Storage activity source is pickedAbiertobug
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 73/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 77/100
omdsh-dev/DSH-better-sidebar#1141 ·
Los mantenedores suelen responder en 2 días