With the current params, the current session and the LiveView socket.Īs in a regular request, params contains public data that can be When LiveView is first rendered, the mount/3 callback is invoked You begin by rendering a LiveView typically from your router. Guaranteeing a regular HTML page even if JavaScript is disabled.Īny time a stateful view changes or updates its socket assigns, it isĪutomatically re-rendered and the updates are pushed to the client. Uses more memory on the server compared to stateless requests.Ī LiveView begins as a regular HTTP request and HTML response,Īnd then upgrades to a stateful view on client connect, This allows LiveView applications to react faster to userĮvents as there is less work to be done and less data to be sentĬompared to stateless requests that have to authenticate, decode, load,Īnd encode data on every request. Then a persistent connection is established between client and Paint", in addition to helping search and indexing engines. HTTP requests, which provides quick times for "First Meaningful LiveView is first rendered statically as part of regular Internal application messages (usually emitted by Phoenix.PubSub) The state itself is nothing more than functionalĪnd immutable Elixir data structures. Process that receives events as messages and updates its Work of tracking changes and sending the relevant diffs toĪt the end of the day, a LiveView is nothing more than a
This means developers write LiveView templates asĪny other server-rendered HTML and LiveView does the hard To the browser, which updates itself in the most efficient Re-render the relevant parts of its HTML template and push it Saying "once event X happens, change Y on the page",Įvents in LiveView are regular messages which may causeĬhanges to its state. The LiveView programming model is declarative: instead of LiveView provides rich, real-time user experiences with Settings View Source Phoenix.LiveView behaviour (Phoenix LiveView v0.17.11)
0 kommentar(er)
