Redux: A hora de Redux veio e se foi

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

Muitas pessoas estão muito felizes com o Redux. Você deve perguntar por aí - não estou realmente qualificado para responder a essa pergunta. Eu diria que se seu aplicativo tiver muitos dados pesados ​​como o Facebook (muitas entidades aninhadas com relacionamentos complexos), é uma boa ideia investir em um back-end GraphQL e aprender Relay. Eu só ouvi coisas boas sobre isso.

Redux é claro é mais explícito e não resolve a busca de dados declarativos para você. Existem tentativas de integrar Redux e GraphQL, mas não posso avaliá-las em relação ao Relay - sei muito pouco sobre isso.

Redux tem um nível muito mais baixo que Relay e não é mais “passado” do que objetos e funções JS simples são “passados”. Relay é um framework, e Redux, sem as verificações de sanidade, tem dez funções de 10 linhas, então não deveria ser uma surpresa que eles tenham escopos diferentes. Escolha o que funciona melhor para você e nos informe.

A busca declarativa de GraphQL é incrível, excelente. No entanto, o Relay ainda tem uma API HoC principalmente, que não é declarativa em si. Se o Relay oferecesse uma API mais flexível, desacoplada da árvore de componentes, uma vinculação Redux adequada poderia ser escrita?

Acho que são 2 tipos de sistemas que resolvem 2 problemas distintos.
Esse tíquete é como carpinteiros perguntando se o tempo do martelo já passou.
Eu diria que os sistemas baseados no Graphql são uma solução com engenharia excessiva para muitos aplicativos, ao contrário, os aplicativos com estruturas de dados complexas são mais provavelmente projetados com engenharia insuficiente se construídos usando redux.

Eu diria que os sistemas baseados no Graphql são uma solução com engenharia excessiva para muitos aplicativos, ao contrário, os aplicativos com estruturas de dados complexas são mais provavelmente projetados com engenharia insuficiente se construídos usando redux.

Boa maneira de coloca-lo; é assim que também me sinto.

@gaearon continue o bom trabalho com o redux! Uma das melhores ferramentas disponíveis! Estou usando em 5 aplicativos grandes e 2 pequenos na minha empresa e estou adorando!

@gaearon continue o bom trabalho com o redux! Uma das melhores ferramentas disponíveis! Estou usando em 5 aplicativos grandes e 2 pequenos na minha empresa e estou adorando!

: 100:

eu acho que eles não são os mesmos:

• relé - para resolver o gerenciamento de busca de dados do servidor
• redux - para resolver o gerenciamento de estado do aplicativo

muitos aplicativos complexos contêm estado que não está relacionado ao servidor que você precisa gerenciar. Eu argumentarei que, se você usar relé, verá que no final também precisará reduxar. de acordo com o oposto, relay parece um ótimo impulso, mas apenas para coisas relacionadas ao servidor

A questão é como o Relay se relaciona com os padrões de projeto inspirados no fluxo? Onde termina o Relay, quando precisamos do Redux? O Relay Flux 2.0 é?

O exemplo Todo Relay: ele torna o redux obsoleto?

Talvez haja uma maneira de dizer ao seu redutor como se mapear de e para o GraphQL e quando? Não dizendo que não seja complexo, mas qual é a maneira mais simples de fazer isso fazer sentido.

Precisa aprender mais sobre o que é Relay. Não são algumas centenas de linhas de código com certeza!

@oriSomething Você não está bem. O Relay também resolve muito o gerenciamento de estado.

@gyzerok, quis dizer o estado do aplicativo do lado do cliente

@oriSomething Sim, estou falando sobre o estado do aplicativo do lado do cliente

@gyzerok, devo ter perdido. você pode me dar um link sobre isso?

@oriSomething não existe um link especial porque o Relay o gerencia implicitamente. Talvez você possa tentar assistir as palestras do FB sobre o Relay. Eles estão falando sobre como o Relay resolve o problema de cache. Cache de aplicativo do lado do cliente = estado. Não me lembro de uma conversa definitiva, desculpe.

@oriSomething o único lugar onde o desenvolvedor deve fazer algum gerenciamento de estado explícito é aqui .

@gyzerok ok, então nesse caso, existe um gerenciamento de estado que não esteja relacionado ao servidor que o relay faz? tanto quanto eu entendo, não, ou é?

@oriSomething Se bem entendi, o Relay faz todas as coisas sobre normalização de dados no cliente e mesclagem de dados de consultas em um único armazenamento.

@oriSomething sim, ele faz => https://facebook.github.io/relay/img/Guides-Containers-HOC-Relay.png
Verifique: https://facebook.github.io/relay/docs/guides-ready-state.html#content

Somente se houver dados insuficientes no cliente, o Relay enviará uma solicitação ao servidor para obter mais dados.

Redux tem um nível muito mais baixo que Relay e não é mais “passado” do que objetos e funções JS simples são “passados”. Relay é um framework, e Redux, sem as verificações de sanidade, tem dez funções de 10 linhas, então não deveria ser uma surpresa que eles tenham escopos diferentes.

Portanto , criei slim-redux.js apenas por diversão - uma versão do Redux sem comentários, avisos de desenvolvedor e verificações de integridade. Ele passa em todos os testes Redux essenciais (exceto os testes de verificação de sanidade) e tem 99 linhas: wink:. Isso deve selar meu ponto de que Relay e Redux são ferramentas com escopos totalmente diferentes.

@IwanKaramazow acho que não foi claro o suficiente, o que estou tentando dizer, nem todos os dados são sobre o servidor, há dados que não estão relacionados ao servidor para gerenciar e eu realmente não acho que relay é a "ferramenta" ir para, mesmo se puder para gerenciar esses dados

@oriAlgo você pode dar um exemplo?

Concordo totalmente com @mattapperson . Tudo se resume à definição de complexo, ou melhor, onde cada indivíduo reconhece uma "coisa complexa"

@IwanKaramazow acho que @oriSomething fala sobre o estado do formulário do lado do cliente, por exemplo

Mudei de Redux => Relay por causa do GraphQL. Quase todos os recursos do meu aplicativo eram hierárquicos. Eles naturalmente faziam sentido serem entidades aninhadas. Manter um cache desses modelos no Redux foi incrível. Eu tinha uma visão sã dos meus dados e podia iterar rapidamente com os incríveis redux-devtools.

Mas sem o GraphQL, tive que fazer várias viagens de ida e volta para mapear recursos remotos para a árvore redux.

1. / resource1-list
2. / lista de recursos2? recurso1 =
3. / lista de recursos3? recurso2 =

Obviamente, este é um problema com REST, não Redux. Se eu tivesse visto algumas ligações Redux-GraphQL antes, talvez eu as estivesse usando. A adoção do Relay mudou muito pouco em meu aplicativo. Em vez de @connect estou usando Relay.createContainer . Ambos os produtos têm a mesma visão de arquitetura com APIs diferentes. Eu escrevi um post rápido sobre isso.

Atualmente, estou usando redux e relay / graphql e, embora relay seja incrível para obtenção de dados, posso me ver sempre usando redux. Atualmente uso redux por 2 razões e posso me ver encontrando mais razões no futuro

1) Estado diverso que precisa ser compartilhado entre componentes que não residem no banco de dados
2) Preparação do formulário. Na verdade, tenho uma parte do meu aplicativo em que tenho um componente da barra de ferramentas com um botão de envio e um componente do painel que contém todos os meus campos de entrada. Quando eu digito no formulário, eu dependo minha entrada em um "redutor de formulário" armazenado em redux para que minha barra de ferramentas possa ter acesso aos dados antes de eu enviar.

Além disso, redux devtools é incrível.

Cara, cara. Eu li sobre o Relay hoje e tenho que admitir que o código não é fácil de ler nem de entender. Eu olhei alguns exemplos do Redux e fui capaz de compreender os principais conceitos apenas lendo o código.

O tutorial ou o exemplo Todo parecem tudo menos elegantes. Acho que o React e o FLUX se orgulham de serem simples. Não tenho essa sensação de Relay ainda.

Dados os fortes laços do Relay com o React e o relativo exagero em complexidade para a maioria dos aplicativos, estou mais interessado no Falcor ultimamente. Na verdade, por causa de sua interface baseada em promessa, ele se encaixa muito bem em como você executa a maioria dos comportamentos assíncronos no Redux. E como é desacoplado do React, posso usá-lo em qualquer lugar no meu aplicativo com mais facilidade. Além disso, a renderização do lado do servidor ainda não está totalmente pronta , o que não é um começo para mim.

Também estou gostando do resolvedor de reação , que é _uma espécie de_ semelhante a um "Relay Lite". Esse pode acabar sendo o melhor para projetos muito simples ou que dependem de APIs REST de terceiros.

@timdorr Você já tentou armazenar todo o seu estado na Falcor? Fazer com que seus redutores usem um objeto Falcor, por exemplo.

Ainda não. Ainda estou em modo experimental com ele e tenho peixes maiores para fritar em meus projetos, então não dei atenção suficiente ainda.

Já brinquei com a Falcor e recomendo muito. Na verdade, estou trabalhando na integração de um aplicativo Redux com um back-end Falcor agora. Ele não fornece a agregação de consulta do Relay, mas possui uma camada de cache muito sofisticada em sua biblioteca cliente que evita o overfetching. Acho que pode ser bom o suficiente, mas o tempo dirá.

@gaearon como escrever um aplicativo da web React com busca de dados declarativos se compara a escrever o mesmo aplicativo no Elm?

Parece-me que a principal diferença é que a busca de dados é mais declarativa com Relay & GraphQL (Elm pede que você especifique um URL e depende de você classificar os dados que retornam), e todo o resto é mais declarativo no Elm .

Na verdade, parece que o ecossistema Elm poderia se beneficiar de uma porta de Relay / GraphQL.

Em relação à agregação de consulta, existe o método Model.batch . Leva um intervalo (em milissegundos) ou um agendador, mas não estou encontrando muita documentação sobre agendadores.

Se você não se importa que eu pergunte, como você está integrando Redux e Falcor? Todas as minhas tentativas me deixaram frustrado.

Eu também estaria interessado em ver um exemplo Redux da Falcor. Eu li todos os documentos do Falor e concordo que é muito mais simples do que relay / graphql. Embora menos poderoso.

Para quem está se perguntando sobre a relação do Redux com o Relay, e se faz sentido usá-los juntos, consulte: https://github.com/facebook/relay/issues/114

O ponto principal é que o Relay irá eventualmente lidar com dados de múltiplas fontes (back-end, dados locais efêmeros, etc.), então ele substitui outras implementações do Flux que você possa estar usando.

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

Observe que o Relay é uma implementação do padrão Flux (o Flux pode se substituir? ;-).

Estamos usando Redux e Relay intensamente no OpenGov. É verdade que, desde a mudança para o Relay, nossa pasta reducers/ ficou muito menor. No entanto, descobrimos que Redux ainda é bastante útil para gerenciamento de estado local em nível de aplicativo. Talvez um dia o Relay o suplante também nessa área. Mas como @josephsavona colocou uma vez, a "arquitetura Redux" é realmente apenas ... funções :) Mesmo se um dia você mudar de Redux a biblioteca, provavelmente continuará a usar atualizações de estado imutáveis, fluxo de dados reativo, redutor funções, etc. para o futuro previsível. Essa é a parte valiosa do Redux IMO, não necessariamente a biblioteca de <100 linhas que existe neste repo. (Ah, e a comunidade, é claro.)

Eu diria que se seu aplicativo tiver muitos dados pesados ​​como o Facebook (muitas entidades aninhadas com relacionamentos complexos), é uma boa ideia investir em um back-end GraphQL e aprender Relay.

Concordo, mas eu diria que GraphQL + Relay é um bom investimento mesmo para aplicativos de tamanho modesto, especialmente para novos projetos que estão começando do zero.

O que vocês acham de https://github.com/gyzerok/adrenaline?

Não é exatamente adequado, porque ele não usa Relay, mas o que você acha dessa abordagem opinativa full-stack da Comunidade Meteor? https://github.com/mattkrick/meatier

Apenas uma arquitetura profunda como GraphQL / Relay ou Datomic / Om.Next pode resolver o problema de impedância de objeto / relacional ... Aqui estão meus pensamentos - feedback apreciado.

GraphQL / Relay: o fim do Redux?

Parece que há muitas pessoas interessadas neste tópico (Relay / Redux, GraphQL e redução da complexidade). Estou trabalhando em um projeto para um cliente GraphQL simples, mas funcional, que funcionará muito bem com a abordagem Redux para o estado do aplicativo.

Curioso para saber o que as pessoas pensam sobre este conjunto de princípios de design: https://github.com/apollostack/apollo-client/pull/7/files?short_path=83772ba

Apenas adicionando meus 2 centavos aqui: eu não acho que o Redux acabou. É simples, bonito e suficiente em muitos casos. O ecossistema JS é tão rápido e difícil de acompanhar, e Redux, como o React de alguma forma, é um marco no qual podemos confiar por algum tempo. Nós simplesmente não podemos evoluir nosso fluxo de trabalho todo mês (ou pelo menos, eu não posso), e eu acho que o Redux é realmente uma boa opção agora. A retransmissão (e a busca de dados em geral) simplesmente não é necessária em muitos projetos ...

@gaearon já se passaram alguns meses desde que você fez este post e acabou de dar uma palestra sobre Redux em uma conferência React. Onde você diria que estamos agora em termos de integração GraphQL com Redux em comparação com Relay /, ou talvez uma combinação dos três?

@likeabbas se estiver procurando por integração GraphQL-Redux, experimente Apollo Client: http://docs.apollostack.com/apollo-client/index.html

Ainda não temos 100% de paridade de recursos com o Relay, mas estamos chegando perto.

@gaearon para ecoar a pergunta de @likeabbas : "Onde você diria que estamos agora em termos de integração GraphQL com Redux em comparação com Relay /, ou talvez uma combinação dos três?"

Alguns pensamentos breves. Redux é uma estrutura genérica que fornece um equilíbrio entre estrutura suficiente e flexibilidade suficiente. Como tal, ele fornece uma plataforma para que os desenvolvedores criem gerenciamento de estado personalizado para seus casos de uso, ao mesmo tempo que podem reutilizar coisas como o depurador gráfico ou middleware. Esse caso de uso não parece provável de desaparecer, então ao invés de "a hora do Redux veio e se foi", talvez uma pergunta mais interessante seja: se você está construindo um cliente GraphQL, faz sentido construir no Redux?

Ao que eu responderia que não está claro que haja uma resposta certa. Construir no Redux pode se beneficiar da integração (ferramentas compartilhadas, dados compartilhados), enquanto construir uma abordagem customizada é mais trabalhosa, mas permite mais ferramentas específicas de domínio e pode permitir melhor desempenho. Como acontece com muitas coisas no desenvolvimento de software, depende do caso de uso!

@josephsavona : esse é um _grande_ resumo do Redux! Podemos ter que roubar para os documentos em algum lugar :)

Sim, o título deste tópico não é o ideal e parece que a questão está meio que esgotada. Talvez seja hora de mover a discussão para outro lugar.

>.> lock the issue

Vou encerrar isso. Não tenho certeza se alguma resolução deve ser obtida de qualquer maneira Redux funciona para algumas pessoas e isso é bom o suficiente para mim.

Opa, botão errado. Desculpe por isso 😄