Skip to content

[WIP] Live components#247

Draft
Krzysztof-Cieslak wants to merge 4 commits into
mainfrom
liveComponents
Draft

[WIP] Live components#247
Krzysztof-Cieslak wants to merge 4 commits into
mainfrom
liveComponents

Conversation

@Krzysztof-Cieslak

@Krzysztof-Cieslak Krzysztof-Cieslak commented May 21, 2020

Copy link
Copy Markdown
Member

So... this is initial implementation fo Live Components. Inspired by Phoenix Live View they are designed to enable rich, real-time user experiences with server-rendered HTML. Under the hood, they're powered by our current channel implementation - essentially liveComponent is specialized channel.

What is different from Phoenix Life View is that Live 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 side

In current shape, PR is not usable at all, but it shows the basic design of server-side of liveComponent.

Currently missing:

  • Registering liveComponent in the application
  • View helpers (attaching attributes to HTML tags defining events, or the fact something is liveComponent)
  • Client-side (JS) library responsible for communication
  • Static rendering case. 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 etc

Closes #228.

CC: @panesofglass @Banashek @baronfel

@panesofglass

Copy link
Copy Markdown

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

Copy link
Copy Markdown

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
}

@Krzysztof-Cieslak
Krzysztof-Cieslak changed the base branch from master to Saturn014 June 15, 2020 19:58
@Krzysztof-Cieslak
Krzysztof-Cieslak changed the base branch from Saturn014 to master June 19, 2020 14:17
@Krzysztof-Cieslak
Krzysztof-Cieslak marked this pull request as draft October 23, 2020 12:45
@tforkmann

Copy link
Copy Markdown
Contributor

@Krzysztof-Cieslak @Zaid-Ajaj This looks interesting. Should this get implemented? I think only the refactoring of the LiveComponentBuilderState is missing right?

@Krzysztof-Cieslak

Copy link
Copy Markdown
Member Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add LiveView support

4 participants