3 ms·
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"/
by nickjj 5y ago
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 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?
- lessthanseventy 5y agoI think this might be what you are looking for: https://hexdocs.pm/phoenix_live_view/Phoenix.Component.html#module-blocks https://hexdocs.pm/phoenix_live_view/Phoenix.Component.html#...
- nickjj 5y agoThanks, I think that would very likely handle the basic case of having 1 block. But in a re-usable card component you might decide to have a title, body and footer block where the footer is optional and perhaps falls back with a default value if it's undefined. Slots with Surface handle this use case based on their docs. I think there's a lot of component use cases where you'd want the idea of having multiple blocks. The docs you linked don't cover if HEEx supports anything like that, or being able to use multiple named blocks in 1 component. I tried to read the source but render_block is a macro and I couldn't proceed to trace it.
- ramchip 5y agoSlots are on the heex roadmap: https://github.com/phoenixframework/phoenix_live_view/issues/1506 https://github.com/phoenixframework/phoenix_live_view/issues... I chose to stick to base LiveView in my apps because it works fine (slots are nice but not essential), and I want to avoid too much API churn and learning curve for other devs on the same team. The best Surface features are being gradually refined and merged into LV. HEEx is a great example of that.