Yeah from a semantic standpoint it makes kind of sense sometimes but it just shows that jsx/xml is not the right abstraction level for the problem at hand.
If you compare xml style syntax to s-expressions there is a clear distinction between child nodes and attributes (a "bi-partite tree", not sure if the term exists). For markup like html where the child-data is the content and the attributes are meta-level annotations this makes sense. Even when looking at guidelikes for "how to design an xml schema/doctype" the responses are often like "use child elements for alle business data and attributes only for technical meta-data".
So from syntactical perspective there is a clear distinction between attributes and child elements. The main one I would say is that attributes are limited in the sub-structure they can contain (only primitive types or space separated lists).
The way react adopted the html/xml like syntax for the creation of javascript objects to allow the declaration of DOM nodes in a nicer way. On top of that react allows the creation of custom elements as functions and allows their usage via the same xml-like syntax.
But now as soon as these custom components have more complicated dependencies between each other the xml syntax gets (imo) misused as a poor dependency-injection layer. It's only possible because JSX allows for non-primitive attribute values and it sticks out like like a sore thumb because the semantics do not match the syntax (like defining a "+" operator that is not commutative).
In my opinion a better way would be curry the component creation or to introduce a real DI-layer for component configuration that is then used to load fully configured components that can then simply be composed in jsx.
If you compare xml style syntax to s-expressions there is a clear distinction between child nodes and attributes (a "bi-partite tree", not sure if the term exists). For markup like html where the child-data is the content and the attributes are meta-level annotations this makes sense. Even when looking at guidelikes for "how to design an xml schema/doctype" the responses are often like "use child elements for alle business data and attributes only for technical meta-data".
So from syntactical perspective there is a clear distinction between attributes and child elements. The main one I would say is that attributes are limited in the sub-structure they can contain (only primitive types or space separated lists).
The way react adopted the html/xml like syntax for the creation of javascript objects to allow the declaration of DOM nodes in a nicer way. On top of that react allows the creation of custom elements as functions and allows their usage via the same xml-like syntax.
But now as soon as these custom components have more complicated dependencies between each other the xml syntax gets (imo) misused as a poor dependency-injection layer. It's only possible because JSX allows for non-primitive attribute values and it sticks out like like a sore thumb because the semantics do not match the syntax (like defining a "+" operator that is not commutative).
In my opinion a better way would be curry the component creation or to introduce a real DI-layer for component configuration that is then used to load fully configured components that can then simply be composed in jsx.