-
Notifications
You must be signed in to change notification settings - Fork 110
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP] Live components #247
base: main
Are you sure you want to change the base?
Conversation
Outstanding!!! |
Join: (HttpContext -> ClientInfo -> Task<JoinResult>) option | ||
Init: (HttpContext -> ClientInfo -> (Cmd<'Msg> -> unit) -> Task<'State * Cmd<'Msg>>) option | ||
Update: (HttpContext -> ClientInfo -> 'Msg -> 'State -> Task<'State * Cmd<'Msg>>) option | ||
View: (HttpContext -> ClientInfo -> 'State -> XmlNode) option |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using the concrete type XmlNode
ties this implementation of live components with the view engine of Giraffe. It won't be possible to use Feliz.ViewEngine which uses a different type called ReactElement
.
Would it be possible to abstract the view output into the type declaration? i.e.
type LiveComponenetBuilderState<'State, 'Msg, 'View> = {
View: (HttpContext -> ClientInfo -> 'State -> 'View) option
}
5e6d94d
to
cb206d5
Compare
@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