Dynamic chart component with tabs

I am currently using AG 12.3 and IG 12.3.

I am asking this as a follow-up to AG Composite Chart.

I was successfully able to create the 4 charts I needed, all in the same (exposing) component thanks to the response which included this sample: 8132.DynamicStackedChart.zip

• 1 scenario product chart (stacked area)
• 1 scenario process chart (stacked area)
• 2 scenario product chart (stacked area with stacked line)
• 2 scenario process chart (stacked area with stacked line)

In the case of the product charts, I was able to figure out how to color code products using the same process to their processes in correlative charts (populated in adjacent tabs).

As impressive as this is to my users, it looks clunky and amateurish to me and doesn’t serve the next need they have in terms of reporting. I now need to externalize a dynamic chart component that will be able to iteratively load the data passed to it into a single set of tabs. I believe each chart should load as the tab is selected, as I’ve attempted to create in the sample below.

Part of this need is my desire to clean up and reduce duplication of the code. The other part comes from the next reporting element users have requested, which includes creating a separate tab/chart for each product in a 3-scenario summary of 2 parameters (again, stacked area and stacked line chart). Since scenarios can have a maximum of 60 products, I need the tabs to be dynamically generated with the charts rather than statically allocated as in the above reference.

I assume this is the logical way to accomplish my goal. If there is another way that is more sound, I am welcome to seeing it in action.

Thank you in advance.

 

Hello Chris,

I have been reviewing your post on this matter, and I’m a bit unsure of the actual question you are asking in this case?

I have tried running your sample project, and from the scenario you have described, I think the sample demonstrates the structure that you should likely go with, although I am seeing some issues with the sample in that the charts don’t seem to be populating. After doing some debugging, this appears to be due to the ViewChild chart not being populated when the populateChart() method is hit.

Strangely, that populateChart() method appears to be getting hit when the first page loads, rather than when you click the tab that actually has the chart in it, and this is a part I am rather unsure of at the moment. This seems to be related to the chart being null though, as it has not actually rendered yet as it is not in view. It seems like the tabs are not really lazy-loading their content in this case, but I am not sure on this at the moment.

Theoretically, you might be able to get around this is by handling the refreshCompleted event of the IgxDataChart with a flag that you could set at the end of your populateChart() method as this event fires quite often and you wouldn't want to repopulate your data source a bunch of times. This method would fire when you navigate to the page that has the chart on it as it fires whenever the layout of the chart refreshes. Perhaps you could populate your data there?

Please let me know if you have any other questions or concerns on this matter.

I moved all functionality into the tab component and now it seems the tabs are erroring out within the IG call stack. Perhaps a bug should be raised for this? It doesn't matter if I statically declare the charts in the tabs (current implementation) or if I use ngFor to declare them (commented out), the error is exactly the same.

I've verified that the chart component is receiving and processing all data as expected, but because of errors in the IG packages, it's not populating either chart.

1362.DynamicStackedChart.zip

Hello Chris,

I have been investigating into the sample you provided, and there are a few issues that I can see in this case that are  directly leading to the exceptions you are seeing in the console. None of these issues are bugs in our code, though – they are directly related to what you are assigning the data source of your series and the chart to in your “chart-out” component.

Currently, in the sample, you are setting your chart’s data source to data[x], where “x” is either 0 or 1. After inspecting what “data” actually is in your chart-out component, I can see that it is just a single collection of objects, and for this type of binding, it would need to be a collection of collections. This is the reason that you are getting the errors you are seeing – the data source needs to be a collection, and you are currently trying to set it to a single object.

Please let me know if you have any other questions or concerns on this matter.

I have changed those data points and added the brushes/outlines to the chart declaration in the chart component. I can only chalk those lapses up to working on 5 or more items at a time all week.

Even with those changes, there is still no data being charted, even though it looks correct compared to previous implementations. Again, I’m not sure what I could be missing.

Again, I’m concerned with the greatly increased memory need for simply running this project. It has only 3 components, but requires 30gb of memory to be allocated for what reasons I couldn’t possibly imagine. My main project (into which previous implementations have been merged) only requires 9gb (10gb with China users not seeing Icons… integrated) and contains 16 (far more complex) components and 10 services.

 

Hello Chris,

I have been debugging your project, and it appears that there were 2 reasons that the data was not being plotted in the chart.

The first reason was that when the populateChart() method first gets called, the ViewChild “chart” was undefined. This completely skipped the population of the stacked series in your chart. To get around this, I added the bool flag mentioned above with the refreshCompleted method to ensure that the chart is populated.

The second reason was that the public property “this.filter” was not being populated in your buildOutData() method. This looks as if it should have contained the value member paths for your stacked fragments, and after ensuring that this collection is populated, the sample works fine.

Regarding the 30GB memory allocation, this appears to be due to the setting of the max_old_space_size in your npm start command being set to a large number. I have knocked this down to be 8GB and the project still runs fine on my machine.

I am attaching a modified version of the sample project to demonstrate the above.

Please let me know if you have any other questions or concerns on this matter.

8272.DynamicStackedChart.zip

I would love to agree that it is me who is the problem with the memory requirement. Attempting to run with 8GB (binary) gives me the following error:

PS C:\Users\csworen\Downloads\8272.DynamicStackedChart\DynamicStackedChart> npm start

> dynamic-stacked-chart@0.0.0 start
> node --max_old_space_size=8192 node_modules/@angular/cli/bin/ng serve -o --optimization false


<--- Last few GCs --->


<--- JS stacktrace --->


#
# Fatal javascript OOM in GC during deserialization
#

PS C:\Users\csworen\Downloads\8272.DynamicStackedChart\DynamicStackedChart> 

As I increase the memory in max_old_space_size, I it alternates between that (and similar) and random allocation issues with the JavaScript heap. Here's an example at 12GB (decimal):

PS C:\Users\csworen\Downloads\8272.DynamicStackedChart\DynamicStackedChart> npm start

> dynamic-stacked-chart@0.0.0 start
> node --max_old_space_size=12000 node_modules/@angular/cli/bin/ng serve -o --optimization false

Option "optimization" is deprecated: Use the "optimization" option in the browser builder instead.
⠼ Generating browser application bundles (phase: emitting)...node:internal/buffer:959
    super(bufferOrLength, byteOffset, length);
    ^

RangeError: Array buffer allocation failed
    at new ArrayBuffer ()
    at new Uint8Array ()
    at new FastBuffer (node:internal/buffer:959:5)
    at createUnsafeBuffer (node:internal/buffer:1062:12)
    at allocate (node:buffer:409:10)
    at Function.allocUnsafe (node:buffer:374:10)
    at Function.concat (node:buffer:552:25)
    at ConcatSource.buffer (C:\Users\csworen\Downloads\8272.DynamicStackedChart\DynamicStackedChart\node_modules\webpack\node_modules\webpack-sources\lib\ConcatSource.js:69:17)
    at getContent (C:\Users\csworen\Downloads\8272.DynamicStackedChart\DynamicStackedChart\node_modules\webpack\lib\Compiler.js:665:23)
    at processMissingFile (C:\Users\csworen\Downloads\8272.DynamicStackedChart\DynamicStackedChart\node_modules\webpack\lib\Compiler.js:783:24)
PS C:\Users\csworen\Downloads\8272.DynamicStackedChart\DynamicStackedChart> 

And another at 13GB (decimal):

PS C:\Users\csworen\Downloads\8272.DynamicStackedChart\DynamicStackedChart> npm start

> dynamic-stacked-chart@0.0.0 start
> node --max_old_space_size=13000 node_modules/@angular/cli/bin/ng serve -o --optimization false

Option "optimization" is deprecated: Use the "optimization" option in the browser builder instead.
⠙ Generating browser application bundles (phase: sealing)...
<--- Last few GCs --->

[15476:04508F88]    34235 ms: Scavenge 703.3 (730.7) -> 701.0 (731.0) MB, 2.4 / 0.0 ms  (average mu = 0.202, current mu = 0.103) allocation failure
[15476:04508F88]    34242 ms: Scavenge 703.7 (731.0) -> 701.8 (732.0) MB, 4.1 / 0.0 ms  (average mu = 0.202, current mu = 0.103) allocation failure
[15476:04508F88]    34249 ms: Scavenge 704.8 (732.0) -> 702.7 (741.0) MB, 4.2 / 0.0 ms  (average mu = 0.202, current mu = 0.103) allocation failure 


<--- JS stacktrace --->

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
 1: 00FB5D3F v8::internal::Heap::AllocateExternalBackingStore+1551
PS C:\Users\csworen\Downloads\8272.DynamicStackedChart\DynamicStackedChart> 

It finally ran again at 14GB (decimal).

From when it actually runs, I generally math the binary GB requirement and update to make sure it still runs. A couple times, I have had to do the next +.5GB.

I made some modifications to keep this process moving forward. I added single scenario tabs and I sorted data so the color coding between Design and Process is working as expected.

I figured out both, actually (single scenario not populating and reload of all tabs when another tab is selected). I also cleaned up the code/structure a bit.

I think I have resolved every issue I needed fixed. I will let you know if something else comes up. Attaching the final results (for now) for reference.

3252.DynamicStackedChart.zip

Hello Chris,

It’s very strange that this memory issue exists on your machine but not mine. Perhaps it’s just a difference in hardware in this case?

I am glad you were able to resolve the issues you were looking to have fixed in this case. Please let me know if you have any other questions or concerns on this matter.

Ok I lied again. So there's 1 more thing I'm wondering if we can accomplish. For the 3-scenario, single design, 2 parameter charts, is it possible to override the color stagger between the 2 series (stacked area/stacked line)?

Area series is going to be a whole number (units produced/sold) and the line series is going to be a percentage (% of produced units that were sold), but the series will be matching scenarios as they progress.

For example, let's use A-Wing (lego kits) sales/production by month from the previous sample:

• Early_Projection: Date: "2022-Jan", Sales: 185, Production: 235, Sales_Ratio: 78.72%
• Late_Projection: Date: "2022-Jan", Sales: 267, Production:280, Sales_Ratio: 95.36%
• Actual: Date: "2022-Jan", Sales: 233, Production: 275, Sales_Ratio: 84.73%

Users would expect to see 2 data points in the same color from each of these row data:

• Early_Projection: Sales || Production and Sales_Ratio in green
• Late_Projection: Sales || Production and Sales_Ratio in red
• Actual: Sales || Production and Sales_Ratio in blue

But at present, what would happen is this:

• Early_Projection: Sales || Production (GREEN) and Sales_Ratio (RED)
• Late_Projection: Sales || Production (RED) and Sales_Ratio (BLUE)
• Actual: Sales || Production (BLUE) and Sales_Ratio (GREEN)

Which doesn't make sense as a user. They are able to achieve the expected in Excel, but the time it takes to properly stitch, organize, and chart the data is what they're trying to avoid (3-ish hours at least once a week for the most important 4-6 designs).

Also, Users would prefer a traditional line chart over the stacked line (despite asking for the other) with their stacked area data. Can you please update the existing sample for that since there's (again) no documentation on how to do it? I attempted to on my own, but lineSeriesComponent doesn't have a fragments attribute, so I'm a bit lost.

Thanks again.

Hello Chris,

If you define a brushes collection for the IgxDataChart, then the colors that you provide will try to be applied to the series you have placed in your chart by index. So, if you have a brushes collection of “Red, Green, Blue” for example, and you have a stacked series with 3 fragments, the first fragment will be red, the second green, and the third blue. If you were to have a few series that were added to the chart after that, the sequence would repeat.

It is also worth noting that all series are manually able to be colored as well via their brush property, and so you can manually color your series if you are looking to do that instead. It is not currently possible to “stagger” the brushes – it is a 1 to 1 index-based structure. Note, you can add the same color multiple times to the brushes collection though.

Regarding your users wanting a “traditional line chart” over the stacked line, you will not find any “fragments” for the IgxLineSeries component. “Fragments” only exist for stacked series, but you can add multiple line series to the same chart. The difference there is that you need to specify a valueMemberPath on the IgxLineSeries, as again, there are no “fragments” for the single series visualizations.

It is worth noting that adding multiple IgxLineSeries will essentially look the same as an IgxStackedLineSeries though, so I’m a little bit confused on the exact visualization that your users are looking for in this case?

Please let me know if you have any other questions or concerns on this matter.

The exact visualization should match the first example on the Angular Line Chart demo page, which has a working StackBlitz, over the stacked area chart for the other parameter. Is it necessary to create multiple series to cover this or is it more in the nature of adding more valueMemberPath objects?

Also, I'm not sure what I'm doing wrong in attempting to assign the brush property for the stacked line in the example attached. It's just drawing all the lines black.

3581.DynamicStackedChart.zip

Hello Chris,

If you are using the IgxLineSeries object, you would need to create multiple instances of them – there does not exist a way to have a single series object have multiple valueMemberPaths outside of using a stacked series where you associate multiple fragments with multiple valueMemberPaths with the stacked series.

Regarding the brush property, in the case of the IgxStackedLineSeries, you would not set the brush on the series itself – you would set them on the fragments as those are the actual “visual” chart objects – the IgxStackedLineSeries is just the wrapper for them. It also looks like you are trying to define a brushes collection for the IgxStackedLineSeries – this is not supported as that collection is on the chart and will apply to all series in the chart unless the series’ brush property is explicitly set. The brush property for series types takes a string describing the color that you want to apply to the series. You would do this with the single series objects like the IgxLineSeries.

Please let me know if you have any other questions or concerns on this matter.

Sounds like another opportunity for improvement.

It was just communicated that they would prefer to see the line chart over the area chart with neither series stacked. I assume this is also not possible and the work-around would have to be 1 of each being shown side-by-side. Yay, more work for me.

I think I have all the answers I need for this series. Thanks again for being prompt and thorough!