You can store anything in the socket, but the point is to auth the client as soon as he come in, so something has to be on the client side, be it cookie or localStorage. And once the client is auth’ed. you don’t need to store the token anymore, just the auth’ed state and his account details.
derek-zhou
mfilej
On the topic of mixing Surface.LiveViews with classic (dead giggle) views, is there a way to tell Surface to use a live.html layout by default?
I know I can tell each individual module to:
use Surface.LiveView,
layout: {PlatformWeb.LayoutView, "live.html"}
But can I do it globally?
For plain LiveView we would do:
def live_view do
quote do
use Phoenix.LiveView,
layout: {PlatformWeb.LayoutView, "live.html"}
unquote(view_helpers())
end
end
in our myapp_web.ex.
Is there an equivalent for surface?
harmon25
Just replace use Phoenix.LiveView in the live_view macro with use Surface.LiveView
or make a new macro for :surface_live_view
def surface_live_view do
quote do
use Surface.LiveView,
layout: {PlatformWeb.LayoutView, "live.html"}
unquote(view_helpers())
end
end
derek-zhou
The concept of a layout is obsolete in Surface. With a Surface component you can have multiple, named slots, much more expressive than a single <%= @inner_content %>
mfilej
I see what you mean, but I don’t know how to set that up? I have a parent .html.eex layout that is shared between classic controllers and Surface.LiveViews. Now I need a way to output the live_flash only for LiveViews (what live.html does if you generate a new phoenix app with --live).
derek-zhou
If you just need the flash, you can do:
main.sface:
<div id="main-content" class="content" phx-hook="Main">
<div role="alert" :for={{ type <- Map.keys(@messages) }}
class={{ "alert", alert_class(type) }}
phx-value-key={{ type }} phx-click="lv:clear-flash">
{{ @messages[type] }}
</div>
<slot />
</div>
include a Main component in your liveviews::
<Main :props={{ messages: @flash }}>
YOUR STUFF
</Main>
derek-zhou
I prefer explicit specification over implicit. Also with Liveview I typically have far fewer LiveViews than classical controller/view pairs.
Malian
@mfilej I also use the suggestion of @derek-zhou
In most app I develop, I need several layouts as they deserve different purpose, and most importantly, they have different designs.
I often use 3 types of layout:
- a
LandingLayoutthat is used only for the landing page of the website and any related stuff:- marketing-oriented design
- few user interactions
- components are not reused
- a
AppLayoutorMainLayoutthat is used in the application itself when the user is connected- UX oriented design
- a lot of user interactions
- components are reused everywhere in the app
- an
AdminLayoutthat is used only by the team- Ugly design (^^)
- medium user interactions
- components are reused in the backend
By opening one of my live view, it’s really clear for me which layout is used on and what are the features that layout gives me access to!
In 80% of the time, my live views look like this
<AppLayout
flashes={{ @flash }}
current_user={{ @current_user }}
/>
My Content
</AppLayout>
In the 20 remaining %, I am able to tweak my layout for specific pages explicitly without duplicating it.
<AppLayout
show_sidebar={{ false }} <-- NO SIDEBAR FOR THAT LIVE VIEW
flashes={{ @flash }}
current_user={{ @current_user }}
/>
My content
<PageTitle>
Override the design of the page title for that specific live view
</PageTitle>
<RightColumn>
Useful slottable component that extends my layout and that is not present by default
</RightColumn>
# or
<ProfileRightColumn user={{ current_user }} /> <-- A PREDIFINED RIGHT COLUMN THAT IS EXPLICIT OF ITS INTENT (It is "just" a wrapper arround `<RightColumn>...</RightColumn>` with predifined `props`
</AppLayout>
Finally, here is an example of one of my layout with some comments (I removed classes and I only show the render function):
<div
x-data="{ open: false }"
@keydown.window.escape="open = false"
>
<slot name="sidebar" :if={{ @show_sidebar }}> <-- WRAPPING COMPONENTS INTO A SLOT ALLOWS ME TO OVERRIDE THEM EASILY
<Sidebar id="sidebar" />
</slot>
<slot name="secondary_sidebar" /> <-- OPTIONAL EXTENSION
<div>
<slot name="header_menu"> <-- LIKE SIDEBAR, IF THE HEADER HAS NOT BEEN OVERRIDED, SHOW THE DEFAULT ONE
<HeaderMenu id="header-menu" />
</slot>
<!-- Main content -->
<div>
<!-- Primary column -->
<main>
<section>
<h1>{{ @page_title }}</h1> <-- PROP FOR THAT LAYOUT
<slot name="default" /> <-- MAIN CONTENT
</section>
</main>
<!-- Optional secondary column -->
<slot
name="secondary_column"
:if={{ show_secondary_column(assigns) }} /> <-- OPTIONNAL EXTENSION WHOSE VISIBILITY IS MANAGED BY THE CHILD COMPONENT
</div>
</div>
</div>
<FlashMessages flashes={{ @flashes }} /> <-- FLASHES WRAPPER
So yes you have to repeat a few lines of code, but I really believe you gain in clarity and in functionality 
Hope this will help other Surface users! Feel free to comment and get my yours feedback !
10
elcritch
Just started really playing around with Surface, and gotta say nice work y’all! It’s really nice to have typed templates.
I’ve created a few widgets to help with standard IoT/Dashboard things I build a lot (for work and personal), see SurfaceBulmaWidgets. Warning, they probably break a few best practices. 
What I really wanted to share for others was a “bind” concept and macro implementation. See SurfaceBulmaWidgets.Bindings. It draws on my previous experience writing bulma_widgets (which was pre-live-components IIRC).
SurfaceBulmaWidgets.Bindings takes/passes the name of the variable along with it’s value to the child widget (currently Surface.LiveComponent’s). The widget then sends the parent a standardized event {:update_bind, name, value}.
It’s somewhat like contexts but I prefer having a standard event and not needing to pass entire contexts around. It’s basically Vue’s bind mechanism.
defmodule SurfaceBulmaWidgetsPlaygroundWeb.HomePageLive do
use Surface.LiveView
require Logger
use SurfaceBulmaWidgets
alias Surface.Components.LiveRedirect
alias SurfaceBulmaWidgets.Layouts.{Columns, Column}
alias SurfaceBulmaWidgets.UI.{RangedSlider, NumberDisplay|
data count1, :integer, default: 10
data count2, :integer, default: 80
def render(assigns) do
~H"""
<Columns multiline>
<Column width=4>
<div class="box" >
<p>Example Reactive Widgets</p>
<RangedSlider id="rl1" var={{bind(@count1)}}/>
<RangedSlider id="rl2" var={{bind(@count2)}}/>
<NumberDisplay id="ndl2" name="Count 2" value={{bind(@count2)}} digits=1/>
<p><LiveRedirect label="Learn more" to="/uicomponents" /></p>
</div>
</Column>
</Columns>
"""
end
# Override: `handle_info({:update_bind, name, value} = msg, socket)` for custom behavior
end