Mencionaré de antemano que esta no es una pregunta técnica sobre cómo actualizar los datos entre 2 componentes hermanos, sino cuál es la forma correcta de hacerlo.
Tengo la siguiente estructura de árbol de componentes:
App | -- Home | -- SearchBar | | | -- Filters | -- ItemsList ItemsList tiene lógica para cargar la lista de elementos de una llamada API y mostrar la lista de elementos en la página. También gestiona el estado de los artículos. Si se elimina un artículo, lo elimina de la lista y actualiza su estado.
SearchBar es un componente que contiene una búsqueda textual que se muestra arriba de la lista donde un usuario puede ingresar texto para buscar y también tiene un botón que abre el componente Filters donde el usuario puede filtrar diferentes parámetros. Una vez que el usuario busca o filtra, la lista en el componente ItemsList debe actualizarse en consecuencia.
Hay algunas maneras en que puedo pensar para lograr esto:
Home (u otro componente para contener SearchBar y ItemsList , y tanto SearchBar como ItemsList contendrán un consumidor que actualizará el estado con un método en el proveedor, aquellos que actualizan los componentes. Esto en mi opinión crea cierta dependencia entre esos componentes y en realidad no se sostienen por sí solos (el componente ItemsList debe usarse en otras páginas; por supuesto, esto todavía es posible, pero aún no se siente tan "limpio").ItemsList contendrá métodos públicos como "eliminar elemento" y "borrar lista" y esos métodos se llamarán desde el componente de inicio. SearchBar obtendrá una propiedad con una función como un evento, algo así como "onFilterChanged" y llamará al método en ItemsList (tendré que mantener una referencia a ese componente). Pero trabajando así se siente como si cada componente pudiera sostenerse y ser reutilizado por sus propios méritos, pero perdiendo la "reactividad" y más cableado que se necesita hacer.¿Hay otras formas de lograr lo que estoy buscando que no estoy pensando? ¿Cuál es la forma correcta de diseñar este tipo de soluciones?
Cuando dos hermanos necesitan acceso al mismo estado, mantener el estado en un componente padre mutuo es una forma común y recomendada de manejarlo (la documentación oficial de React recomienda ese enfoque para la mayoría de los casos). De esa manera, tanto el estado como cualquier método para actualizar el estado se pueden pasar a ambos niños según sea necesario, y cualquier actualización realizada por un niño se reflejará en el otro niño.
Puede haber inconvenientes en ese enfoque: según el tamaño de la aplicación, la exploración de accesorios puede hacer que el código sea confuso y difícil de mantener, especialmente si un componente que usa dichos datos se usa en varios lugares, profundamente anidado o ambos.
Para tales ocasiones, mantener el estado en contexto o redux es un enfoque más apropiado. La primera opción que enumeró es completamente legítima y lo recomendaría. Tal vez extraer su contexto por completo (no mantenerlo en su componente Home y, en cambio, crear el contexto en su propio archivo) ayudaría a que las cosas se sientan más "limpias".
Determinar cuándo usar qué enfoque es algo que viene con el tiempo y la experiencia. Al elegir un enfoque, es útil tener en cuenta sus planes futuros. Si sabe que la aplicación será pequeña y simple, mantener el estado en un componente principal es un gran paso. Si tiene grandes planes para su aplicación, será más fácil usar Context o Redux desde el principio.
Afortunadamente, el peor de los casos es que decidas cambiar de un enfoque a otro, lo que siempre se puede hacer (por confuso y tedioso que pueda ser a veces).