Our browser initially connects to the server making a simple HTTP GET request to the live route. It’s a single stateful LiveView process, that keeps its state in memory and tracks the changes, as long as we stay connected. We also see that the LiveView process, which serves our browser, is always the same (one process for each connected user). In the terminal we see that each new trade is handled by handle_info/2 which updates the socket, then render/1 is called to re-render the view and send the changes to the browser.
Phoenix liveview examples code#
The JS code running on the browser applies these changes using a library called Morphdom.
In this way the payload is super compact: we just have the aded_at (position number 2 in the diff message), the trade.price (position number 3) and trade.volume (position number 4).Įach dynamic part has it’s own position number and LiveView uses this positions to know which element needs to be updated in the DOM. Looking into one of the diff messages, we don’t see any static part, only the dynamic values that changed in socket.assigns. LiveView is able to track the changes and send only the changed values to the browser. With the browser inspector we can see the messages sent by LiveView process running on the server.Īfter the initial phx_join and phx_reply, we find diff messages, which are the changes sent from the server every time a new trade is received. The view gets re-rendered, calling render/1, and the changes are pushed to the browser.īy refreshing the page on the browser we see that, as expected, the view is now correctly updated every time there is a new trade. We print the PID and assign/3 the :trade in the socket. # Poeticoins.subscribe_to_trades(product)ĭef handle_info( message. Trade = Poeticoins.get_last_trade(product) Product = Product.new("coinbase", "BTC-USD") Defmodule PoeticoinsWeb.CryptoDashboardLive do
0 kommentar(er)
