reactjs - helmet - react open graph

¿Papel de QueryRenderer en relé moderno? (2)

Entonces, después de haber trabajado un poco más con nuestra aplicación, pensé que volvería para publicar sobre nuestros pensamientos y experiencias hasta ahora, con la esperanza de que ayude a alguien.

Sobre la base de la gran publicación de @Peter Suwara, llegamos a una estrategia similar inicialmente

Tener un árbol de navegación raíz / padre
Para cada pantalla en el árbol, tenga un QueryRenderer como raíz para todos los componentes de presentación / tontos que contiene
Utilice fragmentos para declarar dependencias de datos dentro de los subcomponentes

Sin embargo, como comentamos en los comentarios a continuación de su respuesta, este enfoque podría no ser siempre el mejor. Después de una discusión interna, llegamos a la conclusión de que hay demasiados casos en los que esto podría no tener sentido después de todo por un par de razones:

Si recupera datos para cada carga de pantalla, muchas veces terminará con más viajes de ida y vuelta que lo necesario. Desea tener en cuenta el flujo de aplicaciones y obtener tantos datos como sea posible / necesario para una ruta y sus hijos.
Además, si recupera todos los datos para los componentes secundarios de una pantalla en el mismo QueryRenderer, a veces puede terminar obteniendo datos que nunca se mostrarán al usuario (es decir, detalles para una vista de detalles que rara vez se muestra, o casos similares) .

Después de reflexionar un poco más y discutir, se nos ocurrió esta regla de oro para cuándo crear una nueva ''raíz'' de QueryRenderer de un árbol de retransmisión:

Cree un nuevo QueryRenderer para cada vez que necesite una nueva estrategia de manejo de errores

Esto ocurrió por la razón muy práctica de que es la única posibilidad que tiene para manejar los errores / la carga de datos, pero también tiene sentido para nosotros en la forma de flujo y composición del usuario, ya que generalmente las dos cosas chocan: desea una nueva Manera de manejar los errores de red cuando alcanza un nuevo ''flujo'' / parte de su aplicación. Tal vez algunas cabezas más inteligentes en Facebook pensaron en esto antes que nosotros? :-)

Al igual que con todas las reglas generales, es solo eso: una directriz, y no una regla, y tiene excepciones, por supuesto. Sin embargo, parece tener sentido para nosotros internamente, al menos por ahora.

Todos los comentarios sobre estos pensamientos son muy bienvenidos, ya que creo que los documentos oficiales carecen de brillo por decir lo menos, y la discusión de la comunidad es todo lo que tenemos hasta que los documentos y los patrones generales se resuelvan con el tiempo.

Entonces, primero un poco de fondo . Soy un desarrollador nativo de iOS / Android que ahora está iniciando mi primer proyecto React Native. Viene con todos los beneficios y molestias de Javascript, pero hasta ahora me gusta mucho :-) También decidí probar mi mano en GraphQL por primera vez.

Como soy nuevo en el entorno React en general, tampoco tengo ningún conocimiento previo de Relay, pero lo elegí por recomendación de amigos de mi comunidad de inicio y de mis colegas web-dev. También se me advirtió sobre una curva de aprendizaje un tanto abrupta, pero decidí seguir adelante de todos modos: ya estoy librando una batalla cuesta arriba con JS y una versión 0.xx de una nueva plataforma móvil, ¿qué diablos, verdad? :-) Me las arreglé para configurar mi proyecto correctamente y perforar todo mi servidor GQL con un QueryRenderer , lo que fue un gran alivio :-)

Así que, a las preguntas

Me está costando entender la relación contenedor / componente, y la composición del contenedor en general. La lectura de los documentos sobre la composición ayudó, pero todavía tengo dudas sobre el papel del QueryRenderer

Se dice que QueryRenderer es el contenedor raíz para cada árbol de retransmisión. ¿ QueryRenderer significa que uno debe tener un QueryRenderer para la raíz en nuestra aplicación? ¿O en la raíz de cada ruta de navegación (es decir, pestañas en nuestra aplicación)? ¿O solo para cada componente del contenedor (a diferencia de los componentes de presentación / tontos / puros, reaccionar)? Tenga en cuenta que no estoy buscando opiniones, sino argumentos para las mejores prácticas :-)
¿Puede un FragmentContainer (o cualquier otro contenedor) trabajar sin un QueryRenderer en el componente ''primario''?
¿Cómo se vincula QueryRenderer a los contenedores secundarios? ¿Obtiene la suma de todos los datos que los contenedores secundarios desean y luego los contenedores secundarios se leen del caché o? Si es así, he entendido mal las ventajas de Relay: tenemos la impresión de que cada componente puede recuperar datos de forma independiente de todos los demás componentes, y que cada componente no sabe nada sobre los requisitos de datos de otros componentes (incluidos los componentes padre / hijo). ). Creo que esta suposición es también lo que me confunde acerca de QueryRenderer y la necesidad de un contenedor "Root".
Si QueryRenderer es un contenedor de retransmisión ''padre'' / ''raíz'' a un árbol de retransmisión, ¿por qué tiene que representar los componentes de la vista en función de su solicitud? ¿Y por qué tiene que tener una petición? ¿Cuándo y para qué debemos usar un QueryRenderer ?

Cualquier ayuda es muy apreciada :-)

Gracias por traer este tema. Yo también acabo de entrar en Relay con ReactNative, y con algunos resultados emocionantes.

En primer lugar, me sorprende lo fácil que ha sido llevar a la pantalla los componentes de la interfaz de usuario que reflejan las bases de datos GraphQL. Después de la sobrecarga inicial de aprender los conceptos básicos de JavaScript y el canal de reacción nativo, Relay se ha convertido en una forma fantástica de presentar datos.

En cuanto a las mejores prácticas, no puedo decir con seguridad cómo presentar su QueryRenderer y el fragmentContainer, sin embargo, puedo describir nuestra forma de presentar los datos.

En primer lugar creamos una pila y pestaña de navegación de reacción. Dentro de cada pantalla principal ejecutamos un QueryRenderer. Luego, dentro de ese QueryRenderer, para cada componente específico de la IU, nos separamos en un fragmentContainer.

Flujo de navegación (react-navigation, Stack / Tab Navigators)
Pantalla (QueryRenderer) UI
Widget / Componente (fragmentContainer)

Esto nos permite crear la consulta primaria requerida para la pantalla y luego dividir los datos de los componentes para que se ajusten a los componentes consumibles que se definen fácilmente por el fragmento de consulta GraphQL que representan. Sin embargo, significa que estamos ejecutando varias consultas en toda la aplicación sin una consulta de cuenta central para resumir toda la representación en un paquete limpio.

Idealmente, me gustaría probar un QueryRenderer en la parte superior dentro de un Navegador, sin embargo, todavía no he entendido cómo y si esto funcionaría, ya que los Navegadores no responden a una función render (), que es donde está el QueryRenderer. necesario.

También me interesaría escuchar los enfoques de otras personas sobre cómo aplican el relevo dentro de una aplicación navegable nativa de reacción.