Surface - A component-based library for Phoenix LiveView

[wolfiton]

Thanks for creating this example.

Your demo looks good but too improve it you can use highlight.js for your code snippets

[joerichsen]

Thanks - I have added highlight.js now

[wolfiton]

Glad I could help @joerichsen

[msaraiva]

@joerichsen

Just for fun, I created a demo project with some simple Surface components using Bootstrap.

Awesome! I’ll add it to the “Components” section next time I update the demo.

Thanks!

[ityonemo]

thanks for this detailed explanation. I’ll admit that I, too, was too dense to understand the advantages, but I think I do now. I used to manage some programmers who were programming in react and also had to write react code myself, but didn’t have a full understanding of why it’s so good beyond ‘it’s functional and state management is sane’ so thanks for explaining react better than react does =D

[hauleth]

@msaraiva

Ok, first. I find hard to believe you would think it was a typo since the syntax highlighter uses different colours for HTML tags and components

Only when support for this was coded. Remember that not everybody will use the same editor as you so it can look differently in different editors. Vim for example do not support that AFAIK.

Also not everyone is using syntax highlighting (for example visually impaired people).

@msaraiva

In real life you don’t have to create components with the same name of existing tags

But it can happen, for multiple of reasons:

• simpler transition
• inexperienced developer
• creation of new HTML tag by the w3c in the future

[msaraiva]

@hauleth thanks for pointing those exceptions. It’s important that people have them in mind before adopting any technology. As I said before, there is always a tradeoff.

@hauleth

Remember that not everybody will use the same editor as you so it can look differently in different editors. Vim for example do not support that AFAIK.

Vim does not support it yet. If nobody out there with the required skills to add syntax highlighting for vim gets interested in this library, that probably means that the library itself it’s not as useful as I thought. So if that happens, it’s probably a sign that I should move on and try something else.

@hauleth

But it can happen, for multiple of reasons:

• simpler transition
• inexperienced developer
• creation of new HTML tag by the w3c in the future

Indeed. All of those things could happen. However, they can happen in any technology using the concept of “components”, including React, Vue, Svelte or any other that embraced a similar approach. As far as I know, that hasn’t been a problem for the adoption of those technologies. Those are really minor issues, IMO.

Lastly and probably the most important thing out of this discussion is that it helped me a lot to convince myself that we’ve chosen a good approach. Why? Because since Surface knows the structure of the code, we can easily add an option to the translator to check if a component has the same name of an existing HTML element and present a proper warning (or error) to the user.

See how powerful the abstraction is? Even some of the downsides of it can be properly handled in a way that guides the user to do the right thing. I think it’s just fantastic that we can do that, especially for the inexperienced developers you mentioned.

[tme_317]

Awesome library! I was already making some live components using Bulma (with inspiration from the excellent Buefy) and this will make the templating/props experience almost like React!

Quick question… I was reading this issue and is it true Surface.Component can be used to make standard stateless functional templates without LiveView being installed at all?? I just assumed Surface was completely coupled to LV but it would be awesome to be able to use it in my non-LV projects also.

[msaraiva]

@tme_317

is it true Surface.Component can be used to make standard stateless functional templates without LiveView being installed at all?? I just assumed Surface was completely coupled to LV but it would be awesome to be able to use it in my non-LV projects also.

My initial intention for Surface.Component was to keep it as a sort of functional component that could work in both, LV and non-LV projects. The problem is that currently, LiveView does not allow nesting live components inside a functional component. A phoenix LiveComponent can only be initialized inside a LiveView or in other LiveComponent. So in order to allow nested components to work properly in LV I’m changing the implementation of Surface.Component to also rely on live_component/3 which will, unfortunately, make it incompatible with non-LV projects.

BTW, I also think it would be great to be able to use the same model in non-LV projects. However, since we’re currently focusing on LV, I think it’s better to remove the support for now. If in the future more people get interested in using Surface in non-LV projects, we can try to talk to the phoenix core team again and see if we can find an alternative solution for the problem.

[elcritch]

@msaraiva

My plan for the “Components” section is to list different reusable components suites written using different technologies like Bootstrap , Bulma , Tailwind , etc.

That’d be awesome! I’m using Bulma currently and built up an internal livecomponent like library using macros but livecomponents would be so much nicer. Still even as macros, a component library makes developing new pages a sinch. I’m excited to look into your library!

Do you wrap things like dropdowns/number selects/etc and handle their events? If there’s a way to add Bulma based live-components I’d take a look at that (rather than building my own).

[Exadra37]

@msaraiva

Ok, first. I find hard to believe you would think it was a typo since the syntax highlighter uses different colours for HTML tags and components:

It sounds like you are assuming that “everyone” is using VSCode, but many more editors exist, and each editor have many different themes you can choose from.

So his assumption is perfectly valid in thinking that it’s a typo, and he will not be alone for the many years to come, but I am not saying you should rename them.

And congrats for the great work and effort your are putting on this project

[Exadra37]

@msaraiva

If in the future more people get interested in using Surface in non-LV projects, we can try to talk to the phoenix core team again and see if we can find an alternative solution for the problem.

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.

[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.

[chrismccord]

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.

[Exadra37]

@chrismccord

Trying to decouple early on will slow down development

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

@chrismccord

to accommodate a small fraction of users

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?

[chrismccord]

@Exadra37

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?

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.

[Exadra37]

@chrismccord

Sorry, I didn’t mean for it to come across that way.

I know that you haven’t said it with that intention, that’s why I used “everyone” between commas

[msaraiva]

@elcritch

Do you wrap things like dropdowns/number selects/etc and handle their events? If there’s a way to add Bulma based live-components I’d take a look at that (rather than building my own).

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.

@Exadra37

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.

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.

[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).

[msaraiva]

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.