alvises

alvises

I’ve started experimenting with JS charts in LiveView and update the chart with realtime data using LV hooks. I’m able to add new datapoints to the chart without having to redraw it everytime. It seems to work well, BUT I’m not convinced if in this way, in case of really fast updates. the chart can suffer of data loss.

liveview_chart

I’m using Highstock

app.html.eex

<!DOCTYPE html>
<html lang="en">
  <body>
    ...
    <script src="https://code.highcharts.com/stock/highstock.js"></script>
  </body>
</html>

chart_live.ex

defmodule ChartWeb.ChartLive do
  use Phoenix.LiveView

  def mount(_session, socket) do
    :timer.send_interval(1_000, self(), :next_price)
    socket =
      socket
      |> assign(:prices, historical())
    {:ok, socket}
  end

  def render(assigns) do

    ~L"""
    <div phx-hook="Chart" data-prices="<%= @prices %>"></div>
    <div phx-update="ignore">
      <div id="chart" style="width:100%; height:400px;" ></div>
    </div>
    <pre><%= @prices %></pre>
    """ |> IO.inspect()
  end

  def handle_info(:next_price, socket) do
    now_unix = DateTime.utc_now |> DateTime.to_unix(:second)
    {:noreply, assign(socket, :prices, Jason.encode!(random_data(now_unix)))}
  end

  # creates last 10 minutes of random data
  def historical() do
    now_unix = DateTime.utc_now |> DateTime.to_unix(:second)
    hour_ago_unix = now_unix - 60*10

    hour_ago_unix..now_unix
    |> Enum.map(&random_data(&1))
    |> Jason.encode!()
  end

  def random_data(unix_seconds) do
    [unix_seconds * 1_000, Enum.random(100..200)]
  end
end

app.js

Hooks.Chart = {
    lastprice() { return JSON.parse(this.el.dataset.prices)},
    createChart(data) {
        return Highcharts.stockChart('chart', {
            title: {
                text: 'Random prices with Phoenix LiveView'
            },
            series: [{
                name: 'A stock',
                data: data
            }]
        });
    },
    addPointToChart(chart, price) {
        chart.series[0].addPoint(price, true, false)
    },
    mounted() {
        console.log("Chart LiveView mounted");
        
        //using data-historical (last hour of random data)
        let historical = JSON.parse(this.el.dataset.prices);        
        this.chart = this.createChart(historical);
    },
    
    updated() {
        let price = this.lastprice();
        console.log(price)
        this.addPointToChart(this.chart, price)
    }
}

mount and initialization

The ChartLive module initially renders all the historical prices into data-prices attribute (`socket.connected? case to be handled, to avoid to send the whole historical data two times)

When the view is mounted, the mounted function in the JS hooks is called, it reads the data from the data-prices attribute and it creates the chart with that historical data.

Updates

Then for each new price sent from LV, the data-prices is patched and for each update Hooks.Chart.updated() function is called. It takes the new prices from the data-prices attribute and it adds it to the chart.

Considerations

I think that this approach reduces the data hold, rendered and transmitted to the minimum (without taking a huge list of prices into memory and redrawing the whole chart every time) …

BUT, I honestly don’t know how it works in case of rapid updates: is it possible that the JS LiveView on the client side patches the DOM with new data, before update() is able to grab and add the last price to the chart?

Showing Posts 1 to 7

alvises

alvises OP

Sorry, the image’s link has expired. Here’s the result,

And here with a point every 50ms

I’m still investigating if there could be a race condition in updated():sweat_smile:

alvises

alvises OP

Looking at the new Phoenix 1.5-rc0, the LiveDashboard seems to use a similar method

https://github.com/phoenixframework/phoenix_live_dashboard/blob/master/lib/phoenix/live_dashboard/live/chart_component.ex#L34

leductam

leductam

Please correct me if any upgrade for JavaScript can execute multi threading on browser. As I known the JavaScript is just single threaded, that means, code execution will be done one at a time. And the current scenario, your implementation is also just sent the updated prices via :timer.send_interval -->handle_info and the single back-end process (Erlang’s process) is always sequential.
Then single Erlang’s process back-end–> single JavaScript threaded front-end is sequential execution pipeline and there is no race condition.

References:
JavaScript sequential execution.

chrismccord

chrismccord

Creator of Phoenix

Confirm this is exactly what we do on the LiveDashboard and it’s a great approach. Provided your chart update code is synchronous, then it guaranteed to not have any races as everything will happen in the same event loop.

10
Post #4
tmvsiva

tmvsiva

I know this wasn’t at all the point of the post, but I have been trying to recreate this example and failing. I’d certainly appreciate any basic pointers anyone might have.

The browser console shows the error ‘unknown hook found for “Chart”’. It’s from phoenix_live_view.js

The raw full set of price data appears on page load and is then replaced by the raw update data every second.

tmvsiva

tmvsiva

Never mind, it was as simple as creating the Hooks and then adding it into the liveSocket initialisation in app.js:

let Hooks = {}

Hooks.Chart = ...

let liveSocket = new LiveSocket("/live", Socket, {hooks: Hooks, params: {_csrf_token: csrfToken}})
jrissler

jrissler

Using version 0.13.3 of liveview - this works great. Hooks are such a great addition!

— All posts loaded —

Where Next? Top

Trending in Discussions Top

AstonJ
As the title says, please share what you’ve been up to with Elixir. Whether that’s been learning it, looking into it, making stuff with i...
2977 94592 917
New
cblavier
Hey there, It’s been more than a year since we started using LiveView as our main UI library and building a whole library of UI componen...
New
mudasobwa
I am happy to introduce the very α version of the new programming language compiled to BEAM. Welcome Cure. It has literally three kille...
New
heathen
Quite interesting article Google brought me. Didn’t find any mentions about it here. What do you think in general? Would you use togethe...
New
mhanberg
Hi everyone! The first release candidate for the Expert language server project is now available! We’ve published a press release detai...
New
AstonJ
Since we have deprecated our Erlang sections (as we have dedicated Erlang Forums now) let’s add this thread for those who’d like to post ...
New
maennchen
:warning: Security advisory: Decimal DoS vulnerability A vulnerability has been published for decimal where very large exponents can cau...
New

Other Trending Topics Top

JesseHerrick
Hey, I’m Jesse and I’m the main contributor behind Dexter, a full-featured, lightning-fast Elixir LSP optimized for large codebases. It s...
New
marciok
Hi there! We created Gust: A task orchestrator inspired by Airflow. For those who have never heard about Aiflow, it’s a Python-based wor...
New
jimsynz
Beam Bots (or just BB for short) is a framework for building fault-tolerant robotics applications in Elixir using familiar OTP patterns. ...
New
Dmk
Xamal is a deployment tool for Elixir apps that deploys native releases to bare metal servers over SSH. It’s a port of GitHub - basecamp/...
New
netoum
Corex is an accessible, unstyled UI component library for Phoenix that integrates Zag.js state machines using Vanilla JavaScript and Live...
New
webofbits
With AI doing more of the implementation work, I’ve been wondering how much coding I should deliberately keep doing myself. My main conc...
#ai
New

Latest on Elixir Forum

We're in Beta

About us Mission Statement

Options

Thread Display Mode




Thread Preview

Skip Thread Previews