Two things I don't like about the approach taken with these specific examples (and they're related):
- It's harder to see the structure of a page when the parts are composed functionally instead of structurally (i.e. explicit nesting); but functional composition is required because the next step down from components are DOM elements
- This approach makes consistent styling of a large application difficult because it ties business domain views to low-level details like specific DOM elements
(I don't disagree with the patterns themselves, per se. But I wouldn't make them domain specific.)
I'd prefer to code up pages using components designed around a higher level of abstraction: more like UI widgets, and less like business domain specific views. That gives two benefits: increased consistency because there are fewer ways to compose higher level abstractions for a given screen complexity; and it's possible to use nesting more directly, since the nesting won't be so verbose, because the raw materials are higher level abstractions than <span> and <div>, they're more like <DropdownMenu> and <MenuItem>.
(This approach is what we do where I work, only it's been built out of Backbone because that was what was current at the time. It's basically MVVM where the viewmodel is the model for a UI component, rather than anything in the domain of the business. An early anti-pattern in Backbone was to have one-off views for every individual little bit of the page; we found this to make understanding the whole composition very awkward.)
CSS-in-JS libs like https://emotion.sh make "micro-componentization" even easier - pretty much every raw DOM element can be replaced by a domain-relevant/ui-relevant component type. Then if you need to add something beyond styles like state or complex render logic, the consumers don't even know about it because the reference is the same.
- It's harder to see the structure of a page when the parts are composed functionally instead of structurally (i.e. explicit nesting); but functional composition is required because the next step down from components are DOM elements
- This approach makes consistent styling of a large application difficult because it ties business domain views to low-level details like specific DOM elements
(I don't disagree with the patterns themselves, per se. But I wouldn't make them domain specific.)
I'd prefer to code up pages using components designed around a higher level of abstraction: more like UI widgets, and less like business domain specific views. That gives two benefits: increased consistency because there are fewer ways to compose higher level abstractions for a given screen complexity; and it's possible to use nesting more directly, since the nesting won't be so verbose, because the raw materials are higher level abstractions than <span> and <div>, they're more like <DropdownMenu> and <MenuItem>.
(This approach is what we do where I work, only it's been built out of Backbone because that was what was current at the time. It's basically MVVM where the viewmodel is the model for a UI component, rather than anything in the domain of the business. An early anti-pattern in Backbone was to have one-off views for every individual little bit of the page; we found this to make understanding the whole composition very awkward.)