Business
Jobs
  • About Us
  • Solutions
    • Job Postings
      Post your job and receive qualified candidates in 48h.
    • Candidate Assessments
      500+ technical and psychological tests, plus anti-fraud.
    • Headhunting
      Tailor-made executive search from start to finish.
    • Payroll + EOR
      Payroll dispersal and EOR across 15+ LATAM countries.
  • Pricing
  • Jobs

0

99
Views
Manejar una visibilidad modal con el estado principal frente a entregarla con imperativoHandle y estado modal

Necesito implementar un modal reutilizable. Tengo básicamente dos implementaciones en mi mente.

  1. Manejar la visibilidad modal en el estado padre. Luego, tendré que pasar el setter de estado al componente modal, ya que siempre tendré un botón dentro del modal para cerrarlo.
 const Modal = (props) => { return ( <div> <button onClick={() => props.setVisibility(false)}>Cancel</button> </div> ); }; export default function App() { const [showModal, setShowModal] = useState(false); return ( <div className="App"> <button onClick={() => setShowModal((p) => !p)}>Toggle Modal</button> {showModal && <Modal setShowModal={setShowModal} />} </div> ); }
  1. Maneje la visibilidad modal en el componente modal en sí, pero exponga una función para mostrar/ocultar el modal usando un imperativeHandle .
 const Modal = React.forwardRef((props, ref) => { const [showModal, setShowModal] = useState(false); useImperativeHandle(ref, () => ({ hide: () => setShowModal(false), show: () => setShowModal(true), toggle: () => setShowModal((p) => !p) })); if (!showModal) return null; return ( <div> <button onClick={() => setShowModal(false)}>Cancel</button> </div> ); }); export default function App() { const modal = useRef(); return ( <div className="App"> <button onClick={() => modal.current.toggle()}>Toggle Modal</button> <Modal ref={modal} /> </div> ); }

Prefiero el segundo, ya que creo que se ve más limpio, sin un montón de estados que contaminen el componente principal (habrá múltiples modales en una página). La función de alternar solo está ahí para el ejemplo, solo necesitaré las funciones mostrar y ocultar. Además, la visibilidad del modal es una propiedad del modal, y creo que el modal debería ser el componente que lo maneje. Pero he escuchado a personas e incluso a los documentos de reacción decir

El código imperativo que usa referencias debe evitarse en la mayoría de los casos.

Entonces, aunque creo que este es un uso aceptable de las referencias, eso es lo que me detiene. Quiero saber,

  • cual de las dos es la forma de reaccionar de hacer esto
  • ¿Hay alguna diferencia en el rendimiento entre las dos formas?
  • ¿Hay posibilidades de que ocurran errores si decido usar referencias?
about 4 years ago · Santiago Trujillo
1 answers
Answer question

0

Respecto a ti 3 preguntas:

  1. La forma de reacción es definitivamente la forma sin useImperativeHandle . El código de reacción debe ser declarativo, no imperativo.

  2. No sé sobre el rendimiento. No esperaría una gran diferencia.

  3. El useImperativeHandle técnicamente funcionará bien , no habrá errores inmediatos. Pero la idea detrás de la forma de reaccionar es mantener el código mantenible, fácil de entender y evitar futuros errores y confusiones.

Ejemplos de problemas con la forma imperativa:

Imagine que de repente necesita abrir/cerrar un modal de múltiples componentes. Si el estado está en el padre, este cambio es simple, puede pasar fácilmente el estado y la devolución de llamada setState donde quiera.

Si usa useImperativeHandle , debe asegurarse de que el estado sea consistente, lo que en esencia significa manejar el estado en algún componente principal de todos modos.

O imagine que decide (o necesita) refactorizar para usar un patrón reductor y dispatch una acción openModal en lugar de llamar al "método" show de su componente. Nuevamente, eso es fácil si solo maneja estados y devoluciones de llamada de todos modos.

Cómo seguir la vía declarativa y por qué:

Entiendo totalmente su deseo de mantener el estado dentro del modal. Siento lo mismo (y estaría feliz de ser corregido aquí). Pero también estoy feliz una y otra vez de no haber combinado algún estado con otro código, cuando necesito hacer "un cambio rápido".

Si tiene varios estados y no quiere saturar su componente principal, puede usar un enlace personalizado , como probablemente sepa.

Y esa es la belleza de este estilo declarativo:

No tiene que pensar demasiado en ese enlace personalizado por ahora, simplemente puede mover los estados allí tal como están.

Si luego siente que debe cambiar el nombre de algo u organizar el estado de manera diferente (pero aún siguiendo la forma de reaccionar), es fácil lanzar estados entre componentes (o ganchos, o redux, ...),

  • siempre siguiendo los mismos patrones ,
  • pensando solo en lo que estás haciendo en este momento , moviendo estados, sin pensar en la lógica con la que están relacionados,
  • sin confundirse demasiado.
about 4 years ago · Santiago Trujillo Report
Answer question
Find remote jobs

Discover the new way to find a job!

Top jobs
Top job categories
Business
Post vacancy Pricing Sales
Legal
Terms and conditions Privacy policy
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Show me some job opportunities
There's an error!