Looks good.

In one of the HEEx examples in this post it mentions components and uses a weather component as an example with: <MyApp.Weather.city name="Kraków"/>

I'm curious, what would the syntax look like if you wanted to create something like a card component that has an optional header, body and footer where you would want your arguments to be blocks of arbitrary HTML that you pass in and not a single string variable?

Basically a way to do something like this (a more simplified version since I don't know what the API would be):

    <Foo name="bar">
        <p>Custom stuff!</p>
    </Foo>

And then the component itself would have a named "yield" that places in your arbitrary blocks of code in the correct spot.

I think this might be called slots in other frameworks, but they seem essential to be able to create re-usable components unless HEEx has an undocumented way to do this? It looks like Surface has this at https://surface-ui.org/slots.

What are the benefits of using HEEx over Surface? I know they're working together and in the end will share similar functionality and maybe Surface will use HEEx under the hood but as an end user building web applications with Phoenix is there a single case where I would use HEEx instead of Surface? If not, why isn't Surface part of core Phoenix or not heavily pushed as what to use for a templating solution in the docs?