Still, if we have many products it could be an issue to receive all the products’ dynamic values inside the for comprehension every time something changes, especially if each product receives many trades per second. But LiveView makes an optimization, it understands what is static and what is dynamic inside a comprehension, so it only sends the dynamic values to the client. This happens because LiveView doesn’t perform change tracking inside comprehensions. After adding three different products to the dashboard, taking a look at the exchanged WebSocket messages we immediately see that every time the LiveView process receives a new trade, it updates the :trades map and all the dynamic values inside the for loop are sent to the browser (for every trade). Let’s see what happens at each render when we have many products. We notice that the PID is always the same, because components (both stateless and stateful) live inside the live view’s process.Įvery time the :trades map in CryptoDashboardLive view is updated, ProductComponents in the for are re-rendered. Since the LiveView process subscribes to a PubSub topic to get new trades for that product, for each new trade the component is re-rendered callingmount/1 ,update/2 andrender/1`. Then, when we add a product, LiveView renders the component, by calling mount/1 update/2 and render/1. When we connect to the dashboard with a browser we immediately see the LIVEVIEW MOUNT log which prints the LiveView process ID #PID. IO.inspect(self(), label: "LIVEVIEW MOUNT") #lib/poeticoins_web/live/crypto_dashboard_live.exĭefmodule PoeticoinsWeb.CryptoDashboardLive do Then, in CryptoDashboardLive.render(assigns), we render the component calling live_component/4, passing the :product and :trade assigns. We move the product card div (the one in the for comprehension in CryptoDashboardLive) into the ProductComponent.render(assigns) function. We start by implementing just the render(assigns) callback. If the template is too big, we can move it to a. render(assigns), which returns the component’s LiveEEx template.update(assigns, socket), optional, called with the assigns passed to live_component.mount(socket), which is optional, it’s called only with the socket and it can be used to initialize the data.Let’s start with the simplest one, a stateless ProductComponent.įirst, we create a new lib/poeticoins_web/live/product_component.ex module where we define the PoeticoinsWeb.ProductComponent, which implements the Phoenix.LiveComponent behaviour. We start by moving the product card, the part inside the for comprehension, into a LiveComponent. A LiveComponent can be stateless (which pretty much renders a template), or stateful (which keeps its own state and handles its own events). We can move a part of the LiveView’s logic (and related template) into separate components.Ī LiveComponent lives in the same LiveView process.
This page already has different parts with different responsibilities, for example: product cards where each one shows its product price, a toolbar with a dropdown to add products to the dashboard…Ĭomponents are a mechanism to compartmentalize state, markup, and events in LiveView.
#LIVEVIEW ELIXIR CODE#
The risk is to find us with a single massive live view module which handles every aspect of our page, making che code hard to read and maintain. It’s not just about the template in the render/1 function, we could easily move it into a. These are the things that I’m wondering if they’re in the pipeline.We’ve just started to build our CryptoDashboardLive view, and we already have the feeling that the we are piling up a lot of code into the single CryptoDashboardLive module. Being able to sync the local and server-side state after reconnection.Being able to keep state on the client-side to be used during disconnections.Returning to the web-browser based UI, the features I think are missing for LiveView to support the behaviour I described are: Imagine the fictitious app developer adding a Phoenix backend to allow users to synchronize their todos across devices.Ĭan the server-side state be accessible to the app via WebSockets while the local copy takes over when there’s no connection, with both syncing when the connection is restored?
#LIVEVIEW ELIXIR OFFLINE#
The todo app runs offline (desktop/mobile in this case) and manages its local state successfully. In fact, its example todo app illustrates what I’m curious about, albeit in a slightly different domain. I’m aware of Elixir-desktop and I follow its progress constantly. Thank you for clearing about being strictly server-side.
0 kommentar(er)
