para - reactjs redux

¿Por qué redux sugiere conectarse solo a componentes de nivel superior?

Question

Soy nuevo en redux y reaccion-redux, mientras tanto estoy tratando de hacer una aplicación redux.

No entiendo la declaración en el documento de redux:

Luego, envolvemos los componentes que queremos conectar a Redux con la función connect () de reaccion-redux. Intente hacer esto solo para un componente de nivel superior o controladores de ruta. Aunque técnicamente puede conectar () cualquier componente en su aplicación a la tienda Redux, evite hacer esto demasiado profundamente, ya que hará que el flujo de datos sea más difícil de rastrear.

¿No es más fácil conectarse a todos los componentes y cuando se actualiza el estado, cada componente puede obtener el nuevo árbol de estados?

¿Por qué componentes tontos y contenedores de alto nivel?

Gracias.

Answer 1

Cuando tenía un contenedor en la parte superior, tenía problemas de eficiencia porque React había reenviado todos mis componentes durante la más mínima actualización en algún lugar del árbol. Así que abandoné ese enfoque e hice mi aplicación contra los documentos, lo que resultó ser más rápido.

Pero luego he visto que incluso el autor de Redux escribió en su Twitter:

Enfatizar "un componente contenedor en la parte superior" en los ejemplos de Redux fue un error. No tomes esto como una máxima.

https://twitter.com/dan_abramov/status/668585589609005056

y

Trate de mantener sus componentes de presentación separados. Cree componentes de contenedor conectándolos cuando sea conveniente. https://twitter.com/dan_abramov/status/668586001175048192

Answer 2

En algunos casos, puede usar componentes connect() ed más abajo. No interpretaría la documentación tan estrictamente.

En general, si te encuentras con demasiados elementos de apoyo de tus componentes y los componentes que realizan el paso no están utilizando esos accesorios, entonces se pueden mover a un componente contenedor separado.

Si te encuentras constantemente escribiendo accesorios en una cadena de componentes, podría ser el momento de agregar un contenedor:

// A blog post view component
render () {
  const {post} = this.props;

  return (
    <div>
      <h1>{post.title}</h1>

      <Author author={this.props.author}
        onClick={this.props.favAuthor}
        onHover={this.props.authorDetails}
        isAuthorFaved={this.props.isAuthorFaved}
        isAuthorFollowed={this.props.isAuthorFollowed}/>
    </div>
  )
}

En este caso, el componente de publicación no tiene ningún uso o necesidad de los accesorios utilizados para <Author/> . Es posible que desee considerar crear un <AuthorContainer author={this.props.author}/> lugar. El autor pertenece a la publicación, por lo que necesitará esa información. El resto se puede calcular usando el estado en la función mapStateToProps(state, ownProps) donde ownProps.author es el objeto autor.

Nuevamente, este es un ejemplo artificial, pero en realidad depende de usted a dónde pertenece la lógica.

Answer 3

La respuesta está en esta sección de su extracto de los documentos:

Aunque técnicamente puede conectar () cualquier componente en su aplicación a la tienda Redux, evite hacer esto demasiado profundamente, ya que hará que el flujo de datos sea más difícil de rastrear.

Uno de los principios básicos de Redux es que los datos generalmente deben fluir de arriba hacia abajo, es decir, deben ser unidireccionales. Si connect demasiados componentes de nivel inferior, su flujo de datos ya no es unidireccional. La principal consecuencia de esto es que es mucho más fácil tener un estado inconsistente entre sus componentes.

Cuando va de arriba hacia abajo, que es lo que ocurre naturalmente cuando solo conecta un número limitado de componentes de alto nivel, es mucho más difícil crear situaciones en las que tenga un estado inconsistente, de ahí el consejo en los documentos.

Answer 4

Como se mencionó, Abramov (autor de Redux) ha seguido su consejo sobre los componentes de connect() ed. Él articula una buena regla general en esta publicación de Reddit sobre el tema :

Lo hago de esta manera:

1. Comience utilizando un contenedor y varios componentes de presentación

2. A medida que el árbol de componentes de presentación crece, los componentes "medios" comienzan a pasar demasiados elementos hacia abajo

3. En este punto, envuelvo algunos componentes de hoja en contenedores para que los componentes "intermedios" no tengan que aceptar y pasar los accesorios que no están relacionados con ellos.

4. Repetir

Si ves los últimos diez videos de mi curso en Egghead, este es exactamente el enfoque que demuestro: https://egghead.io/series/getting-started-with-redux

Desde mi lectura, el consejo inicial sobre connect() no tenía nada que ver con el rendimiento y todo lo relacionado con los componentes modulares y la facilidad de razonamiento sobre el flujo de datos en aplicaciones más grandes.

De hecho, más componentes de connect() ed pueden ser una ventaja de rendimiento en comparación con el patrón más pesado de 1 contenedor-a-regla-ellos-todos. Abramov una vez más :

Ambos enfoques están bien, y tener componentes conectados () anidados en realidad le dará más rendimiento. La desventaja es que están un poco más acoplados a la aplicación y un poco más difíciles de probar, pero eso puede no ser un gran problema.