Redux: ¿Ha llegado y se ha ido el tiempo de Redux?

https://github.com/rackt/redux/issues/464

Mucha gente está bastante contenta con Redux. Debería preguntar, no estoy realmente calificado para responder esta pregunta. Yo diría que si su aplicación tiene muchos datos al estilo de Facebook (muchas entidades anidadas con relaciones complejas) es una buena idea invertir en un backend GraphQL y aprender Relay. Solo he escuchado cosas buenas sobre eso.

Redux, por supuesto, es más explícito y no resuelve la búsqueda de datos declarativos por usted. Hay intentos de integrar Redux y GraphQL, pero no puedo evaluarlos con Relay; sé muy poco al respecto.

Redux tiene un nivel mucho más bajo que Relay, y no es más "pasado" que los objetos y funciones JS simples son "pasados". Relay es un marco, y Redux, sin los controles de cordura, tiene diez funciones de 10 líneas, por lo que no debería sorprender que tengan diferentes alcances. Elija lo que funcione mejor para usted y avísenos.

La búsqueda declarativa de GraphQL es asombrosa, de primera categoría. Sin embargo, Relay todavía tiene una API HoC principalmente, que no es declarativa per se. Si Relay ofreciera una API más flexible, desacoplada del árbol de componentes, ¿se podría escribir un enlace Redux adecuado?

Creo que son 2 tipos de sistemas que resuelven 2 problemas distintos.
Este boleto es como un carpintero preguntando si ha pasado la hora del martillo.
Yo diría que los sistemas basados ​​en graphql son una solución de ingeniería excesiva para muchas aplicaciones; a la inversa, las aplicaciones con estructuras de datos complejas probablemente no estén bien diseñadas si se construyen con redux.

Yo diría que los sistemas basados ​​en graphql son una solución de ingeniería excesiva para muchas aplicaciones; a la inversa, las aplicaciones con estructuras de datos complejas probablemente no estén bien diseñadas si se construyen con redux.

Buena manera de colocarlo; así es como me siento yo también.

@gaearon sigue con el buen trabajo con redux! ¡Una de las mejores herramientas en marcha! ¡Lo estoy usando en 5 aplicaciones grandes y 2 pequeñas en mi empresa y me encanta!

@gaearon sigue con el buen trabajo con redux! ¡Una de las mejores herramientas en marcha! ¡Lo estoy usando en 5 aplicaciones grandes y 2 pequeñas en mi empresa y me encanta!

: 100:

Creo que no son lo mismo:

• relé: para resolver la gestión de la obtención de datos desde el servidor
• redux - para resolver la gestión de estado de la aplicación

muchas aplicaciones complejas contienen estados que no están relacionados con el servidor que necesitará administrar. Voy a argumentar que si usa relé, verá que al final también necesitará una reducción. de acuerdo con lo contrario, el relé parece un buen impulso, pero solo para cosas relacionadas con el servidor

La pregunta es ¿cómo se relaciona Relay con los patrones de diseño inspirados en flux? ¿Dónde termina Relay, cuándo necesitamos Redux? ¿Es Relay Flux 2.0?

El ejemplo de Todo Relay: ¿vuelve obsoleto redux?

Tal vez haya una manera de decirle a su reductor cómo mapearse desde y hacia GraphQL y cuándo. No decir algo que no sea complejo, sino cuál es la forma más sencilla de hacer que eso tenga sentido.

Necesito aprender más sobre qué es Relay. ¡No son un par de cientos de líneas de código, eso es seguro!

@oriSomething No tienes toda la razón. Relay también resuelve gran parte de la gestión estatal.

@gyzerok me refiero al estado de la aplicación del lado del cliente

@oriSomething Sí, estoy hablando del estado de la aplicación del lado del cliente

@gyzerok, me lo he perdido. ¿puedes darme un enlace sobre esto?

@oriSomething no hay un enlace especial porque Relay lo gestiona implícitamente. Tal vez puedas intentar ver las charlas de FB sobre Relay. Hablan de cómo Relay resuelve el problema de la caché. Caché de la aplicación del lado del cliente = estado. No recuerdo una charla definida, lo siento.

@oriSomething en el único lugar donde el desarrollador debería hacer una gestión explícita del estado es aquí .

@gyzerok ok, entonces, en ese caso, ¿hay una gestión de estado que no esté relacionada con el servidor que retransmite? hasta donde tengo entendido, no es así, ¿o no?

@oriSomething Si te entendí correctamente, Relay hará todo lo posible sobre la normalización de datos en el cliente y la fusión de datos de consultas en una sola tienda.

@oriSomething sí, lo hace => https://facebook.github.io/relay/img/Guides-Containers-HOC-Relay.png
Verificar: https://facebook.github.io/relay/docs/guides-ready-state.html#content

Solo si no hay datos suficientes en el cliente, Relay envía una solicitud al servidor para obtener más datos.

Redux tiene un nivel mucho más bajo que Relay, y no es más "pasado" que los objetos y funciones JS simples son "pasados". Relay es un marco, y Redux, sin los controles de cordura, tiene diez funciones de 10 líneas, por lo que no debería sorprender que tengan diferentes alcances.

Así que hice slim-redux.js solo por diversión, una versión de Redux sin comentarios, advertencias para los desarrolladores y controles de cordura. Pasa todas las pruebas esenciales de Redux (excepto las de comprobación de cordura) y tiene 99 líneas: wink:. Esto debería sellar mi punto de que Relay y Redux son herramientas con alcances tremendamente diferentes.

@IwanKaramazow creo que no fui lo suficientemente claro, lo que estoy tratando de decir es que no todos los datos son sobre el servidor, hay datos que no están relacionados con el servidor para administrar, y realmente no creo que la retransmisión es la "herramienta" a la que acudir incluso si puede administrar estos datos

@ori¿Algo me puedes dar un ejemplo?

Totalmente de acuerdo @mattapperson . Todo se reduce a la definición de complejo, o mejor, a donde cada individuo reconoce una "cosa compleja"

@IwanKaramazow Creo que @oriSomething habla sobre el estado del formulario del lado del cliente, por ejemplo

Me mudé de Redux => Relay debido a GraphQL. Casi todos los recursos de mi aplicación eran jerárquicos. Naturalmente, tenían sentido ser entidades anidadas. Mantener un caché de estos modelos en Redux fue increíble. Tenía una vista sana de mis datos y podía iterar rápidamente con las increíbles herramientas redux-devtools.

Pero sin GraphQL, tuve que hacer varios viajes de ida y vuelta para asignar recursos remotos al árbol redux.

1. / lista-recurso1
2. / resource2-list? resource1 =
3. / resource3-list? resource2 =

Obviamente, este es un problema con REST, no con Redux. Si hubiera visto algunos enlaces de Redux-GraphQL antes, tal vez los estaría usando. La adopción de Relay cambió muy poco en mi aplicación. En lugar de @connect estoy usando Relay.createContainer . Ambos productos tienen la misma visión de la arquitectura con diferentes API. Escribí una publicación rápida sobre esto.

Actualmente estoy usando tanto redux como relay / graphql y aunque el relay es increíble para la obtención de datos, puedo verme siempre usando redux. Actualmente uso redux por 2 razones y puedo verme encontrando más razones en el futuro

1) Estado misceláneo que debe compartirse entre componentes que no viven en la base de datos
2) Preparación de formularios. De hecho, tengo una parte de mi aplicación en la que tengo un componente de barra de herramientas que tiene un botón de envío y un componente de panel que contiene todos mis campos de entrada. Cuando escribo el formulario, elimino mi entrada en un "reductor de formularios" almacenado en redux para que mi barra de herramientas pueda tener acceso a los datos antes de enviarlos.

Además, redux devtools es increíble.

Hombre, oh hombre. Hoy he estado leyendo sobre Relay y debo admitir que el código no es fácil de leer ni de entender. Miré algunos ejemplos de Redux y pude comprender los conceptos básicos con solo leer el código.

El tutorial o el ejemplo de Todo parecen todo menos elegantes. Creo que React y FLUX se enorgullecen de ser simples. Todavía no tengo esa sensación de Relay.

Dados los fuertes vínculos de Relay con React y la relativa excesiva complejidad para la mayoría de las aplicaciones, últimamente he estado más interesado en Falcor. De hecho, debido a su interfaz basada en promesas, encaja muy bien con la forma en que realiza la mayoría de los comportamientos asincrónicos en Redux. Y debido a que está desacoplado de React, puedo usarlo en cualquier lugar de mi aplicación más fácilmente. Además, la renderización del lado del servidor aún no está completamente preparada , lo cual

También me gusta react-resolver , que es una especie de "Relay Lite". Ese puede terminar siendo el mejor para proyectos muy simples o aquellos que dependen de API REST de terceros.

@timdorr ¿Ha intentado almacenar todo su estado en Falcor? Hacer que sus reductores utilicen un objeto Falcor, por ejemplo.

Aún no. Todavía estoy en modo experimental con él y tengo peces más grandes para freír en mis proyectos, por lo que aún no le he prestado suficiente atención.

He jugado con Falcor y lo recomiendo mucho. De hecho, estoy trabajando en la integración de una aplicación Redux con un backend de Falcor en este momento. No le proporciona la agregación de consultas de Relay, pero tiene una capa de caché muy sofisticada en su biblioteca de cliente que evita la captación excesiva. Creo que eso puede ser suficiente, pero el tiempo lo dirá.

@gaearon ¿cómo se obtención de datos declarativos con escribir la misma aplicación en Elm?

Me parece que la principal diferencia es que la búsqueda de datos es más declarativa con Relay & GraphQL (Elm le pide que especifique una URL, y depende de usted ordenar los datos que regresan), y todo lo demás es más declarativo en Elm .

En realidad, parece que el ecosistema Elm podría beneficiarse de un puerto de Relay / GraphQL.

En lo que respecta a la agregación de consultas, existe el método Model.batch . Toma un intervalo (en milisegundos) o un programador, pero no encuentro mucha documentación sobre programadores.

Si no le importa que le pregunte, ¿cómo está integrando Redux y Falcor? Todos mis intentos me han dejado frustrado.

También me interesaría ver un ejemplo de redux Falcor. He leído todos los documentos de Falor y estoy de acuerdo en que es mucho más simple que relay / graphql. Aunque menos poderoso.

Para cualquiera que se pregunte acerca de la relación de Redux con Relay, y si tiene sentido usarlos juntos, consulte: https://github.com/facebook/relay/issues/114

La esencia es que Relay eventualmente manejará datos de múltiples fuentes (backend, datos efímeros locales, etc.), por lo que reemplaza otras implementaciones de Flux que pueda estar usando.

https://github.com/facebook/relay/issues/168#issuecomment -135169255:

Tenga en cuenta que Relay es una implementación del patrón Flux (¿puede Flux reemplazarse a sí mismo? ;-).

Estamos usando mucho Redux y Relay en OpenGov. Es cierto que desde que se mudó a Relay, nuestra carpeta reducers/ ha vuelto mucho más pequeña. Sin embargo, hemos descubierto que Redux sigue siendo bastante útil para la gestión estatal local a nivel de aplicación. Quizás algún día Relay lo suplante también en esa área. Pero como dijo @josephsavona una vez, la "arquitectura Redux" es realmente solo ... funciones :) Incluso si un día pasa de Redux a la biblioteca, es probable que continúe usando actualizaciones de estado inmutables, flujo de datos reactivo, reductor funciones, etc. para el futuro previsible. Esa es la parte valiosa de Redux IMO, no necesariamente la biblioteca de <100 líneas que existe en este repositorio. (Ah, y la comunidad, por supuesto).

Yo diría que si su aplicación tiene muchos datos al estilo de Facebook (muchas entidades anidadas con relaciones complejas) es una buena idea invertir en un backend GraphQL y aprender Relay.

De acuerdo, pero diría que GraphQL + Relay es una buena inversión incluso para aplicaciones de tamaño modesto, especialmente para proyectos nuevos que comienzan desde cero.

¿Qué piensan ustedes de https://github.com/gyzerok/adrenaline?

No es exactamente apropiado, porque no usa Relay, pero ¿qué piensas de este enfoque obstinado de pila completa de la comunidad de meteoritos? https://github.com/mattkrick/meatier

Solo una arquitectura profunda como GraphQL / Relay o Datomic / Om.Next puede resolver el problema de impedancia relacional / objeto ... Aquí están mis pensamientos: se agradecen los comentarios.

GraphQL / Relay: ¿El fin de Redux?

Parece que hay mucha gente interesada en este tema (Relay / Redux, GraphQL y reducción de la complejidad). Estoy trabajando en un diseño para un cliente GraphQL simple pero funcional que funcionará muy bien con el enfoque Redux del estado de la aplicación.

Es curioso lo que piensa la gente sobre este conjunto de principios de diseño: https://github.com/apollostack/apollo-client/pull/7/files?short_path=83772ba

Solo agrego mis 2 centavos aquí: no creo que haya un final para Redux. Es simple y hermoso, y suficiente en muchos casos. El ecosistema JS es tan rápido y difícil de mantener, y Redux, como React de alguna manera, es un hito en el que podemos confiar durante algún tiempo. Simplemente no podemos hacer evolucionar nuestro flujo de trabajo todos los meses (o al menos yo no puedo), y creo que Redux es una buena opción en este momento. La retransmisión (y la obtención de datos en general) simplemente no es necesaria en muchos proyectos ...

@gaearon han pasado algunos meses desde que hiciste esta publicación, y acabas de dar una charla sobre Redux en una conferencia de React. ¿Dónde diría que estamos ahora en términos de integración GraphQL con Redux en comparación con Relay /, o quizás una combinación de los tres?

@likeabbas si está buscando la integración GraphQL-Redux, pruebe Apollo Client: http://docs.apollostack.com/apollo-client/index.html

Todavía no tenemos una paridad de funciones del 100% con Relay, pero nos estamos acercando.

@gaearon para hacerse eco de la pregunta de @likeabbas : "¿Dónde diría que estamos ahora en términos de integración de GraphQL con Redux en comparación con Relay /, o quizás una combinación de los tres?"

Un par de breves pensamientos. Redux es un marco genérico que proporciona un equilibrio entre la estructura suficiente y la flexibilidad suficiente. Como tal, proporciona una plataforma para que los desarrolladores creen una administración de estado personalizada para sus casos de uso, mientras pueden reutilizar cosas como el depurador gráfico o el middleware. Ese caso de uso no parece probable que desaparezca, así que en lugar de "ha llegado y se ha ido el tiempo de Redux", quizás una pregunta más interesante sería: si está construyendo un cliente GraphQL, ¿tiene sentido construir sobre Redux?

A lo que respondería que no está claro que haya una respuesta correcta. Construir sobre Redux puede beneficiarse de la integración (herramientas compartidas, datos compartidos), mientras que construir un enfoque personalizado es más trabajo pero permite más herramientas específicas de dominio y puede permitir un mejor rendimiento. Como ocurre con muchas cosas en el desarrollo de software, ¡depende del caso de uso!

@josephsavona : ¡ese es un gran resumen de Redux! Es posible que tengamos que robar eso para los documentos en algún lugar :)

Sí, el título de este hilo no es el óptimo, y parece que la pregunta se ha agotado un poco. Quizás sea el momento de trasladar la discusión a otra parte.

>.> lock the issue

Cerraré esto. No estoy seguro de si se va a tener alguna resolución de todos modos. Redux funciona para algunas personas y eso es lo suficientemente bueno para mí.

Vaya, botón equivocado. Lo siento por eso 😄