Milestone 4: Chart Component (Chart.js + Blazor JS Interop)

[csharpfritz]

Milestone 4: Chart Component

Summary

Implements the Web Forms Chart control as a Blazor component using Chart.js v4.x via JS interop. This is the project's first JavaScript interop component. Brings the component count from 50/53 (94%) to 51/53 (96%).

What's New

Chart Component Hierarchy

• Chart.razor — Main component inheriting BaseStyledComponent. Renders <canvas> with JS interop to Chart.js.
• ChartSeries.razor — Child component for data series with ChartType, XValueMember, YValueMembers parameters.
• ChartArea.razor — Chart area configuration with AxisX, AxisY parameters.
• ChartLegend.razor — Legend configuration with Docking, Enabled parameters.
• ChartTitle.razor — Title configuration with Text, Docking parameters.
• Axis.cs / DataPoint.cs — Supporting POCOs.
• ChartConfigBuilder.cs — Pure static class mapping component state → Chart.js JSON config (highly testable).
• ChartJsInterop.cs — C# IJSRuntime wrapper with lazy module loading.

JS Interop Infrastructure

• chart-interop.js — ES module bridge: createChart, updateChart, destroyChart.
• chart.min.js — Chart.js v4.4.8 placeholder stub (needs real bundle for production).

Supported Chart Types (Phase 1)

Column, Line, Bar, Pie, Area, Doughnut, Scatter, StackedColumn — covering 90%+ of real-world usage.

Enums

SeriesChartType (35 values for API fidelity), ChartPalette (12 palettes), Docking, ChartDashStyle.

HTML Output Exception

Web Forms Chart renders <img src=\"/ChartImg.axd?...\">. Blazor Chart renders <canvas>. Justified: server-side image generation is architecturally impossible in Blazor; migration value is in the API, not the HTML.

Testing

• ✅ 866 bUnit tests (140 new Chart tests) — all passing
• ✅ 124 integration tests (19 new Chart tests) — all passing

Bug Fixes (Boy Scout Rule)

• Fixed ASP.NET structured log console error filter in integration tests (was causing 97 test failures)
• Fixed external resource loading error filter (placeholder images)
• Removed duplicate FileUpload route (Pages/ControlSamples/FileUpload/Default.razor)
• Fixed ChangePassword and CreateUserWizard test assertions for EditForm interactive rendering

Documentation

• docs/DataControls/Chart.md — Full component documentation with migration notes
• docs/Migration/DeferredControls.md — Updated Chart status
• Updated mkdocs.yml, README.md, status.md

Sample Pages

8 sample pages under ControlSamples/Chart/:
Index (Column), Line, Bar, Pie, Area, Doughnut, Scatter, StackedColumn

Design Decisions

• Chart.js selected over D3 (wrong abstraction), ApexCharts (2x bundle), Plotly (3-4MB)
• CascadingParameter "ParentChart" pattern for child registration (follows MultiView/View)
• BaseStyledComponent base class (Web Forms Chart inherits WebControl)
• IAsyncDisposable for JS interop cleanup

In general, to fix this kind of issue, we should replace a foreach loop that scans a sequence and conditionally processes only elements that satisfy a predicate with an explicit LINQ filter such as .Where(predicate) (and possibly .FirstOrDefault(), .Select(...), etc., as appropriate). This makes the code’s intent—“work with the first series that has points”—explicit and reduces nesting.

Here, the loop from lines 101–114 finds the first ChartSeriesConfig whose Points collection is non‑null and non‑empty, then builds labels from that series’ points and breaks. We can preserve this behaviour by:

1. Selecting that series explicitly using LINQ:

   var firstSeriesWithPoints = seriesList
       .FirstOrDefault(s => s.Points != null && s.Points.Count > 0);

2. If such a series exists, building the labels from firstSeriesWithPoints.Points in a simple foreach without extra conditionals or break.

Concretely in BuildDataSection within src/BlazorWebFormsComponents/ChartConfigBuilder.cs, replace the foreach (var s in seriesList) block that builds labels with:

• A var firstSeriesWithPoints = ...FirstOrDefault(...) statement.
• An if (firstSeriesWithPoints != null) block iterating over its Points and adding their labels/XValues to the labels list.

No new imports are needed: System.Linq is already imported, and FirstOrDefault is a standard LINQ method. The rest of the method, including the use of labels and datasets, remains unchanged.

In general, to fix this pattern you keep a single assignment and replace the if/else with a conditional (? :) that chooses between the two values that were previously assigned in each branch. This keeps the behavior identical while making it clearer that the only difference is which value is used.

For this specific case in src/BlazorWebFormsComponents/ChartConfigBuilder.cs, lines 135–148, we should replace:

• The entire if (s.ChartType == SeriesChartType.Point) { ... } else { ... } block

with a single assignment:

• dataset["data"] = s.ChartType == SeriesChartType.Point ? <point-expression> : <other-expression>;

The two existing expressions (s.Points.Select(...dictionary...) and s.Points.Select(...double...)) will become the true/false branches of the ternary. We must preserve the .ToList() calls and the existing dictionary and selection logic exactly, only restructuring into a conditional expression. No new imports or helper methods are needed; everything can be expressed inline where the if/else currently sits.

In general, to fix this issue you should replace patterns of if (dict.ContainsKey(key)) { var v = dict[key]; ... } with if (dict.TryGetValue(key, out var v)) { ... }, which combines the existence check and retrieval into a single dictionary operation.

For this specific code in src/BlazorWebFormsComponents/ChartConfigBuilder.cs, update both the "x" and "y" scale-handling blocks to use TryGetValue on the scales dictionary. Instead of checking scales.ContainsKey("x") and then accessing scales["x"], call scales.TryGetValue("x", out var existingObj), verify that existingObj is a Dictionary<string, object>, and then merge the axis configuration into that dictionary. If the key does not exist (or does not hold the expected type), fall back to assigning scales["x"] = xAxis as before. Do the same for the "y" axis. This preserves existing behavior, but ensures only one dictionary lookup in the common path. No new imports or types are required; you only need to introduce local variables for the out values and type checks.

In general, to fix this issue you replace the sequence “check with ContainsKey, then read with indexer” with a single call to TryGetValue, which both checks for existence and retrieves the value in one dictionary lookup. You then operate on the retrieved value if the call succeeds, or handle the absence of the key in the else branch.

In this file, there are two such patterns: one for the "x" key (lines 230–235) and one for the "y" key (lines 245–249). For each, we can change:

• if (scales.ContainsKey("x")) { var existing = (Dictionary<string, object>)scales["x"]; ... }
• if (scales.ContainsKey("y")) { var existing = (Dictionary<string, object>)scales["y"]; ... }

to use TryGetValue:

• if (scales.TryGetValue("x", out var xScaleObj)) { var existing = (Dictionary<string, object>)xScaleObj; ... }
• if (scales.TryGetValue("y", out var yScaleObj)) { var existing = (Dictionary<string, object>)yScaleObj; ... }

The cast to Dictionary<string, object> still happens (and will still throw if the stored value is of the wrong type), preserving existing behavior. No new methods, imports, or additional definitions are required; we only change the conditional and how we fetch the existing scale dictionary. All changes are localized to src/BlazorWebFormsComponents/ChartConfigBuilder.cs in the shown region.

In general, to fix this kind of issue you replace an if/else where both branches assign to the same variable with a single assignment whose right-hand side is a ternary expression. That keeps the logic equivalent but shorter and more expressive.

Here, we focus only on the block:

if (yValue != null)
{
	point.YValues = new[] { Convert.ToDouble(yValue) };
}
else
{
	point.YValues = Array.Empty<double>();
}

The best fix is to assign point.YValues once, using a ternary on yValue != null to pick between the two alternatives, while ensuring Convert.ToDouble(yValue) is still evaluated only when yValue is non-null. The resulting line:

point.YValues = yValue != null ? new[] { Convert.ToDouble(yValue) } : Array.Empty<double>();

keeps behavior identical: if yValue is non-null, it converts it to double and wraps it in a single-element array; otherwise, it sets YValues to an empty array. No new methods, imports, or definitions are required, and only the shown lines inside src/BlazorWebFormsComponents.Test/ChartTests.cs need to be changed.

In general, to fix this issue you replace an if/else statement where both branches only assign or return a value with a single assignment or return that uses the ternary (? :) operator. This expresses the conditional choice more directly and concisely.

Here, the if/else sets config.Points to either ExtractDataPointsFromItems() or Points. We should replace the whole if/else block with one assignment:

config.Points = (Items != null && !string.IsNullOrEmpty(YValueMembers))
	? ExtractDataPointsFromItems()
	: Points;

This preserves the existing condition and behavior. To retain the intent of the “Fall back to manually-specified Points” comment, we can move that comment onto the ternary’s false branch or just above the assignment. No new methods, imports, or other definitions are required. The change is localized to the ToConfig method in src/BlazorWebFormsComponents/ChartSeries.razor.cs around lines 112–121.

In general, to fix generic catch clauses, you should replace them with one or more catch blocks that name the specific exception types you intend to handle, and allow unexpected exceptions to propagate. This avoids accidentally hiding serious problems while still handling the failure modes you care about.

For this specific method, we only want to treat conversion failures as “return false.” According to .NET documentation, Convert.ToDouble(object) can throw InvalidCastException, FormatException, and OverflowException for non-null inputs that cannot be converted. We should explicitly catch these three and return false in each case. Any other exception (e.g., OutOfMemoryException) should not be swallowed and will bubble up, which is safer.

Concretely, in src/BlazorWebFormsComponents/ChartSeries.razor.cs, in the TryConvertToDouble method’s default case, replace the bare catch block starting at line 233 with three specific catch blocks: one each for InvalidCastException, FormatException, and OverflowException, all returning false. No new using directives are needed because these exception types are already in System, which is imported at the top. This preserves the current behavior for ordinary conversion problems while complying with the CodeQL recommendation.