How to load historical chart data on scroll the bars right side

[subramanian-iouring]

Lightweight Charts™ Version: 4.0.1

Am using "subscribeVisibleLogicalRangeChange" to listen chart bar scroll. function callBackFun () { // called multiple times, so i can't able to call http service here. } lightChart.current.timeScale().subscribeVisibleLogicalRangeChange(callBackFun);

Expected behavior:

Load historical data when scroll the chart to right side.

[SlicedSilver]

You may find the example for barsInLogicalRange to be useful: https://tradingview.github.io/lightweight-charts/docs/api/interfaces/ISeriesApi#barsinlogicalrange

Note that, when adding more data to a series which is older (to the left) then you need to use the setData method and provide the full data set again (with the additional data at the start).

[parthya]

I am implementing lazy loading to replace historic data as user scrolls to the left.

I have observed that every subsequent setData call gets slower and slower, occasionally get Page Unresponsive alert.

Is there any cache we can clear before making setData calls to replace the data?

[SlicedSilver]

Does the suggestion in this stack overflow answer help? https://stackoverflow.com/questions/75132897/fetching-backward-data-make-the-chart-stuck-for-a-while-with-lightweight-chart/75133235?noredirect=1#comment132591374_75133235

[parthya]

Load all data crashes the browser that's why going for chunks, listening to subscribeVisibleTimeRangeChange.

Will try multiple series for each chunk. Thanks a lot!

[parthya]

Update: Loading all data (25k candles) was not crashing the page.

I was creating too many small line series (trade open-close points) with markers to plot on the candle chart. This was causing the issue.

Fixed by creating just 2 open and close line series.

[pengyou200902]

Brief version what I want:

• Limit the scroll range. Eg: User can only scroll to the right side for a maximum 50 units per scroll.
• Only trigger the "range change handler" once per scroll instead of every minimal movement.

---

Hi there, I've viewed these

1. https://tradingview.github.io/lightweight-charts/docs/api/interfaces/ISeriesApi#barsinlogicalrange
2. https://tradingview.github.io/lightweight-charts/tutorials/demos/infinite-history

but still I am facing the issue that was mentioned by the OP here, that is, every minimal movement of the time range (horizontal axis) will trigger a call to the handler method, inside which I am calling an endpoint. And this basically causes tons of unnecessary HTTP requests to the endpoint. Imagine each log line is a HTTP request.

I know I might handle this wrongly, someone please help point me to the correct place I should look at. Or any simple code piece would help.

Thank you!!!

[SlicedSilver]

@pengyou200902 Based on my experience, the following approach is the most effective way to handle loading historical data as needed:

As demonstrated in the infinite history example, it's optimal to begin loading the next chunk of historical data while you still have some bars off-screen to the left. In essence, it's preferable to have an excess of data available for display, which serves as a buffer. This ensures that when users scroll, they see existing data while new data chunks load in the background. In the example, a buffer of 10 bars is used, but you might want to increase this number or base it on the current barSpacing value (zoom level) for better performance.

It's normal for the time range changed event to trigger on each scroll event. However, you can implement checks within that handler to determine whether to request more data. Here's a suggested approach:

1. First, verify that the unseen buffer of items to the left of the chart is sufficiently large.
2. Then, ensure that there isn't already a data request in progress.
3. Only if both conditions are met should you initiate a new request for additional data.

I recommend making relatively large data requests to minimize the number of HTTP calls. For instance, request the data you immediately need (say, 20 bars) plus an additional buffer (perhaps 100 bars or more, depending on your specific use case).

By implementing this logic, you can significantly reduce the number of network requests for data. This approach strikes a balance between providing a smooth user experience and optimizing server load and network usage.

Remember, the key is to anticipate user behavior and load data preemptively, rather than reacting to every small scroll movement. This strategy not only improves performance but also enhances the overall user experience by reducing visible loading times.

[pengyou200902]

@SlicedSilver Very much appreciate your detailed and comprehensive reply!! That really helps a lot!!