Stop chart dynamicChartOptions array growing unrestricted

[Steve-Mcl]

Description

Consolidates dynamicChartOptions array into a singular row by calling this.chart.getOption()

Related Issue(s)

closes #2012

Checklist

• I have read the contribution guidelines
• Suitable unit/system level tests have been added and they pass
• Documentation has been updated
  • Upgrade instructions
  • Configuration details
  • Concepts
• Changes flowforge.yml?
  • Issue/PR raised on FlowFuse/helm to update ConfigMap Template
  • Issue/PR raised on FlowFuse/CloudProject to update values for Staging/Production
• Link to Changelog Entry PR, or note why one is not needed.

Labels

• Includes a DB migration? -> add the area:migration label

[Steve-Mcl]

@colinl - does this make sense to you? See any issues with consolidating the chart options?

[colinl]

It is difficult for me to see the complete picture as I only have a phone.
Does it work if you make a series of updates to a chart on a page that is not being viewed, and then switch to the page with it on?

[Steve-Mcl]

It is difficult for me to see the complete picture as I only have a phone. Does it work if you make a series of updates to a chart on a page that is not being viewed, and then switch to the page with it on?

The array is still present and does get populated so long as there is no chart object. Once there is a chart object, the changes should be applied and consolidated. That's the theory anyhow.

I don't have time to dig further and do any manual testing so this will sit here for a while Colin.

[colinl]

Looking at this again I agree that it would be an improvement, but it does not fix the underlying problem as the array will still build up if the chart is not on screen. I did it this way, though I was not really happy with it, in order to avoid having to import a deep merge package such as lodash.merge.

Having thought about it again, I wonder whether a better solution would be, when msg.ui_update.chartOptions is passed to the node, to perform the deep merge server side, as is done at the moment, but then always pass the full merged set to the clients, rather than just the latest modification. The clients would then only need to save the latest set. There would be a small increase in comms, but only when chartOptions is passed to the node, but I can't see that it would ever be significant.