Open Krzysztof-Cieslak opened 4 years ago
Outstanding!!!
@Krzysztof-Cieslak @Zaid-Ajaj This looks interesting. Should this get implemented? I think only the refactoring of the LiveComponentBuilderState is missing right?
@tforkmann, there's also a client-side component (i.e. JS library) that probably we should provide to make it easy to use in practice. And add helpers for actually using this client-side library in the server-side rendered code to define communication between client and server.
So... this is initial implementation fo
Live Components
. Inspired byPhoenix Live View
they are designed to enable rich, real-time user experiences with server-rendered HTML. Under the hood, they're powered by our currentchannel
implementation - essentiallyliveComponent
is specializedchannel
.What is different from
Phoenix Life View
is thatLive Components
implements MVU pattern. Essentially each component is small MVU application (it has its internal state and event loop), all operations known from MVU -init
,update
,view
- are performed on the server, and after the view is rendered we push it to the client through web socket - this will then be used by some JS diffing library to update the DOM. Similarly to MVU, we define'State
and'Msg
types that represent state and actions in our component - both are defined on the server sideIn current shape, PR is not usable at all, but it shows the basic design of server-side of
liveComponent
.Currently missing:
liveComponent
in the applicationliveComponent
)liveComponent
first render should be static (i.e. send as part of normal HTTP response) and real-time communication kicks in after it - this will enable fast first rendering and SEO etcCloses #228.
CC: @panesofglass @Banashek @baronfel