Web: value={0} with a negative minimumValue renders the thumb at the minimum
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 2/5
- Tiempo estimado
- 1-3 horas
- Aptitud para principiantes
- 78/100
- Tipo de issue
- Error
- Claridad
- Bien especificado
- Estado de actividad
- Activo
- Stack tecnológico
- react-native, typescript
Línea de trabajo
Comienza en package/src/RNCSliderNativeComponent.web.tsx, especialmente en el estado inicial cerca de la línea 81 y en el efecto de resincronización cerca de las líneas 163-171. Reproduce el ejemplo proporcionado con un mínimo negativo y, después, verifica que un valor explícito value={0} se renderiza en cero, mientras que el caso no controlado no se restablece inesperadamente.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Environment
@react-native-community/slider: 5.2.1 (also present onmainat the time of writing)- Platform: web (
react-native-web0.21.2) - react: 19.2.3 · react-native: 0.86.3 · Expo SDK 57
- New architecture: yes (Expo
newArchEnabledis unconditional in SDK 57) — but this is a web-only code path, so the architecture is not relevant
Description
On web, a slider rendered with value={0} and a negative minimumValue paints its thumb at the minimum instead of at zero.
The value itself is fine — onValueChange reports correctly, and every number the app derives from the slider is right. Only the thumb position is wrong, and it stays wrong until the user drags it, at which point it starts behaving. So the failure looks like a rendering quirk rather than a state bug, which makes it easy to dismiss.
It is quite easy to hit in practice: any bipolar control that rests at zero does. Mine is a turntable-style pitch fader (-8 … +8, resting at 0), which means it was wrong on every load.
Reproducible Demo
import Slider from '@react-native-community/slider';
// Thumb renders hard left. Expected: centred.
<Slider minimumValue={-8} maximumValue={8} value={0} />
// Both of these are fine, which isolates it to the value being exactly zero
// against a negative minimum:
<Slider minimumValue={-8} maximumValue={8} value={0.1} />
<Slider minimumValue={0} maximumValue={16} value={8} />
Cause
Two things combine, both in package/src/RNCSliderNativeComponent.web.tsx.
1. The initial state is seeded with || (L81):
const [value, setValue] = React.useState(initialValue || minimumValue);
0 is falsy, so value={0} seeds the internal state at minimumValue rather than at 0.
This cannot be fixed with ?? alone, because value is already defaulted at the destructure (L55):
value: initialValue = 0,
so by the time that line runs, "no value prop" and value={0} are indistinguishable — both are 0.
2. The resync effect cannot recover it (L163-L171):
const lastInitialValue = React.useRef<number>(0);
// ...
if (initialValue !== lastInitialValue.current) {
lastInitialValue.current = initialValue;
const newValue = updateValue(initialValue);
animationValues.val.setValue(newValue);
}
The ref starts at 0, so for initialValue === 0 the guard evaluates 0 !== 0 — false. The effect never runs and the wrong initial state is never corrected.
I appreciate the guard is deliberate; the comment above it explains that it exists because initialValue gets defaulted to 0 by Slider, and without it the value resets constantly when the slider is uncontrolled. Any fix wants to keep that property.
Suggested fix
Distinguish "no value prop" from value={0} by not defaulting at the destructure, and track the same distinction in the ref:
value: initialValue, // no ` = 0`
// ...
const [value, setValue] = React.useState(initialValue ?? minimumValue);
const lastInitialValue = React.useRef<number | undefined>(initialValue);
// ...
if (initialValue !== undefined && initialValue !== lastInitialValue.current) {
lastInitialValue.current = initialValue;
const newValue = updateValue(initialValue);
animationValues.val.setValue(newValue);
}
That keeps the uncontrolled case from being reset (the effect still does nothing when no value is passed) while letting an explicit value={0} through.
I have not sent a PR since the change touches the uncontrolled path and you will have a clearer view than I do of what that should do; happy to open one if the approach looks right.
Workaround
For anyone hitting this before it is fixed: shift the domain so zero is not the resting value, and convert at the boundary.
// fader units 0 … 2R, presented as -R … +R
<Slider
minimumValue={0}
maximumValue={range * 2}
value={pitch + range}
onValueChange={(v) => setPitch(v - range)}
/>
The only value that still lands on 0 is the control fully down, where minimumValue is also 0, so the falsy branch produces the correct result anyway.
- Lenguaje dominante
- TypeScript
- Estrellas
- 1.4k
- Forks
- 295
- Métricas de merge de PR
- Sin PR fusionados en 30 d
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-slider
-
bug report
Dificultad 1/5 Menos de una hora Aptitud para principiantes 68/100
callstack/react-native-slider#769 ·
-
bug report platform: iOS
Dificultad 4/5 3-5 días Aptitud para principiantes 42/100
callstack/react-native-slider#782 · 6 comentarios ·
-
bug report
Dificultad 3/5 1-2 días Aptitud para principiantes 65/100
callstack/react-native-slider#780 · 1 comentario ·
-
bug report
Dificultad 3/5 1-2 días Aptitud para principiantes 35/100
callstack/react-native-slider#767 ·
-
bug report platform: iOS
Dificultad 4/5 3-5 días Aptitud para principiantes 45/100
callstack/react-native-slider#758 · 4 comentarios ·
Todos los issues de callstack/react-native-slider
Issues similares
-
refactor
Dificultad 2/5 Medio día Aptitud para principiantes 84/100
Los mantenedores suelen responder en 5 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
OHDSI/Data2Evidence#3450 ·
Los mantenedores suelen responder en 2 días
-
e2e-failure ready-to-code
Dificultad 2/5 1-3 horas Aptitud para principiantes 90/100
redhat-developer/rhdh-plugin-export-overlays#4011 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
automation missing-model model-sync provider:ofox
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
anomalyco/models.dev#8421 ·
Los mantenedores suelen responder en 1 día
-
SlackAdapter and TelegramAdapter are not assignable to Adapter under exactOptionalPropertyTypesAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
Los mantenedores suelen responder en 1 día