React-window: Cambiar los accesorios de un elemento actualizará toda la lista

Tengo exactamente el mismo caso de uso y problema, y ​​no he podido encontrar una solución ...

Esto se debe a que cambiar un elemento crea una nueva matriz items que crea un nuevo objeto itemData . Es importante que las técnicas de memorización se invaliden y luego cambien sus datos.

Si desea que los elementos sean más resistentes a este tipo de cambio, puede implementar su propia función areEqual (o shouldComponentUpdate ).

El propósito de la demostración es simplemente mostrar cómo itemData y la memorización pueden trabajar juntos para pasar valores complejos.

Lo había probado con mi propia función shouldComponentUpdate pero esta función no se ejecutará, si el componente se desmonta una y otra vez

si el componente se desmonta una y otra vez

No hay forma de memorizar un componente que se desmonta. Sin embargo, eso no es lo que sucede en mi demostración. Si es lo que sucede en su aplicación, hay algo más, y no puedo especular sobre qué.

@BertelBB ¿Encontraste una solución?

@ffjanhoeck En realidad, no, no. Me di cuenta de que mi caso de uso es en realidad un poco diferente en el sentido de que mi lista también se puede ordenar / filtrar. Lo que hice fue pasar los accesorios itemData y itemKey para configurar manualmente el accesorio clave para cada elemento. La lista completa aún se actualiza, pero no es tan lenta como antes.
https://react-window.now.sh/#/api/FixedSizeList aquí puede leer sobre los accesorios a los que me refiero.

@BertelBB Ya implementé esa función ayer, gracias :)
Pero el problema no se soluciona :(
Aquí hay un GIF que está retrasado: como puede ver, tomó algunos milisegundos verificar un elemento.
Todo está memorizado o tiene un shouldComponentUpdate implementado.

@ffjanhoeck Sí, tengo el mismo problema. Lamentablemente, no tengo tiempo para profundizar en esto a partir de ahora. Pero te haré saber si encuentro una mejor solución :)

@ffjanhoeck ¿ Alguna posibilidad de que pueda echar un vistazo a la aplicación que mostraste en el GIF de arriba? Tendría curiosidad por ejecutar un generador de perfiles y ver de dónde proviene la lentitud.

@bvaughn Sí, claro, ¡le he enviado las credenciales en su correo electrónico! :)

Creo que la lentitud proviene de la breve vista previa de un elemento (la imagen y el texto azul con el texto secundario representan el componente EntityShortPreview). Pero no es un problema para un artículo. El problema es que todos los elementos se desmontan y montan en la selección y, si resume esto, es lento.

Ese es mi sentimiento actual: D Pero tal vez puedas encontrar otros problemas :)

Esto sucede si un usuario selecciona un elemento

@ffjanhoeck Me encontré exactamente con el mismo problema, y ​​después de investigar un poco, logré descubrir la causa: es porque estamos usando funciones anónimas como representadores de elementos, en lugar de componentes con nombre. No soy un gurú de React, pero creo que esto arruina la reconciliación de React, ya que los componentes no son reconociblemente los mismos entre los renders.

Hice un ejemplo de CodeSandbox que ilustra el problema aquí: https://codesandbox.io/s/qx4088mn36

Creo que esto también está relacionado con la conversación aquí: https://github.com/bvaughn/react-window/issues/85#issuecomment -436329610

Eso es lo que estoy viendo también después de un vistazo rápido esta mañana. (Estaba escribiendo un correo electrónico pero me interrumpieron). Mover la función en línea a un accesorio de instancia aceleró las cosas (pero también rompió algunas otras cosas que no tuve tiempo de rastrear debido al tamaño de la carcasa de reproducción).

Creo que esto arruina la reconciliación de React, ya que los componentes no son reconociblemente los mismos entre los renders.

Esto es correcto. 👍

Mmm. Esto es desafortunado, porque estoy escribiendo mi proyecto usando ReasonReact, que (actualmente) carece de las características necesarias de propagación / componente funcional para evitar este problema. Reconozco que esto no es de ninguna manera un problema con react-window, solo una limitación del sistema de tipos de ReasonML, pero supongo que vale la pena mencionarlo en caso de que alguien más se tope con este hilo.

Para ser claros, esta es la razón por la que todos los ejemplos de documentos muestran que la representación del elemento se define fuera del componente principal, y el ejemplo de memorización muestra cómo compartir datos entre los dos. (Básicamente, es como un contexto integrado más ligero).

Genial, ¡echaré un vistazo! :)

¡Su solución solucionó el problema! Gracias y que tenga un buen día