Redux: Onde está o "meio termo" entre componentes inteligentes e componentes burros?

Criado em 19 abr. 2016 · 3Comentários · Fonte: reduxjs/redux

Tenho assistido aos tutoriais Redux de Dan sobre egghead e lembro de um conselho que se o componente pai não usa alguns dados, mas precisa deles apenas para passar para as crianças - não faça isso. Use connect sobre o componente filho que precisa desses dados.

Gosto desse conselho porque odeio passar toneladas de dados por meio de adereços. Achei que essa abordagem fosse comumente usada, mas recentemente eu estava implementando o projeto "mini twitter" como tarefa de teste para a empresa que usa redux em seu projeto e é por isso que quero trabalhar lá.

Mas meu código foi rejeitado, pois "o React-way também tem o máximo de componentes burros". Isso é verdade?
Aqui está o meu código se alguém quiser dar uma olhada https://bitbucket.org/amorphius/minitwitter/overview
Portanto, o motivo pelo qual foi reconhecido como código incorreto é que há muitos connect no código.

Onde está o meio-termo?

question

Fonte

amorphius

Comentários muito úteis

Costumávamos dizer que ter menos componentes conectados é melhor nas versões anteriores dos documentos, mas eu não previ o quanto isso se tornaria um culto à carga. 😞 Sim, conectar todos os componentes costuma ser um exagero, mas colocar tudo no topo também é! Conectar-se apenas para obter dispatch é especialmente inofensivo, então você não deve se sentir mal por fazer isso com frequência.

Seu código parece absolutamente bom para mim. 👍

gaearon em 19 abr. 2016

👍4 ❤3

Todos 3 comentários

Seu código parece absolutamente bom para mim. 👍

gaearon em 19 abr. 2016

👍4 ❤3

Obrigado. Pelo menos agora tenho um forte argumento de que meu código está bom e provavelmente conseguirá um emprego em uma empresa melhor :)

Mas ainda não consigo imaginar um cenário em que connect seja um exagero. Como desenvolver essa habilidade para saber qual regra eu tenho que quebrar passar dados do controle pai que não usa esses dados para o controle filho ou ter outro connect no código (especialmente se ele ler um pequeno pedaço de dados da loja)?

Que tipo de problema surgirá com muitos connect no aplicativo?

amorphius em 19 abr. 2016

O processo de notificação de assinante do Redux é um loop simples que executa o retorno de chamada de cada assinante, então é obviamente O (n). Em teoria, se os retornos de chamada dos assinantes estão fazendo algo complexo, ou se o número de assinantes crescer _muito_, isso pode se tornar um problema de desempenho.

Na prática, provavelmente não é muito preocupante. Suspeito que você teria que ter vários milhares de assinaturas ativas, com muitas ações despachando por segundo, antes que se tornasse um problema de forma realista. Não conheço nenhum benchmark específico no momento que pudesse apontar para verificar isso, no entanto (a menos que talvez a recente comparação MobX / Redux esteja relacionada).

De modo geral, acho que você deve se sentir seguro ao seguir a abordagem clássica "faça funcionar, faça direito, faça isso rápido". Escreva código que faça os recursos do seu aplicativo funcionarem corretamente. Veja o que você escreveu e ajuste a estrutura, se necessário, para que faça mais sentido. Se parecer lento, meça, avalie e corrija as partes que estão realmente lentas.