Pasar accesorios al componente principal en React.js

Editar : consulte los ejemplos finales para ver ejemplos actualizados de ES6.

Esta respuesta simplemente maneja el caso de relación directa entre padres e hijos. Cuando padre e hijo tengan potencialmente muchos intermediarios, consulte esta respuesta .

Otras soluciones no entienden el punto

Si bien todavía funcionan bien, a otras respuestas les falta algo muy importante.

¿No existe una forma sencilla de pasar los accesorios de un niño a sus padres mediante eventos en React.js?

¡El padre ya tiene ese accesorio infantil! : si el niño tiene un accesorio, entonces es porque su padre le proporcionó ese accesorio al niño. ¿Por qué quiere que el niño le devuelva el accesorio al padre, mientras que el padre obviamente ya tiene ese accesorio?

Mejor implementación

Niño : realmente no tiene por qué ser más complicado que eso.

var Child = React.createClass({
  render: function () {
    return <button onClick={this.props.onClick}>{this.props.text}</button>;
  },
});

Padre con un solo hijo : usando el valor que le pasa al niño

var Parent = React.createClass({
  getInitialState: function() {
     return {childText: "Click me! (parent prop)"};
  },
  render: function () {
    return (
      <Child onClick={this.handleChildClick} text={this.state.childText}/>
    );
  },
  handleChildClick: function(event) {
     // You can access the prop you pass to the children 
     // because you already have it! 
     // Here you have it in state but it could also be
     //  in props, coming from another parent.
     alert("The Child button text is: " + this.state.childText);
     // You can also access the target of the click here 
     // if you want to do some magic stuff
     alert("The Child HTML is: " + event.target.outerHTML);
  }
});

JsFiddle

Padre con lista de hijos : todavía tienes todo lo que necesitas sobre el padre y no necesitas complicar más al niño.

var Parent = React.createClass({
  getInitialState: function() {
     return {childrenData: [
         {childText: "Click me 1!", childNumber: 1},
         {childText: "Click me 2!", childNumber: 2}
     ]};
  },
  render: function () {
    var children = this.state.childrenData.map(function(childData,childIndex) {
        return <Child onClick={this.handleChildClick.bind(null,childData)} text={childData.childText}/>;
    }.bind(this));
    return <div>{children}</div>;
  },

  handleChildClick: function(childData,event) {
     alert("The Child button data is: " + childData.childText + " - " + childData.childNumber);
     alert("The Child HTML is: " + event.target.outerHTML);
  }
});

JsFiddle

También es posible utilizar this.handleChildClick.bind(null,childIndex)y luego utilizar.this.state.childrenData[childIndex]

Tenga en cuenta que estamos vinculando con un nullcontexto porque, de lo contrario, React emite una advertencia relacionada con su sistema de vinculación automática . Usar nulo significa que no desea cambiar el contexto de la función. Ver también .

Acerca de la encapsulación y el acoplamiento en otras respuestas

Para mí, esto es una mala idea en términos de acoplamiento y encapsulación:

var Parent = React.createClass({
  handleClick: function(childComponent) {
     // using childComponent.props
     // using childComponent.refs.button
     // or anything else using childComponent
  },
  render: function() {
    <Child onClick={this.handleClick} />
  }
});

Uso de accesorios : como expliqué anteriormente, ya tienes los accesorios en el padre, por lo que es inútil pasar todo el componente secundario para acceder a los accesorios.

Usando referencias : ya tienes el objetivo de clic en el evento y, en la mayoría de los casos, esto es suficiente. Además, podría haber utilizado una referencia directamente sobre el niño:

<Child ref="theChild" .../>

Y acceda al nodo DOM en el padre con

React.findDOMNode(this.refs.theChild)

Para casos más avanzados en los que desea acceder a varias referencias del hijo en el padre, el hijo podría pasar todos los nodos dom directamente en la devolución de llamada.

El componente tiene una interfaz (accesorios) y el padre no debe asumir nada sobre el funcionamiento interno del hijo, incluida su estructura DOM interna o para qué nodos DOM declara referencias. Que un padre utilice una referencia de un niño significa que acopla estrechamente los 2 componentes.

Para ilustrar el problema, tomaré esta cita sobre Shadow DOM , que se usa dentro de los navegadores para representar elementos como controles deslizantes, barras de desplazamiento, reproductores de video...:

Crearon un límite entre lo que usted, el desarrollador web, puede alcanzar y lo que se considera detalles de implementación, por lo que es inaccesible para usted. El navegador, sin embargo, puede traspasar este límite a voluntad. Con este límite establecido, pudieron crear todos los elementos HTML utilizando las mismas tecnologías web antiguas, a partir de divs y spans tal como lo haría usted.

El problema es que si permite que los detalles de la implementación secundaria se filtren al padre, será muy difícil refactorizar al hijo sin afectar al padre. Esto significa que, como autor de una biblioteca (o como editor de navegador con Shadow DOM), esto es muy peligroso porque permite que el cliente acceda demasiado, lo que hace que sea muy difícil actualizar el código sin romper la retrocompatibilidad.

Si Chrome hubiera implementado su barra de desplazamiento permitiendo al cliente acceder a los nodos dom internos de esa barra de desplazamiento, esto significa que el cliente puede tener la posibilidad de simplemente romper esa barra de desplazamiento, y que las aplicaciones se romperían más fácilmente cuando Chrome realice su actualización automática después de refactorizar el barra de desplazamiento... En cambio, solo dan acceso a algunas cosas seguras como personalizar algunas partes de la barra de desplazamiento con CSS.

Sobre usar cualquier otra cosa

Pasar todo el componente en la devolución de llamada es peligroso y puede llevar a los desarrolladores novatos a hacer cosas muy raras como llamar childComponent.setState(...)a or childComponent.forceUpdate()o asignarle nuevas variables dentro del padre, lo que hace que sea mucho más difícil razonar sobre toda la aplicación.

Editar: ejemplos de ES6

Como mucha gente ahora usa ES6, aquí hay los mismos ejemplos para la sintaxis de ES6

El niño puede ser muy simple:

const Child = ({
  onClick, 
  text
}) => (
  <button onClick={onClick}>
    {text}
  </button>
)

El padre puede ser una clase (y eventualmente puede administrar el estado mismo, pero lo paso como accesorios aquí:

class Parent1 extends React.Component {
  handleChildClick(childData,event) {
     alert("The Child button data is: " + childData.childText + " - " + childData.childNumber);
     alert("The Child HTML is: " + event.target.outerHTML);
  }
  render() {
    return (
      <div>
        {this.props.childrenData.map(child => (
          <Child
            key={child.childNumber}
            text={child.childText} 
            onClick={e => this.handleChildClick(child,e)}
          />
        ))}
      </div>
    );
  }
}

Pero también se puede simplificar si no es necesario gestionar el estado:

const Parent2 = ({childrenData}) => (
  <div>
     {childrenData.map(child => (
       <Child
         key={child.childNumber}
         text={child.childText} 
         onClick={e => {
            alert("The Child button data is: " + child.childText + " - " + child.childNumber);
                    alert("The Child HTML is: " + e.target.outerHTML);
         }}
       />
     ))}
  </div>
)

JsFiddle

ADVERTENCIA DE RENDIMIENTO (se aplica a ES5/ES6): si está utilizando PureComponento shouldComponentUpdate, las implementaciones anteriores no se optimizarán de forma predeterminada porque se usan onClick={e => doSomething()}o se vinculan directamente durante la fase de renderizado, ya que creará una nueva función cada vez que el padre renderice. Si esto es un cuello de botella de rendimiento en su aplicación, puede pasar los datos a los hijos y reinyectarlos dentro de una devolución de llamada "estable" (configurada en la clase principal y vinculada al thisconstructor de la clase) para que PureComponentla optimización pueda activarse, o usted Puede implementar el suyo propio shouldComponentUpdatee ignorar la devolución de llamada en la verificación de comparación de accesorios.

También puede utilizar la biblioteca Recompose , que proporciona componentes de orden superior para lograr optimizaciones precisas:

// A component that is expensive to render
const ExpensiveComponent = ({ propA, propB }) => {...}

// Optimized version of same component, using shallow comparison of props
// Same effect as React's PureRenderMixin
const OptimizedComponent = pure(ExpensiveComponent)

// Even more optimized: only updates if specific prop keys have changed
const HyperOptimizedComponent = onlyUpdateForKeys(['propA', 'propB'])(ExpensiveComponent)

En este caso, podría optimizar el componente secundario utilizando:

const OptimizedChild = onlyUpdateForKeys(['text'])(Child)

Jul 31 '2015 23:07 Sebastien Lorber