sadpandajoe commented on code in PR #42910:
URL: https://github.com/apache/superset/pull/42910#discussion_r4322114381


##########
superset-frontend/plugins/plugin-chart-echarts/src/BigNumber/BigNumberPeriodOverPeriod/PopKPI.test.tsx:
##########
@@ -0,0 +1,107 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ *   http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied.  See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+import { render, screen } from 'spec/helpers/testing-library';
+import PopKPI from './PopKPI';
+import { PopKPIProps } from './types';
+
+const baseProps: PopKPIProps = {
+  height: 200,
+  width: 400,
+  data: [],
+  metrics: [],
+  metricName: 'Sales',
+  showMetricName: true,
+  headerText: '',
+  boldText: true,
+  bigNumber: '120',
+  prevNumber: '100',
+  valueDifference: '20',
+  percentDifferenceFormattedString: '20%',
+  compType: 'r',
+  percentDifferenceNumber: 0.2,
+  subtitleFontSize: 0.15,
+  shift: '',
+  headerFontSize: 'l',
+  subheaderFontSize: 'm',
+  comparisonColorEnabled: true,
+};
+
+test('renders the up arrow and metric values when the metric increased', () => 
{
+  render(<PopKPI {...baseProps} />);
+
+  expect(screen.getByText('↑')).toBeInTheDocument();
+  expect(screen.getByText('120')).toBeInTheDocument();
+  expect(screen.getByText('Sales')).toBeInTheDocument();
+});
+
+test('renders the down arrow when the metric decreased', () => {
+  render(
+    <PopKPI
+      {...baseProps}
+      percentDifferenceNumber={-0.2}
+      valueDifference="-20"
+    />,
+  );
+
+  expect(screen.getByText('↓')).toBeInTheDocument();
+  expect(screen.getByText('-20')).toBeInTheDocument();
+});
+
+// The precise color resolution (legacy `comparisonColorScheme` fallback,
+// custom hex precedence, the neutral disabled state) is covered by pure
+// unit tests against `resolveComparisonColorKeys` / `getComparisonColorTokens`
+// in utils.test.ts, since emotion's `css` prop styles aren't reliably
+// observable through jsdom's computed styles. These tests instead confirm
+// PopKPI renders without crashing across the same prop combinations.
+test('renders without crashing with only the legacy comparisonColorScheme 
(backward compatibility)', () => {
+  render(<PopKPI {...baseProps} comparisonColorScheme="Red" />);
+
+  expect(screen.getByText('↑')).toBeInTheDocument();
+});
+
+test('renders without crashing with a custom increaseColor hex', () => {

Review Comment:
   These three color tests only assert that the arrow renders, so they still 
pass if PopKPI stops applying the resolved colors. For example, with 
`comparisonColorScheme="Red"` and `increaseColor="#336699"`, dropping the 
wiring would paint the arrow with the legacy error color and `↑` would still be 
found. The helper tests cover the conversion but not that PopKPI uses it. Could 
this assert the arrow and pill colors with `toHaveStyleRule`, plus the neutral 
styling when `comparisonColorEnabled` is false?



##########
superset-frontend/src/explore/components/controls/IntervalColorsControl/index.tsx:
##########
@@ -0,0 +1,114 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ *   http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied.  See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+import { t } from '@apache-superset/core/translation';
+import { getCategoricalSchemeRegistry } from '@superset-ui/core';
+import {
+  isRangesInputComplete,
+  hasTrailingBlankToken,
+} from '@superset-ui/plugin-chart-echarts';
+import ControlHeader from '../../ControlHeader';
+import ColorPickerControl from '../ColorPickerControl';
+import type { ColorPickerValue } from '../ColorPickerControl';
+import {
+  RangeRow as IntervalRow,
+  RangeLabel as BoundLabel,
+  replaceColorAtIndex,
+} from '../shared/RangeColorRow';
+import { IntervalColorsControlProps } from './types';
+import {
+  parseIntervalBounds as parseBounds,
+  resolveLegacyIntervalColors as resolveLegacyColors,
+} from './legacyColors';
+
+/**
+ * Per-interval color editor for the Gauge chart. Row *count* is driven by
+ * the sibling `intervals` control (one row per parsed upper bound) so bound
+ * values keep a single source of truth; this control only owns colors,
+ * stored as an array of hex strings positionally matched to those bounds.
+ */
+export default function IntervalColorsControl({
+  value,
+  onChange,
+  intervals,
+  legacyIntervalColorIndices,
+  colorScheme,
+  ...headerProps
+}: IntervalColorsControlProps) {
+  const bounds = parseBounds(intervals);
+  // `parseBounds` leniently drops blank tokens (e.g. mid-edit "20,,60"),
+  // which would otherwise shift colors to the wrong bound once the blank is
+  // filled back in -- same hazard `BulletRangeColorsControl` guards against.
+  const boundsComplete = isRangesInputComplete(intervals);
+  // See the identical guard in `BulletRangeColorsControl`: while `intervals`
+  // ends in the one tolerated trailing blank (the last bound is being
+  // retyped), `bounds` is transiently one entry short. Writing a color at
+  // that moment must not truncate the array to that shorter length, or the
+  // color for the bound being retyped is permanently lost.
+  const writeLength = hasTrailingBlankToken(intervals)

Review Comment:
   While `intervals` ends in the tolerated trailing blank, `writeLength` is the 
shortened bounds length, so a color edit persists a shorter explicit array and 
turns off the legacy fallback. For example, with bounds `20,40,60` and legacy 
indices `3,2,1`, erase `60`, edit the first color while the bounds read 
`20,40,`, then restore `60`. The third band now renders positional color 3 
instead of its original legacy color 1. Should the color edit be held until the 
bounds are complete, or the legacy colors be resolved for the full previous 
length?



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to