Move TargetedMS QC/chart UI off ExtJS to plain JS + HTML by ankurjuneja · Pull Request #1257 · LabKey/targetedms

ankurjuneja · 2026-07-07T23:19:50Z

Rationale

We are gradually removing our dependency on ExtJS. ExtJS is old, heavy, and something we want to stop using. Each of these screens used ExtJS only as a wrapper around plain data or existing non-ExtJS chart code, so we can swap in simple HTML, plain JavaScript, and jQuery without changing what the user sees. This makes the code lighter, easier to read, and easier to maintain.

Related Pull Requests

Changes

Trace metric dialog (resources/web/PanoramaPremium/window/AddNewTraceMetricWindow.js)
Pareto plot (webapp/TargetedMS/js/ParetoPlotPanel.js)
Calibration curve (webapp/TargetedMS/js/CalibrationCurve.js)
Summary charts (src/org/labkey/targetedms/view/summaryChartsView.jsp)

labkey-jeckels · 2026-07-27T17:37:31Z

+        const title = op === 'insert' ? 'Add New Trace Metric' : 'Edit Trace Metric';
+
+        // In update mode, pick the mode based on the stored values; default to the time-value mode.
+        const isTraceValueMode = op === 'update' && metric.TraceValue > 0;


The check on line 79 allows zeros when saving, but this treats them as a sentinel. Probably best to make line 79 ensure a positive value, which matches the old validation.

Further/related concern:

Issue: const isTraceValueMode = op === 'update' && metric.TraceValue > 0; picks the radio button by looking at TraceValue alone, but the server resolves the opposite way — TargetedMSManager line ~2910 checks timeValueOption first and only falls through to traceValue when it is null.

Why it matters: Every trace metric saved by the old dialog can have both configurations populated, because the old saveNewMetric wrote only the chosen mode's columns and never cleared the other. Opening such a row now shows the trace-value radio selected with a trace threshold filled in, while the plot on the dashboard is still being computed from TimeValueOption/MinTimeValue/MaxTimeValue. That is the same class of "UI shows one thing, server does another" bug the rest of this change sets out to eliminate.

Suggestion: const isTraceValueMode = op === 'update' && !metric.TimeValueOption && metric.TraceValue > 0;

labkey-jeckels · 2026-07-27T17:39:17Z

+            return String(a.TextId).localeCompare(String(b.TextId));
+        });
+        let html = '<option value="">-- Select trace --</option>';
+        traces.forEach(function(row) {


Low priority, but if the previously saved value is no longer present, it won't be in the list. The old code always added the saved value. We could do the same here.

labkey-jeckels · 2026-07-27T17:39:56Z

+        const metricName = $('#lk-trace-metric-name').val().trim();
+        checkMetricNameExists(metricName, function(exists) {
+            if (exists) {
+                showError('A metric with the name "' + LABKEY.Utils.encodeHtml(metricName) + '" already exists. Please choose a different name.');


showError uses .text() so this will be double-encoded. Remove the encoding here.

labkey-jeckels · 2026-07-27T17:46:40Z

+            areaElement.style.width = parseInt(widthInput.value) + 'px';
+            areaElement.style.height = parseInt(heightInput.value) + 'px';
+            timeElement.style.width = parseInt(widthInput.value) + 'px';
+            timeElement.style.height = parseInt(heightInput.value) + 'px';


Ideally we'd handle a NaN as type="number" isn't particularly strict.

labkey-jeckels · 2026-07-27T18:51:08Z

-                        this.queryError.setVisible(true);
-                    }
-                });
+            LABKEY.Query.saveRows({


In my local testing, this can be sluggish to save. There's no feedback for the user while it's working, which led me to click on Save a second time, which then produced a key violation. This change presumably hasn't impacted the perf, but it would be nice to show a spinner and disable the buttons to avoid a double-submit.

labkey-jeckels · 2026-07-27T18:55:00Z

    public void addClientDependencies(ClientDependencies dependencies)
    {
-        dependencies.add("Ext4");
+        dependencies.add("Ext4"); // still needed by QCMetricConfigLoader.js


Looks like it's just for JSON parsing. Can we migrate that?

Co-authored-by: Josh Eckels <jeckels@labkey.com>

…xtJS port

labkey-jeckels

Minor suggestions but not need for further review unless you want it.

labkey-jeckels · 2026-08-20T00:50:03Z

+    // The ExtJS stores prepended "All"/"None" entries, so the original visibility checks were
+    // count-based (e.g. store.count() > 2). Translate those to list-size checks here.


Is this important post-migration?

labkey-jeckels · 2026-08-20T18:38:18Z

+        const title = op === 'insert' ? 'Add New Trace Metric' : 'Edit Trace Metric';
+
+        // In update mode, pick the mode based on the stored values; default to the time-value mode.
+        const isTraceValueMode = op === 'update' && metric.TraceValue > 0;


Further/related concern:

Issue: const isTraceValueMode = op === 'update' && metric.TraceValue > 0; picks the radio button by looking at TraceValue alone, but the server resolves the opposite way — TargetedMSManager line ~2910 checks timeValueOption first and only falls through to traceValue when it is null.

Why it matters: Every trace metric saved by the old dialog can have both configurations populated, because the old saveNewMetric wrote only the chosen mode's columns and never cleared the other. Opening such a row now shows the trace-value radio selected with a trace threshold filled in, while the plot on the dashboard is still being computed from TimeValueOption/MinTimeValue/MaxTimeValue. That is the same class of "UI shows one thing, server does another" bug the rest of this change sets out to eliminate.

Suggestion: const isTraceValueMode = op === 'update' && !metric.TimeValueOption && metric.TraceValue > 0;

Co-authored-by: Josh Eckels <jeckels@labkey.com>

ankurjuneja added 5 commits July 7, 2026 13:47

trace metric dialog from extjs to jquery/html

2fecd60

pareto plot from extjs to jquery/html

30803c5

calibration curve from extjs to jquery/html

4ed1606

summaryViewCharts from extjs to jquery/html

d6cebe5

Merge branch 'develop' into fb_1249_extJS

afcd89b

ankurjuneja requested a review from labkey-jeckels July 20, 2026 23:41

cnathe reviewed Jul 21, 2026

View reviewed changes

Comment thread src/org/labkey/targetedms/view/calibrationCurve.jsp Outdated

labkey-jeckels reviewed Jul 30, 2026

View reviewed changes

ankurjuneja and others added 8 commits August 16, 2026 10:52

Merge branch 'develop' into fb_1249_extJS

ed16e12

Update src/org/labkey/targetedms/view/summaryChartsView.jsp

6378b95

Co-authored-by: Josh Eckels <jeckels@labkey.com>

Update src/org/labkey/targetedms/view/summaryChartsView.jsp

4ae629a

Co-authored-by: Josh Eckels <jeckels@labkey.com>

Update webapp/TargetedMS/js/CalibrationCurve.js

0b43eea

Co-authored-by: Josh Eckels <jeckels@labkey.com>

code review comments

7baaed5

claude code review changes

5d29c2d

more fixes

f8f8610

Name chart size inputs and fix TargetedMSLibraryTest locators after E…

8f0bdfa

…xtJS port

ankurjuneja requested a review from labkey-jeckels August 19, 2026 13:23

labkey-jeckels approved these changes Aug 20, 2026

View reviewed changes

ankurjuneja and others added 4 commits August 21, 2026 09:27

Apply suggestions from code review

1acc0f7

Co-authored-by: Josh Eckels <jeckels@labkey.com>

Update webapp/TargetedMS/js/CalibrationCurve.js

6a22494

Co-authored-by: Josh Eckels <jeckels@labkey.com>

code review changes

1daa537

Merge remote-tracking branch 'origin/fb_1249_extJS' into fb_1249_extJS

6e2e76e

		// The ExtJS stores prepended "All"/"None" entries, so the original visibility checks were
		// count-based (e.g. store.count() > 2). Translate those to list-size checks here.

Uh oh!

Conversation

ankurjuneja commented Jul 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Rationale

Related Pull Requests

Changes

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

labkey-jeckels left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

ankurjuneja commented Jul 7, 2026 •

edited

Loading