Skip to content
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

Draft
wants to merge 4 commits into
base: main
Choose a base branch
from
Draft

[WIP] Live components #247

wants to merge 4 commits into from

Conversation

Krzysztof-Cieslak
Copy link
Member

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

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

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

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