Siempre me han dicho que los componentes de React deben diseñarse en una jerarquía de árbol para que los antepasados/padres puedan mantener el estado y pasárselo a sus hijos.
Solo me pregunto, ¿es eso IMPRESCINDIBLE?
El principio de diseño de React es que "React ha sido diseñado desde el principio para una adopción gradual, y puede usar tanto React como necesite". Solo pensé, ¿qué pasa si tengo un proyecto existente y quiero agregar un poco de componentes de React por separado aquí y allá sin modificar la mayor parte del código/HTML existente? ¿Pueden estos componentes comunicarse entre sí?
Por ejemplo, digamos que quiero agregar dos componentes React separados en diferentes posiciones en una página HTML sin formato existente, y realmente me gusta que el HTML existente no se genere/modifique con JavaScript tal como está. Los dos componentes no están en ninguna jerarquía entre sí. ¿Todavía pueden acceder al estado del otro? Si un componente se actualiza (ya sea por el clic del usuario, la respuesta de AJAX, etc.), ¿puede este componente notificar al otro que se actualice o decirle que llame a una función?
Todavía no he probado nada, pero habría pensado que si realmente iba a hacer lo anterior, usaría variables/funciones globales como último recurso si nada más funciona. Sin embargo, estoy más interesado en aprender cualquier convención/método/mejor práctica de React para lograr lo anterior.
Si tuviera que compartir el estado (solo con React, al menos), tendría que envolver estos componentes en un contexto y luego representarlos en esos lugares separados con Portals. Estoy bastante seguro de que es factible, aunque en realidad no responde a su pregunta, en este caso los dos componentes serían hermanos que tienen un padre común, proveedor de contexto.
Una solución más razonable sería usar, por ejemplo, Redux o una solución similar. Tendría una sola tienda y luego simplemente llamaría a ReactDOM.render tantas veces como quiera para cada componente que quiera montar en algún lugar de la página. Cada uno de estos componentes tendría que ser un elemento secundario de un proveedor de tienda (que también es un componente) y luego estos componentes podrían comunicarse a través de la tienda.
En términos muy generales, lo que está describiendo es programación basada en eventos y definitivamente puede funcionar. Algunas palabras clave para buscar trabajos anteriores relevantes en el dominio de Javascript son "javascript event bus" y "javascript pub sub" .
La programación basada en eventos estaba de moda en los días de jQuery y ha caído un poco en desgracia en el mundo de la interfaz en los últimos años, pero eso no significa que no pueda usarla. Tenga en cuenta que si bien definitivamente hay ventajas en la programación basada en eventos, también hay una serie de problemas difíciles: flujos asíncronos, eventos que se activan antes de que los oyentes estén listos para ellos, estado consistente, etc. Los enlaces proporcionados anteriormente tienen más información sobre esos problemas también.
La arquitectura que describe es una forma de adoptar gradualmente React y es una solución válida, simplemente debe ser consciente de las ventajas y desventajas. Dependiendo de su caso de uso, esas compensaciones pueden o no tener sentido. En esencia, los principios de diseño de React están algo en desacuerdo con las arquitecturas basadas en eventos, por lo que personalmente lo desaconsejaría. La respuesta de Paolostyle es un buen ejemplo de soluciones alternativas que le permiten realizar una adopción gradual sin dejar de seguir los propios principios de React.