Redux: ¿Dónde está el "término medio" entre componentes inteligentes y componentes tontos?

Creado en 19 abr. 2016 · 3Comentarios · Fuente: reduxjs/redux

He estado viendo los tutoriales de Dan's Redux sobre egghead y recuerdo un consejo: si el componente principal no usa algunos datos pero los necesita solo para pasar a los niños, no lo haga. Use connect sobre el componente secundario que necesite estos datos.

Me gusta este consejo porque odio pasar toneladas de datos a través de accesorios. Pensé que este es un enfoque de uso común, pero recientemente estaba implementando el proyecto "mini twitter" como asignación de prueba para la empresa que usa redux en su proyecto y es por eso que quiero trabajar allí.

Pero mi código fue rechazado porque "React-way también tiene un máximo de componentes tontos". ¿Es eso cierto?
Aquí está mi código si alguien quiere echar un vistazo https://bitbucket.org/amorphius/minitwitter/overview
Entonces, la razón por la que fue reconocido como un código incorrecto es que hay demasiados connect en el código.

¿Dónde está el medio feliz?

question

Fuente

amorphius

Comentario más útil

Solíamos decir que tener menos componentes conectados es mejor en las versiones anteriores de los documentos, pero no anticipé cuánto se convertiría en un culto de carga. 😞 Sí, conectar todos los componentes suele ser una exageración, ¡pero también lo es poner todo en la parte superior! Conectarse solo por obtener dispatch es especialmente inofensivo, por lo que no debe sentirse mal por hacer esto con frecuencia.

Tu código se ve absolutamente bien para mí. 👍

gaearon en 19 abr. 2016

👍4 ❤3

Todos 3 comentarios

Tu código se ve absolutamente bien para mí. 👍

gaearon en 19 abr. 2016

👍4 ❤3

Gracias. Al menos ahora tengo un fuerte argumento de que mi código está bien y probablemente consiga un trabajo en una mejor compañía :)

Pero aún no puedo imaginar el escenario donde connect es excesivo. Cómo desarrollar esta habilidad para saber qué regla tengo que romper, ya sea para pasar datos del control principal que no usa estos datos al control secundario o para tener otro connect en el código (especialmente si lee una pequeña cantidad de datos de la tienda)?

¿Qué tipo de problemas surgirán con muchos connect en la aplicación?

amorphius en 19 abr. 2016

El proceso de notificación de suscriptores de Redux es un ciclo simple que ejecuta cada devolución de llamada de suscriptor, por lo que obviamente eso es O (n). En teoría, si las devoluciones de llamada de los suscriptores están haciendo algo complejo, o si el número de suscriptores crece _muy_ grande, eso podría convertirse en un problema de rendimiento.

En la práctica, probablemente no sea una gran preocupación. Sospecho que tendrías que tener varios miles de suscripciones activas, con muchas acciones despachadas por segundo, antes de que realmente se convierta en un problema. Sin embargo, no conozco ningún punto de referencia específico al que pueda señalar para verificar eso (a menos que tal vez se relacione la comparación reciente de MobX / Redux).

En general, creo que debería estar seguro siguiendo el enfoque clásico de "hazlo funcionar, hazlo bien, hazlo rápido". Escriba código que haga que las características de su aplicación funcionen correctamente. Mire lo que ha escrito y ajuste la estructura si es necesario para que tenga más sentido. Si parece lento, mida y compare y corrija las partes que son realmente lentas.