React: Preguntas sobre "props.children"

_Estructura de datos opaca_ se refiere al hecho de que children pueden ser muchas cosas: matrices, fragmentos, elementos únicos, cadenas literales, etc.

_React.Children_ contiene algunos métodos que le permiten trabajar con los diferentes tipos de children _ de una manera unificada_, y definitivamente no es la única forma de interactuar con ellos.

¿Por qué exactamente no props.children en caso de que haya algunos hijos (uno o más) solo siempre una matriz (como se hace en "Preact" por ejemplo)?

Aparte del hecho de que tiene una abreviatura en JSX, children es una propiedad como cualquier otra. De hecho, puede especificarlo como:

<Component children={...}/>

Cuando React necesita actualizar el DOM, sería mucho más caro saber si dos matrices de un solo elemento son iguales que si dos valores primitivos (por ejemplo, cadenas) son iguales.

Dicho esto, creo que la documentación de React.Children podría expandirse un poco, pero es un problema para iniciar sesión en el repositorio de

Este artículo puede aclarar un poco las cosas, ¡lo hizo por mí!

Muchas gracias @danburzo por tus respuestas y aclaraciones.
Después de su respuesta, está claro que entendí completamente mal la palabra "opaco" allí.
La documentación de React solo quería decir que la estructura de datos de props.children es un tipo de unión completamente bien definido y que varía en su representación concreta (como siempre lo hacen los tipos de unión).

Acabo de encontrar un problema anterior que trataba exactamente el mismo tema. ¿Me pregunto qué pasó con esos cambios? (Abrí un problema en reactjs.org => reactjs / reactjs.org # 914):

https://github.com/facebook/react/pull/6018/files/91223423410f107ff83a8a6ce3158c488247292f?short_path=ef51787#diff -ef51787305cfed62f6f564284762d4de

Sin embargo, me gustaría volver a hacer la segunda pregunta:
¿Por qué "props.children" NO es una matriz en caso de que haya exactamente UN niño (realmente parece una violación al principio del menor asombro si no conoce el fondo => si el nombre es "niños" o "elementos" o "tokens" que normalmente espera una colección)?
¿Es realmente por motivos de rendimiento? Realmente no puedo ver que el cálculo de "checkResult" a continuación lleve tanto tiempo:

const
  child1 = ...,
  child2 = ...,
  child1IsArray = Array.isArray(child1),
  child2IsArray = Array.isArray(child2),

  checkResult = child1IsArray && child2IsArray
     && child1.length === 1 && child2.length === 1
     && child1[0] === child2[0]; 

Lo siento si volver a preguntar parece un poco molesto, pero me encantaría saber la razón exacta de esa decisión de diseño ...

¡Me alegra poder ayudarte con la primera parte de tu pregunta! Desafortunadamente, en cuanto a por qué los niños solteros no se representan como una matriz de un solo elemento, no tengo una respuesta _exact_. Sin embargo, estaba tratando de señalar que todavía puede pasar válidamente a un solo niño como un accesorio normal (en lugar de la taquigrafía JSX), un hecho que accidentalmente oculté con mi hipótesis de que está relacionado con el rendimiento.

@danburzo Gracias de nuevo por tu respuesta.

Mmh, francamente esperaba que tal vez alguien del equipo de React recordara el motivo real de esa decisión de diseño ...
Porque realmente hay algunos problemas sutiles con el manejo de accesorios de los niños en React.
Por ejemplo, pregúntele a un novato de React si los componentes Test1 y Test2 en el siguiente ejemplo se comportan de la misma manera (usted, como profesional de React, sabe que la respuesta es "no" => Test2 advertirá en DEV sobre las claves faltantes mientras que Test1 no, pero ¿es esto realmente lo que esperarías si fueras un novato?!?)

const
  h = React.createElement,
  Test1 = () => h('div', null, h('br'), h('br')),
  Test2 = () => h('div', { children: [h('br'), h('br')] });

ReactDOM.render(
  h('div', null, h(Test1), h(Test2)),
  document.getElementById('container')
);

Por cierto: si se permitiera Test2, esto tendría algunos beneficios de rendimiento sutiles si está implementando algunos reemplazos de createElement , como alguna función de hiperescripto, por ejemplo.

Otro ejemplo: pregúntele a un novato de React cómo se vería "children: PropTypes ...." si el requisito es que todos los niños deben cumplir una determinada condición. Creo que no sería fácil de responder (al menos para un novato).

Para el equipo de React: Si las razones de la decisión de diseño en cuestión no se conocen realmente o tal vez fueron solo una cuestión de gustos, entonces, por supuesto, no dude en cerrar este problema.

Supongo que la decisión de no usar una matriz para un solo niño se tomó para evitar asignaciones de matriz innecesarias.

Porque realmente hay algunos problemas sutiles con el manejo de accesorios de los niños en React.

Generalmente no recomendamos usar un children prop explícito. La mayoría de los usuarios también usan JSX en lugar de llamar directamente a React.createElement , por lo que los problemas que mencionó no suelen ser un problema.

@aweary Gracias por tu respuesta