This sounds like it should be done now, then rather later on, when it may require a lot of changes, or even make it non viable due to backwards incompatibilities and design decisions.
Exadra37
tme_317
Bummer! Would be great if we could somehow use it on non-LV projects without requiring significant work on core LV. Is there a way to make a new component type like Surface.StaticComponent or something with the current behaviour that doesn’t depend on LiveView?
Just hoping there is an easy way to support this because I much prefer the benefits of using this (so eloquently laid out in your earlier reply) versus EEx in non-LV projects.
0
chrismccord
Creator of Phoenix
You have to pick your battles. Trying to decouple early on will slow down development to accommodate a small fraction of users, so punting on this is something that I’d continue to kick down the road.
1
Exadra37
I see this more as a design choice that can hurt down the road, then a question of decoupling code, but I don’t know the code as well as you 
Are you really sure that is a small fractions of users? Seems that you are over confident that “everyone” will be using LiveView in their projects?
0
chrismccord
Creator of Phoenix
Sorry, I didn’t mean for it to come across that way. Speaking from experience, folks very often push for maintainers to decouple too early in projects, and it almost always is the wrong call. You can get lost in the weeds way too early instead of making forward progress to 1.0. For now, I’d focus on getting the surface model and features intact for its intended purpose.
4
Exadra37
I know that you haven’t said it with that intention, that’s why I used “everyone” between commas
0
msaraiva
Broadway Core Team
Since I’m still working on the core features, I didn’t have time to build a full suite of components yet. However, all examples in my demo were created using Bulma, including a live Dialog component that handles events. As far as I know, there’s also a WIP by @joerichsen using bootstrap.
I understand your concern but I have to agree with @chrismccord on this one. The problem is that having too many different kinds of components at this moment will certainly slow me down. My main goal now is to validate the model in the most complex scenario, which is using stateful components with LV. If everything works as expected, adding a simpler version for non-LV projects will be a breeze, trust me 
I’ll definitely come back to this discussion as soon as I finish Implement a compiler instead of a translator · Issue #15 · surface-ui/surface · GitHub. If until then we have no solution on the LV side and we find out that a lot of people want this feature, I’ll consider creating a new separate Surface.StaticComponent as suggested by @tme_317.
8
regal
is there a way to render a component in a .leex template? I am looking to add a Live Layout, and I believe that means I need to point to a leex file, but if possible I would like to reuse some Surface components in that template. I have tried <%= live_component @socket, MyComponent %> but it appears it is missing some preparation (the :surface value).
0
msaraiva
Broadway Core Team
Hi @regal!
Currently, surface components require some preparation as you noticed. I opened this issue to create a surface_component/3 wrapper that could replace live_component/3 for those cases.
I have a quick question though. Would you still use a .leex file if you could load a .sface file that accepts the surface’s syntax instead? The .sface proposal is described here. I’m trying to list a few possible scenarios where this feature would be useful before start working on it.
Cheers.
2