React-window: Mudar os adereços de um item irá atualizar toda a lista

Tenho exatamente o mesmo caso de uso e problema, e não consegui encontrar uma solução ...

Isso porque alterar um item cria um novo array items que cria um novo objeto itemData . É importante que as técnicas de memoização sejam invalidadas e seus dados sejam alterados.

Se quiser que os itens sejam mais robustos a esse tipo de mudança, você pode implementar sua própria função areEqual (ou shouldComponentUpdate ).

O objetivo da demonstração é apenas mostrar como itemData e a memoização podem trabalhar juntos para passar valores complexos.

Eu testei com minha própria função shouldComponentUpdate, mas esta função não será executada se o componente for desmontado repetidamente

se o componente for desmontado repetidamente

Não há como memorizar um componente que é desmontado. Não é isso que acontece na minha demonstração. Se é o que acontece no seu aplicativo, há algo mais acontecendo - e não posso especular sobre o quê.

@BertelBB Você encontrou uma solução?

@ffjanhoeck Na verdade, não. Percebi que meu caso de uso é um pouco diferente no sentido de que minha lista também pode ser classificada / filtrada. O que eu fiz é que eu passar na itemData e ItemKey adereços para que eu definir manualmente o suporte chave para cada item. A lista inteira ainda é atualizada, mas não está tão atrasada quanto antes.
https://react-window.now.sh/#/api/FixedSizeList aqui você pode ler sobre os adereços que estou me referindo.

@BertelBB Já implementei essa função ontem, obrigado :)
Mas o problema não foi resolvido :(
Aqui está um GIF que está lento - como você pode ver, demorou alguns milissegundos para verificar um item.
Tudo é memoized ou tem um shouldComponentUpdate implementado.

@ffjanhoeck Sim, tem o mesmo problema. Infelizmente, não tenho tempo para examinar isso mais profundamente a partir de agora. Mas eu avisarei se eu encontrar uma solução melhor :)

@ffjanhoeck Alguma chance de eu dar uma olhada no aplicativo que você mostrou no GIF acima? Eu ficaria curioso para executar um profiler e ver de onde vem a lentidão.

@bvaughn Sim, claro - enviei a você as credenciais no seu e-mail! :)

Acho que a lentidão vem da curta visualização de um item (a imagem e o texto em azul com o texto secundário representam o componente EntityShortPreview). Mas não é um problema para um item. O problema é que todos os itens são desmontados e montados no select e, se você somar isso, é lento.

Esse é o meu sentimento atual: D Mas talvez você possa encontrar alguns outros problemas :)

Isso acontece se um usuário selecionar um item

@ffjanhoeck Encontrei exatamente o mesmo problema e, após alguma investigação, consegui descobrir a causa: é porque estamos usando funções anônimas como representantes de itens, em vez de componentes nomeados. Não sou um guru do React, mas acredito que isso atrapalhe a reconciliação do React, já que os componentes não são reconhecivelmente os mesmos entre os renderizadores.

Fiz um exemplo CodeSandbox ilustrando o problema aqui: https://codesandbox.io/s/qx4088mn36

Acredito que isso também esteja relacionado à conversa aqui: https://github.com/bvaughn/react-window/issues/85#issuecomment -436329610

Isso é o que estou vendo também depois de uma rápida olhada esta manhã. (Estava escrevendo um e-mail, mas fui interrompido.) Mover a função inline para uma prop de instância acelerou as coisas, (mas também interrompeu algumas outras coisas que não tive tempo de rastrear devido ao tamanho do caso de reprodução).

Acredito que isso atrapalhe a reconciliação do React, já que os componentes não são reconhecivelmente os mesmos entre os renderizadores.

Isto está certo. 👍

Hmm. Isso é lamentável, porque estou escrevendo meu projeto usando ReasonReact, que (atualmente) não possui os recursos de propagação / componentes funcionais necessários para evitar esse problema. Reconheço que isso não é, de forma alguma, um problema com a janela de reação, apenas uma limitação do sistema de tipos do ReasonML, mas acho que vale a pena mencioná-lo, caso mais alguém tropece neste tópico.

Para ficar claro, é por isso que todos os exemplos de documentos mostram a renderização do item sendo definida fora do componente pai, e o exemplo de memoização mostra como compartilhar dados entre os dois. (Basicamente, é como um contexto integrado mais leve.)

Ótimo, vou dar uma olhada! :)

Sua solução corrigiu o problema! Obrigado e tenha um bom dia