Nuestros mejores investigadores han agotado sus depósitos de café, en su búsqueda día y noche por la solución, hasta que Víctor encontró la solución en Bitbucket por lo tanto hoy la compartimos aquí.
Solución:
Tratar:
var Wrapper = React.createClass(
render: function()
return (
before
this.props.children
after
);
);
Consulte Componentes múltiples: elementos secundarios y tipo de accesorios secundarios en los documentos para obtener más información.
Esto también se conoce como transclusion en Angular.
children es un accesorio especial en React y contendrá lo que está dentro de las etiquetas de su componente (aquí está dentro Wrapper, entonces es el children
Tenga en cuenta que no es necesario que utilice children, que es único para un componente, y también puede usar accesorios normales si lo desea, o mezclar accesorios y elementos secundarios:
const AppLayout = (header,footer,children) => (
header
children
footer
);
const appElement = (
header
footer=
footer
>
body
);
render(appElement,node);
Esto es simple y está bien para muchos casos de uso, y lo recomendaría para la mayoría de las aplicaciones de consumo.
hacer accesorios
Es posible pasar funciones de renderizado a un componente, este patrón generalmente se llama render prop, y el children prop se usa a menudo para proporcionar esa devolución de llamada.
Este patrón no está diseñado para el diseño. El componente contenedor se usa generalmente para mantener y administrar algún estado e inyectarlo en sus funciones de renderizado.
Ejemplo de contador:
const Counter = () => (
(val, set) => (
set(val + 1)>
clicked val times
)
);
Puede ser aún más elegante e incluso proporcionar un objeto.
loading: () =>
...
,
success: (data) =>
data.something
,
error: (e) =>
e.message
,
Tenga en cuenta que no es necesario que utilice children, es cuestión de gustos / API.
...
renderSuccess=(data) =>
data.something
renderError=(e) =>
e.message
/>
A día de hoy, muchas bibliotecas están usando accesorios de renderización (contexto de reacción, movimiento de reacción, Apollo …) porque la gente tiende a encontrar esta API más fácil que las HOC. react-powerplug es una colección de componentes sencillos de render-prop. react-adopt te ayuda a hacer la composición.
Un componente de orden superior / HOC es generalmente una función que toma un componente y devuelve un nuevo componente.
Usar un componente de orden superior puede ser más eficaz que usar children o render props, porque la envoltura puede tener la capacidad de cortocircuitar el renderizado un paso adelante con shouldComponentUpdate.
Aquí estamos usando PureComponent. Al volver a renderizar la aplicación, si el WrappedApp name prop no cambia con el tiempo, el contenedor tiene la capacidad de decir “No necesito renderizar porque los props (en realidad, el nombre) son los mismos que antes”. Con el children solución basada en arriba, incluso si la envoltura es PureComponent, no es el caso porque el elemento secundario se vuelve a crear cada vez que el elemento primario se procesa, lo que significa que el contenedor probablemente siempre se volverá a procesar, incluso si el componente envuelto es puro. Existe un complemento de babel que puede ayudar a mitigar esto y garantizar una constante children elemento a lo largo del tiempo.
Conclusión
Los componentes de orden superior pueden ofrecerle un mejor rendimiento. No es tan complicado, pero ciertamente parece poco amistoso al principio.
No migre todo su código base a HOC después de leer esto. Solo recuerde que en las rutas críticas de su aplicación, es posible que desee usar HOC en lugar de contenedores de tiempo de ejecución por razones de rendimiento, especialmente si el mismo contenedor se usa muchas veces, vale la pena considerar convertirlo en un HOC.
Redux usó al principio un contenedor de tiempo de ejecución y luego cambió a un HOC connect(options)(Comp) por razones de rendimiento (de forma predeterminada, el contenedor es puro y se usa shouldComponentUpdate). Esta es la ilustración perfecta de lo que quería resaltar en esta respuesta.
Tenga en cuenta que si un componente tiene una API de apoyo de renderizado, generalmente es fácil crear un HOC sobre él, por lo que si es un autor de lib, primero debe escribir una API de apoyo de renderizado y, finalmente, ofrecer una versión de HOC. Esto es lo que hace Apolo con componente render-prop, y el graphql HOC usándolo.
Personalmente, uso ambos, pero en caso de duda prefiero los HOC porque:
Es más idiomático componerlos (compose(hoc1,hoc2)(Comp)) en comparación con los accesorios de renderizado
Me puede dar mejores actuaciones
Estoy familiarizado con este estilo de programación.
No dudo en usar / crear versiones HOC de mis herramientas favoritas:
Reaccionar Context.Consumer comp
No declarado Subscribe
utilizando graphql HOC de Apolo en lugar de Query hacer prop
En mi opinión, a veces los accesorios de renderización hacen que el código sea más legible, a veces menos … Intento usar la solución más pragmática de acuerdo con las restricciones que tengo. A veces, la legibilidad es más importante que las interpretaciones, a veces no. Elija sabiamente y no siga estrictamente la tendencia de 2018 de convertir todo en accesorios de renderizado.
Además de la respuesta de Sophie, también he encontrado un uso en enviar tipos de componentes secundarios, haciendo algo como esto:
var ListView = React.createClass(
render: function()
var items = this.props.data.map(function(item)
return this.props.delegate(data:item);
.bind(this));
return
items
;
);
var ItemDelegate = React.createClass(
render: function()
return
this.props.data
);
var Wrapper = React.createClass(
render: function()
return
);
Al final de todo puedes encontrar las notas de otros sys admins, tú además eres capaz insertar el tuyo si dominas el tema.
