Molecule looks nice, will definitely try.
But I’m still super jelly of Surface vscode integration 
cpgo
0
stevensonmt
msaraiva
Broadway Core Team
Hi @stevensonmt!
It depends on which kind of integration you’re talking about. For features like auto-completion/suggestions which is been implemented as an ElixirSense plugin, any editor using ElixirSense directly or indirectly via Elixir-LS, will automatically have that feature.
For things like syntax highlighting, it would be really hard for me to implement it for an editor that I don’t use. Unfortunately, I have to focus on the core features and only hope that someone with the proper knowledge starts using Surface and may be willing to do that task.
2
aimerib
I’m not sure if I’ll have time for working on this soon, so I’ll leave this here for any intrepid souls out here who might want to take a pass at creating a syntax highlighting plugin for vim.
Guide for creating your own syntax highlighting plugin for Vim: https://thoughtbot.com/blog/writing-vim-syntax-plugins
For the keywords and regions necessary to properly highlight Surface related code, one should probably be able to extract those from the json files inside the vscode plugin.
This should be hard to do, just time consuming.
0
msaraiva
Broadway Core Team
Hi folks!
Surface v0.1.0 has been released and it’s available on hex.
Many thanks to all contributors who made this release possible. There’s no way we’d get this far without your help.
Also many thanks to all Phoenix Core Team for creating LiveView and its amazing component API, which is the foundation that made this project come true.
Happy coding!
-marlus
20
mcgingras
I am testing out some Surface components, and I noticed they are not adopting the “live” layout that all of my other liveview templates are using.
In web.ex I have set the layout for all LiveViews with
use Phoenix.LiveView, layout: {MyWebApp.LayoutView,"live.html"}
but it seems that Surface components are not following that path. I was able to set the layout of the surface component at the router level with
live("/surface", SurfaceComponentLive, layout: {MyAppWeb.LayoutView, :live})
but it would be great if I could follow the same convention as regular liveview components where I put the layout once in web.ex and forget about it.
Is there any to apply the same layout to all of my surface components?
Thanks!
0
msaraiva
Broadway Core Team
Hi @mcgingras!
I assume you did this inside the live_view/0 function which, by default, is used to define regular live views, not Surface LVs. However, you can either update those definitions replacing use Phoenix.LiveView, ... with use Surface.LiveView, ... or define a separate function, like:
def surface_live_view do
quote do
use Surface.LiveView,
layout: {MyAppWeb.LayoutView, "live.html"}
unquote(view_helpers())
end
end
And then use it whenever you need to define a LV:
use MyAppWeb, :surface_live_view
2
olivermt
I’ve now spent since Sunday tinkering with Surface and this is just so great.
To reiterate my rant from freenode today:
- Easy to explain to frontend devs, it feels and acts more or less like React + Redux, but then imagine Redux lives in your server instead of in the client
- Very declarative and very easy to use to set up reactive sidebars, navbars, footers and whatever
- Props design is very clean and easy to use and I love the vscode and compiler enforcement and warnings, feels almost as good as how Typescript holds your hand in React land
- Combine it with Absinthe.run() in a Service or Context module to feed data to your components and your frontend devs who really hate elixir and dont wanna learn dumb functional hard toy languages (more or less actual quote :D) can jump straight in and make awesome stuff without having touch a single piece of javascript.
10/10 experience, would recommend!
(Will update with more replies when I try to do advanced stuff and headbutt Surface/LiveView, but for now, very happy!)
12
mcgingras
Hi @msaraiva!
Thanks for all the help so far. I’m really enjoying the Surface library.
I’m running into an issue trying to recursively call a surface component within itself. The use case that is motivating this example is rendering a tree like select field. The Component accepts a map of data that looks like…
%{name: "name1", children: [%{name: "child", children []}]}
I’ve created a component called TreeNode that displays some information about the current node, then tries to render child TreeNode’s for each child of the current node.
Not the real code but something similar to…
<div>
{{ @name }}
<div :if={{ length(@children) > 0 }} :for={{ childNode <- @children }}>
<TreeNode name={{ childNode["name"] }} children={{ childNode["children"] }} />
</div>
</div>
The problem is, Surface does not seem to allow me to call the Component within itself, recursively. I am getting the error:
you are trying to use the module MyWeb.Components.TreeNode which is currently being defined.
This sort of thing works fine if you use regular liveview components, and I would love for it to work in Surface as well. Do you have any suggestions?
Thanks again for the help, I feel like I’ve been asking quite a few questions. But I really do love the library!
0
msaraiva
Broadway Core Team
Hi @mcgingras!
Currently, Surface does not allow using a component recursively. However, you can easily make it work by moving the recursion to a separate function. Something like:
defmodule Tree do
...
@doc "The root node"
prop node, :map
def render(assigns) do
~H"""
{{ render_node(@node) }}
"""
end
defp render_node(node) do
~H"""
<div>
{{ node.name }}
<div :for={{ child <- node.children }}>
{{ render_node(child) }}
</div>
</div>
"""
end
end
5