Allow hook for LiveDashboard historical data at client connection

I’m wondering if you actually need to send the historical data separately to the frontend? The JS doesn’t really care where the data is coming from (unless it should be marked differently somehow).

This is because they’re for different types of charts/metrics, see the classes around them.

I didn’t think so initially, but passing it in as data assigns doesn’t work/is ignored, perhaps because of the initialData function? I can play around with later or you’re welcome to/I can try and package up a little app that’s using this integration to demo/play with more easily extracted from my actual app’s usage if you think useful. I don’t think it should be marked differently, though its an interesting question, I could see perhaps wanting a marker at the dividing line, but I think that would be a future refinement if so.

Actually, you’re right, though the way I have it working without modifying JS feels a bit dirty/maybe you have an idea for a better place, it works if I do a send_update immediately after the render of live_component like so:

   <%= if @metrics do %>
      <div class="phx-dashboard-metrics-grid row">
      <%= for {metric, id} <- @metrics do %>
        <%= live_component @socket, ChartComponent, id: id, metric: metric %>
        <% send_update(ChartComponent, id: id, data: history_for(metric, @historical_data)) %>
      <% end %>
      </div>
    <% end %>

but putting a side effect there feels a bit dirty, perhaps there’s a better hook available to call immediately after render? Dunno… but locally its working beautifully this way so that’s a start…

I would’ve looked at doing it within mount of ChartComponent, so data is filled from the start.

oh yeah that makes more sense I’ll try that now, thanks!

Hmm, but I dont have access to the assigns in ChartComponent mount, I thought maybe they were in the socket on socket.assigns but that just has flash and myself at mount…

In any case, working version is pushed up, may try and refactor from there to use mount and/or add some tests or something but still welcome code reviews from anyone following this before I open PR, to both save José and company time and also increase chance of it being accepted!

Link again is GitHub - bglusman/phoenix_live_dashboard at historical_data · GitHub I’ll open a PR into my master branch if I can to avoid bothering the main project until ready but allow code review…

Found a small improvement noticing that live_component accepts a do block, so can add a do block and call my send_update there and that works well enough… if I don’t hear ideas from anyone else I think I’ll accept that as reasonable place to do after-render work for a live component, since it is designed to take that block…

OK official PR is open now, added tests and more docs, hopefully its up to snuff but for anyone interested Historical data configuration hook by bglusman · Pull Request #122 · phoenixframework/phoenix_live_dashboard · GitHub

So over the weekend Jose reviewed the PR and then closed it with some more feedback around some cases I hadn’t considered (I also may have gotten on his badside with some confusion/ignorance about Github alerts etc , but ahh well, live and learn…). If anyone is using LiveDashboard with more complex metric types, tags and explicit units etc that they might like to enable history for, please let me know, as I don’t have any of these myself so I’d be making up fictitious use to try and cover the edge cases he mentions… I think the main points he raises can be handled by just passing the entire metric to the callback instead of just passing the name, but if I’m reading his comments correctly the larger issue is reworking the guide/example implementation I provided to handle those other situations with good documentation and understanding when the user might not want to play back certain events from history (this part didn’t make a ton of sense to me/maybe :telemetry_poller is already saving up some events for later playback or there’s some other side effect I’m missing?).

@LostKobrakai if you have any interest or bandwidth to discuss/weigh in on above, or @axelson @fhunleth or @sfusato since you all expressed interest (apologies if I’m failing/breaking any kind of etiquette by @'ing you guys here, no obligation to respond, apparently I’m clueless how to internet about these things ), or anyone else who has ability/desire to perhaps run my fork locally or in production and help refine the other kinds of charts/metrics José brings up to help solidify implementation and docs, contact me here or email me at brian@ my last name .me

(I pushed up the minimal changes I understand from José’s feedback into code and docs, but looking for further understanding from others on both!)

Telemetry poller is not saving any events. It periodically triggers the emission of certain telemetry events, which are not triggered by explicit actions, like e.g. current memory usage.

One thing I did when testing the charting was just hit the endpoint with a load testing tool. This will quickly bring stress to your system and fill up your metrics cache. The complexity here lies in the details. Events might be quite big (which is not a problem for just dispatching, but might when kept around). Short bursts to the system will fill up any timebased solution to extends maybe not accounted. Generally keeping much data around in memory can be problematic (see the topic on tz_world here on the forum), you don’t want to bring an application to crash for OOM reasons. Then there’s – as correctly noted - the problem of many metrics for the same base event.

I guess Jose’s point is that those are best solved first before thinking about best hooking the result into live_dashboard.