lockAspectRatio still breaks at independent min/max constraints
@sameerdeolalikar ya está trabajando en esto.
Desde el 26/9/2026.
- #278 de @sameerdeolalikar — abierto
Evaluación
- Dificultad
- 3/5
- Tiempo estimado
- 1-2 días
- Aptitud para principiantes
- 76/100
- Tipo de issue
- Error
- Claridad
- Bien especificado
- Estado de actividad
- Activo
- Stack tecnológico
- react, typescript
- Área
- frontend
Línea de trabajo
Start at the lockAspectRatio constraint projection and clamping logic in the current implementation, then run the focused regression test described in the issue. Verify width and height minimum and maximum bounds, overshoot/return, and a subsequent gesture preserve the aspect ratio when possible. Confirm the incompatible-bounds control still gives size constraints precedence.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
With lockAspectRatio enabled, independently calculated width and height constraints can still change the aspect ratio on current master (c6fd4ab8d3d4e9c0707c2bbb6d47d0fcbdb5e6b9, 4.0.2).
For example, start at 300 × 150 (2:1), set minConstraints={[100, 50]} and maxConstraints={[420, 400]}, then drag the southeast handle toward 600 × 300. The current result is 420 × 300 rather than 420 × 210. The width and height are clamped independently after projection onto the ratio line. With a controlled component, that changed ratio also becomes the next resize's input ratio.
Expected: when a size satisfying both bounds and the ratio exists, keep the ratio and choose that size. If the bounds make the ratio impossible, retain size-constraint precedence rather than exceeding a bound.
Related historical report: #51. The current implementation still reproduces this despite the later projection rewrite. I have a focused regression test covering width/height minimum and maximum bounds, overshoot/return and a subsequent gesture. Five new tests fail on unchanged master; the incompatible-bounds control passes.
- Lenguaje dominante
- TypeScript
- Estrellas
- 2.6k
- Forks
- 373
- 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
- Sin 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 react-grid-layout/react-resizable
-
Dificultad 4/5 3-5 días Aptitud para principiantes 38/100
react-grid-layout/react-resizable#237 · 8 comentarios · 1 reacción ·
-
Dificultad 3/5 1-2 días Aptitud para principiantes 55/100
react-grid-layout/react-resizable#222 · 4 comentarios ·
Todos los issues de react-grid-layout/react-resizable
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
feat(icons): add [solidping]Abierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 82/100
homarr-labs/dashboard-icons#2939 ·
Los mantenedores suelen responder en 1 día
-
Agent/category reasoning variants are still checked against the stale model cache in chat.paramsAbiertoopencode
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
code-yeongyu/oh-my-openagent#10003 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 77/100
Los mantenedores suelen responder en 1 día
-
Actions on ToastsAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
nextcloud-libraries/nextcloud-dialogs#2669 ·
Los mantenedores suelen responder en 1 día