¿Has echado un vistazo al JS compilado en un proyecto de React?

Las etiquetas JSX se transforman esencialmente en declaraciones React.createElement . Puedes leer los documentos aquí . Esencialmente la sintaxis es:

React.createElement(FunctionOrClassComponent, { props }, ...children)

En los tres ejemplos, esto ocurriría. En los tres ejemplos, los componentes más pequeños son componentes funcionales en lugar de componentes de clase. Es decir, no tienen los métodos de ciclo de vida de React de un componente de clase, pero pueden usar ganchos de React equivalentes, si así lo desea.

Editado: la evaluación (instanciación y representación) depende de su lógica de representación. Si tiene declaraciones de representación condicional o sus funciones devuelven un valor nulo (o menos contenido) en función de ciertas condiciones, entonces, obviamente, está haciendo menos trabajo. Y como señaló correctamente en los comentarios a continuación, cuando asigna un JSX.Element a una variable, eso se evalúa en línea en lugar de como resultado de una función, por lo que eso sucede de inmediato.

Para mí, los tres son enfoques válidos. Para responder a sus preguntas:

• experiencia de desarrollo,
  • para componentes pequeños con estado mínimo, los componentes funcionales como variables o lambdas son convenientes para escribir y leer/analizar fácilmente al revisar el código en una fecha posterior. Cuando un componente se vuelve más complejo, es posible que deba reconsiderar cómo está escrito y tal vez usar componentes de clase.
• cómo los trata el marco,
  • que yo sepa, el marco trata los tres ejemplos de la misma manera en términos de compilación. No estoy seguro acerca de la optimización de renderizado.
• ¿Hay optimizaciones de rendimiento?
  • sus ejemplos no representan nada computacionalmente oneroso, por lo que las opciones de optimización del rendimiento no son tan obvias
• ¿Hay diferencias en los comportamientos de tiempo de ejecución en todos estos?
  • todos se traducen a elementos React, se controlan los cambios de accesorios y se vuelven a renderizar si los padres vuelven a renderizar (si no se emplean cosas como React.memo); puede haber diferencias con respecto a los elementos basados en clases, pero supongo que eso las diferencias de tiempo de ejecución entre sus tres ejemplos son mínimas
• ¿Alguno de los dos es mejor para usar en ciertos escenarios?
  • Las diferencias entre los tres son más una cuestión de estándares o etiqueta que de resultados funcionales. Como desarrollador, podría leer y comprender los tres, pero al trabajar en equipo, me gustaría ver un enfoque estándar.

Método 2:

 function BigComponent(props) { const smallComponent1 = <div>{props.a}</div>; const smallComponent2 = <div>{props.b}</div>; return ( <div> {smallComponent1} {smallComponent2} </div> ) }

• Si desea una interfaz de usuario grande en una interfaz de usuario más pequeña separada, este método le brindará el mejor rendimiento porque
  • Todavía es solo un gran componente de la interfaz de usuario.
  • reaccionar solo hay que resolver las referencias de variables.
  • mientras se vuelve a renderizar, BigComponent, smallComponent1 y smallComponent2 se renderizan juntos como una sola unidad.
  • smallComponent1 y smallComponent2 no pueden tener su propio estado, ciclos de vida y ganchos.
  • smallComponent1 y 2 deben reinicializarse cada vez que se cambia el estado de Bigcomponent. Por lo tanto, es una buena práctica envolverlos con useMemo() si el resultado de esos componentes pequeños proviene de un cálculo costoso.

Método 3:

 function SmallComponent1({ a }) { return <div>{a}</div>; } function SmallComponent2({ b }) { return <div>{b}</div>; } function BigComponent(props) { return ( <div> <SmallComponent1 a={props.a} /> <SmallComponent2 b={props.b} /> </div> ) }

• React necesita resolver la referencia y ejecutar la función después de resolver la referencia.

• Es una composición de los componentes secundarios reales de reaccionar en un componente grande.

• Los componentes secundarios pueden tener sus propios hooks .

• Los componentes secundarios no se reinicializan, pero se vuelven a procesar si se cambia el estado de BigComponent.

• Existe la posibilidad de que SmallComponent1 y SmallComponent2 se vuelvan a renderizar varias veces en el renderizado de BigComponents una vez si los componentes pequeños están actualizando su propio estado en función del cambio de accesorios en los padres.

• si se supone que cada SmallComponents debe usar múltiples accesorios cuyo estado de BigComponents, Keeping SmallComponents fuera de BigComponent ofrece una buena experiencia de desarrollador.

• Espero que el Método 1 y el Método 4 también se puedan entender utilizando estos puntos anteriores.

• Nota: los componentes secundarios almacenados en variables y componentes secundarios como función se vuelven engañosos si la lógica de su aplicación usa ref o elemento DOM para mantener el enfoque o el punto de anclaje de la representación.