codeant-ai-for-open-source[bot] commented on code in PR #35897:
URL: https://github.com/apache/superset/pull/35897#discussion_r2765787850
##########
superset-frontend/plugins/plugin-chart-table/src/TableChart.tsx:
##########
@@ -935,18 +939,46 @@ export default function TableChart<D extends DataRecord =
DataRecord>(
formatter.getColorFromValue(valueToFormat);
if (!formatterResult) return;
- if (formatter.toTextColor) {
+ if (
+ formatter.objectFormatting === ObjectFormattingEnum.TEXT_COLOR
+ ) {
color = formatterResult.slice(0, -2);
+ } else if (
+ formatter.objectFormatting === ObjectFormattingEnum.CELL_BAR
+ ) {
+ if (showCellBars)
+ backgroundColorCellBar = formatterResult.slice(0, -2);
Review Comment:
**Suggestion:** Cell-bar conditional formatting currently checks only the
global `showCellBars` flag, ignoring per-column `config.showCellBars`, so if
cell bars are enabled for a specific column while globally disabled, bars will
render (because `valueRange` uses the column override) but the formatter's
color will never be applied, leading to inconsistent behavior. [logic error]
<details>
<summary><b>Severity Level:</b> Major ⚠️</summary>
```mdx
- ❌ Cell-bar color ignored for column override.
- ⚠️ Column-level showCellBars produces inconsistent UI.
- ⚠️ Conditional formatting UX confusing for users.
```
</details>
```suggestion
const isCellBarVisible =
config.showCellBars === undefined
? showCellBars
: config.showCellBars;
if (isCellBarVisible) {
backgroundColorCellBar = formatterResult.slice(0, -2);
}
```
<details>
<summary><b>Steps of Reproduction ✅ </b></summary>
```mdx
1. Build and open a table where a specific column has config.showCellBars =
true while the
global showCellBars prop passed to TableChart is false. The valueRange
calculation uses
(config.showCellBars === undefined ? showCellBars : config.showCellBars) at
lines ~880–885
to decide if a bar should render.
2. Add a CELL_BAR conditional formatter for that same column so
getColorFromValue will
return a formatterResult (formatters created by
packages/superset-ui-chart-controls/src/utils/getColorFormatters.ts).
3. On render, execution reaches the formatter application in TableChart.tsx
(lines
942–954). The current code only assigns backgroundColorCellBar when the
global
showCellBars is true, ignoring the column override.
4. Observe a cell bar rendered (because valueRange is true from the column
override) but
the bar color from the formatter is not applied (bar uses default
cellBackground),
producing a mismatch between user config and UI.
```
</details>
<details>
<summary><b>Prompt for AI Agent 🤖 </b></summary>
```mdx
This is a comment left during a code review.
**Path:** superset-frontend/plugins/plugin-chart-table/src/TableChart.tsx
**Line:** 949:950
**Comment:**
*Logic Error: Cell-bar conditional formatting currently checks only the
global `showCellBars` flag, ignoring per-column `config.showCellBars`, so if
cell bars are enabled for a specific column while globally disabled, bars will
render (because `valueRange` uses the column override) but the formatter's
color will never be applied, leading to inconsistent behavior.
Validate the correctness of the flagged issue. If correct, How can I resolve
this? If you propose a fix, implement it and please make it concise.
```
</details>
##########
superset-frontend/plugins/plugin-chart-table/src/TableChart.tsx:
##########
@@ -935,18 +939,46 @@ export default function TableChart<D extends DataRecord =
DataRecord>(
formatter.getColorFromValue(valueToFormat);
if (!formatterResult) return;
- if (formatter.toTextColor) {
+ if (
+ formatter.objectFormatting === ObjectFormattingEnum.TEXT_COLOR
+ ) {
color = formatterResult.slice(0, -2);
+ } else if (
+ formatter.objectFormatting === ObjectFormattingEnum.CELL_BAR
+ ) {
+ if (showCellBars)
+ backgroundColorCellBar = formatterResult.slice(0, -2);
} else {
backgroundColor = formatterResult;
+ valueRangeFlag = false;
}
};
columnColorFormatters
- .filter(formatter => formatter.column === column.key)
- .forEach(formatter => applyFormatter(formatter, value));
+ .filter(formatter => {
+ if (formatter.columnFormatting) {
+ return formatter.columnFormatting === column.key;
+ }
+ return formatter.column === column.key;
+ })
+ .forEach(formatter => {
+ let valueToFormat;
+ if (formatter.columnFormatting) {
+ const index = Object.keys(row.original).findIndex(
+ key => key === formatter.column,
+ );
+ valueToFormat = row.values[index];
+ } else {
+ valueToFormat = value;
+ }
+ applyFormatter(formatter, valueToFormat);
+ });
columnColorFormatters
- .filter(formatter => formatter.toAllRow)
+ .filter(
+ formatter =>
+ formatter.columnFormatting ===
+ ObjectFormattingEnum.ENTIRE_ROW,
+ )
Review Comment:
**Suggestion:** Entire-row conditional formatting is being detected via
`formatter.columnFormatting === ObjectFormattingEnum.ENTIRE_ROW`, but the
formatter structure already has a dedicated `toAllRow` flag for this purpose,
so the current filter will likely never match and entire-row rules will never
be applied. [logic error]
<details>
<summary><b>Severity Level:</b> Major ⚠️</summary>
```mdx
- ❌ Entire-row conditional formatting not applied.
- ⚠️ Row-level highlight rules silently ignored.
- ⚠️ Users misled by missing row formatting.
```
</details>
```suggestion
.filter(formatter => formatter.toAllRow)
```
<details>
<summary><b>Steps of Reproduction ✅ </b></summary>
```mdx
1. Look at getColorFormatters in
packages/superset-ui-chart-controls/src/utils/getColorFormatters.ts where
formatters are
produced and include the property toAllRow: config?.toAllRow (see that util
where
accumulator objects include toAllRow).
2. Configure an entire-row conditional formatting rule (toAllRow true) in
the chart
configuration so getColorFormatters will set toAllRow on the resulting
formatter.
3. Render TableChart; the code that tries to apply entire-row rules is at
lines 976–984 in
TableChart.tsx and filters formatters by formatter.columnFormatting ===
ObjectFormattingEnum.ENTIRE_ROW instead of checking formatter.toAllRow.
4. Observe entire-row rules are not applied (cells remain unformatted)
because the filter
does not match the toAllRow flag produced by getColorFormatters.
```
</details>
<details>
<summary><b>Prompt for AI Agent 🤖 </b></summary>
```mdx
This is a comment left during a code review.
**Path:** superset-frontend/plugins/plugin-chart-table/src/TableChart.tsx
**Line:** 977:981
**Comment:**
*Logic Error: Entire-row conditional formatting is being detected via
`formatter.columnFormatting === ObjectFormattingEnum.ENTIRE_ROW`, but the
formatter structure already has a dedicated `toAllRow` flag for this purpose,
so the current filter will likely never match and entire-row rules will never
be applied.
Validate the correctness of the flagged issue. If correct, How can I resolve
this? If you propose a fix, implement it and please make it concise.
```
</details>
##########
superset-frontend/packages/superset-ui-chart-controls/src/types.ts:
##########
@@ -486,12 +486,16 @@ export type ConditionalFormattingConfig = {
toAllRow?: boolean;
toTextColor?: boolean;
useGradient?: boolean;
+ columnFormatting?: string;
+ objectFormatting?: string;
};
export type ColorFormatters = {
column: string;
toAllRow?: boolean;
toTextColor?: boolean;
+ columnFormatting?: string;
+ objectFormatting?: string;
Review Comment:
**Suggestion:** In the `ColorFormatters` type, `objectFormatting` is also
typed as a plain string instead of `ObjectFormattingEnum`, which weakens type
safety and can cause mismatches if other code assumes only the enum's values
are used. [type error]
<details>
<summary><b>Severity Level:</b> Major ⚠️</summary>
```mdx
- ❌ Color formatters not applied to intended object types.
- ⚠️ ConditionalFormattingControl rendering incorrect formatting.
- ⚠️ Tests may accept invalid formatter configs.
```
</details>
```suggestion
objectFormatting?: ObjectFormattingEnum;
```
<details>
<summary><b>Steps of Reproduction ✅ </b></summary>
```mdx
1. Open the ColorFormatters type declaration in
`superset-frontend/packages/superset-ui-chart-controls/src/types.ts` around
lines 493-501
and observe `objectFormatting?: string;` at line 498 (this is the type
returned/passed
where formatters are configured).
2. In any place that builds a ColorFormatters entry (for example test
fixtures or runtime
formatter providers exercised by
`src/explore/components/controls/ConditionalFormattingControl/FormattingPopoverContent.test.tsx`
as suggested by the PR), set `objectFormatting` to a non-enum string (e.g.,
`'cellBar'` or
`'INVALID'`). The current `string` type allows this at compile time.
3. Run the UI or unit tests. The code that consumes ColorFormatters (the
ConditionalFormattingControl and rendering paths referenced in types.ts
comments) compares
`objectFormatting` values to ObjectFormattingEnum constants. Because the
provided string
does not equal one of the enum members, the formatter is not applied to the
intended
object (cell bar, text color, background).
4. Observe the resulting misbehavior: color formatters that were intended
for CELL_BAR /
BACKGROUND_COLOR / TEXT_COLOR do not execute, causing incorrect or missing
formatting in
the Conditional Formatting UI and in rendered tables.
```
</details>
<details>
<summary><b>Prompt for AI Agent 🤖 </b></summary>
```mdx
This is a comment left during a code review.
**Path:** superset-frontend/packages/superset-ui-chart-controls/src/types.ts
**Line:** 498:498
**Comment:**
*Type Error: In the `ColorFormatters` type, `objectFormatting` is also
typed as a plain string instead of `ObjectFormattingEnum`, which weakens type
safety and can cause mismatches if other code assumes only the enum's values
are used.
Validate the correctness of the flagged issue. If correct, How can I resolve
this? If you propose a fix, implement it and please make it concise.
```
</details>
##########
superset-frontend/src/explore/components/controls/ConditionalFormattingControl/types.ts:
##########
@@ -32,6 +32,8 @@ export type ConditionalFormattingConfig = {
toAllRow?: boolean;
toTextColor?: boolean;
useGradient?: boolean;
+ columnFormatting: string;
+ objectFormatting: string;
};
export type ConditionalFormattingControlProps = ControlComponentProps<
Review Comment:
**Suggestion:** The shape of column options is duplicated inline for the
control props instead of reusing the dedicated option type, which can easily
lead to the two representations diverging over time (for example if a new
property is added to the shared type) and cause subtle type mismatches and bugs
between the control and the popover that consume these objects. Reusing the
shared type here removes this duplication and keeps all consumers in sync.
[possible bug]
<details>
<summary><b>Severity Level:</b> Major ⚠️</summary>
```mdx
- ⚠️ ConditionalFormattingControl type mismatches during refactors.
- ⚠️ Developer friction when changing column shape.
- ⚠️ Potential compile errors after ColumnOption evolution.
```
</details>
```suggestion
columnOptions: ColumnOption[];
```
<details>
<summary><b>Steps of Reproduction ✅ </b></summary>
```mdx
1. Inspect the type definitions in
superset-frontend/src/explore/components/controls/ConditionalFormattingControl/types.ts:
the inline columnOptions type exists at line 39 while a shared ColumnOption
interface is
added later at lines 61-65.
2. Modify ColumnOption (lines 61-65) later (for example add a new property
like tooltip?:
string) and run TypeScript checks (yarn tsc). The inline columnOptions type
at line 39
will not reflect the new property, causing diverging type expectations and
compile-time/type errors in places that use columnOptions vs allColumns.
3. Reproduce by updating a component that fills columnOptions with objects
matching the
new ColumnOption shape: consumers typed with the inline shape will show type
mismatches or
require manual edits.
4. This is a maintainability issue: unifying both to ColumnOption[] (as
proposed) prevents
future drift and immediate type mismatches when the shared type evolves.
```
</details>
<details>
<summary><b>Prompt for AI Agent 🤖 </b></summary>
```mdx
This is a comment left during a code review.
**Path:**
superset-frontend/src/explore/components/controls/ConditionalFormattingControl/types.ts
**Line:** 39:39
**Comment:**
*Possible Bug: The shape of column options is duplicated inline for the
control props instead of reusing the dedicated option type, which can easily
lead to the two representations diverging over time (for example if a new
property is added to the shared type) and cause subtle type mismatches and bugs
between the control and the popover that consume these objects. Reusing the
shared type here removes this duplication and keeps all consumers in sync.
Validate the correctness of the flagged issue. If correct, How can I resolve
this? If you propose a fix, implement it and please make it concise.
```
</details>
##########
superset-frontend/plugins/plugin-chart-table/src/TableChart.tsx:
##########
@@ -935,18 +939,46 @@ export default function TableChart<D extends DataRecord =
DataRecord>(
formatter.getColorFromValue(valueToFormat);
if (!formatterResult) return;
- if (formatter.toTextColor) {
+ if (
+ formatter.objectFormatting === ObjectFormattingEnum.TEXT_COLOR
+ ) {
color = formatterResult.slice(0, -2);
+ } else if (
+ formatter.objectFormatting === ObjectFormattingEnum.CELL_BAR
+ ) {
+ if (showCellBars)
+ backgroundColorCellBar = formatterResult.slice(0, -2);
} else {
backgroundColor = formatterResult;
+ valueRangeFlag = false;
}
};
columnColorFormatters
- .filter(formatter => formatter.column === column.key)
- .forEach(formatter => applyFormatter(formatter, value));
+ .filter(formatter => {
+ if (formatter.columnFormatting) {
+ return formatter.columnFormatting === column.key;
+ }
+ return formatter.column === column.key;
+ })
+ .forEach(formatter => {
+ let valueToFormat;
+ if (formatter.columnFormatting) {
+ const index = Object.keys(row.original).findIndex(
+ key => key === formatter.column,
+ );
+ valueToFormat = row.values[index];
Review Comment:
**Suggestion:** When applying a formatter that targets a different column
via `columnFormatting`, the code derives the value to format by indexing into
`row.values` using an index computed from `Object.keys(row.original)`, which
can become misaligned or `-1` if columns are hidden or reordered, leading to
incorrect values being formatted or `undefined` being passed into the
formatter. [logic error]
<details>
<summary><b>Severity Level:</b> Major ⚠️</summary>
```mdx
- ❌ Cross-column formatings use wrong source values.
- ⚠️ Conditional formatting correctness compromised.
- ⚠️ TableChart displays inconsistent formatted results.
```
</details>
```suggestion
// Use the original row object to fetch the source column
value directly
valueToFormat = row.original[formatter.column];
```
<details>
<summary><b>Steps of Reproduction ✅ </b></summary>
```mdx
1. Produce conditional format rules that reference another column
(formatter.columnFormatting set) via the UI so getColorFormatters creates
formatters
passed into TableChart.
2. Render the table; TableChart executes the formatter loop in the Cell
renderer at lines
963–974 in superset-frontend/plugins/plugin-chart-table/src/TableChart.tsx.
3. The code computes index = Object.keys(row.original).findIndex(...) and
then reads
row.values[index]. If the data object's key order, column visibility, or
react-table
column ordering differs from Object.keys(row.original), the index is
incorrect or -1.
4. The formatter receives the wrong value or undefined, so conditional
formatting uses
incorrect source data and cells are miscolored or unformatted.
```
</details>
<details>
<summary><b>Prompt for AI Agent 🤖 </b></summary>
```mdx
This is a comment left during a code review.
**Path:** superset-frontend/plugins/plugin-chart-table/src/TableChart.tsx
**Line:** 966:969
**Comment:**
*Logic Error: When applying a formatter that targets a different column
via `columnFormatting`, the code derives the value to format by indexing into
`row.values` using an index computed from `Object.keys(row.original)`, which
can become misaligned or `-1` if columns are hidden or reordered, leading to
incorrect values being formatted or `undefined` being passed into the formatter.
Validate the correctness of the flagged issue. If correct, How can I resolve
this? If you propose a fix, implement it and please make it concise.
```
</details>
##########
superset-frontend/src/explore/components/controls/ConditionalFormattingControl/FormattingPopoverContent.tsx:
##########
@@ -361,6 +315,40 @@ export const FormattingPopoverContent = ({
setPreviousColumnType(newColumnType);
};
+ const handleAllColumnChange = (value: string) => {
+ setColumnFormating(value);
+ };
+ const numericColumns = useMemo(
+ () => allColumns.filter(col => col.dataType === GenericDataType.Numeric),
+ [allColumns],
+ );
+
+ const handleObjectChange = (value: string) => {
+ setObjectFormating(value);
+
+ if (value === ObjectFormattingEnum.CELL_BAR) {
+ const currentColumnValue = form.getFieldValue('columnFormatting');
+
+ const isCurrentColumnNumeric = numericColumns.some(
+ col => col.value === currentColumnValue,
+ );
+
+ if (!isCurrentColumnNumeric && numericColumns.length > 0) {
+ form.setFieldsValue({
+ columnFormatting: numericColumns[0]?.value || '',
+ });
Review Comment:
**Suggestion:** When switching to cell bar formatting, the code updates the
form field `columnFormatting` but does not update the `columnFormatting` React
state, which can lead to inconsistent state versus form values and stale
initial values if the form is ever reset or reinitialized. [logic error]
<details>
<summary><b>Severity Level:</b> Major ⚠️</summary>
```mdx
- ⚠️ Formatting column may appear inconsistent after object change.
- ⚠️ Cell bar formatting selection UX can confuse users.
- ⚠️ Form reset paths may exhibit stale initial selection.
```
</details>
```suggestion
const newValue = numericColumns[0]?.value || '';
form.setFieldsValue({
columnFormatting: newValue,
});
setColumnFormating(newValue);
```
<details>
<summary><b>Steps of Reproduction ✅ </b></summary>
```mdx
1. Open the file
superset-frontend/src/explore/components/controls/ConditionalFormattingControl/FormattingPopoverContent.tsx;
the UI for object formatting is rendered at lines ~421-435 where Select
onChange calls
handleObjectChange. The handler is defined at lines 326-342.
2. Prepare props for the component where: allColumns contains both numeric
and non-numeric
columns, and the current form's columnFormatting is set to a non-numeric
column. Mount the
component in a browser or test environment so the Select for "Formatting
object" is
interactable.
3. In the UI, change the "Formatting object" Select to the "Cell bar" option
(ObjectFormattingEnum.CELL_BAR). That triggers handleObjectChange
(FormattingPopoverContent.tsx:326). Because the current formatting column is
non-numeric,
the code at lines 333-340 calls form.setFieldsValue(...) to update the form's
columnFormatting field to the first numeric column, but it does not call
setColumnFormating(...) to update the local React state.
4. Observe possible inconsistencies: the AntD form-controlled Select value
will reflect
the new value (because form.setFieldsValue updates the form), but the
component's local
state columnFormatting (used as the FormItem initialValue and elsewhere)
remains stale
until the next time setColumnFormating is called (e.g., by user
interaction). This can
surface as confusing behavior after form resets or when code relies on the
state variable
rather than form.getFieldValue.
```
</details>
<details>
<summary><b>Prompt for AI Agent 🤖 </b></summary>
```mdx
This is a comment left during a code review.
**Path:**
superset-frontend/src/explore/components/controls/ConditionalFormattingControl/FormattingPopoverContent.tsx
**Line:** 337:339
**Comment:**
*Logic Error: When switching to cell bar formatting, the code updates
the form field `columnFormatting` but does not update the `columnFormatting`
React state, which can lead to inconsistent state versus form values and stale
initial values if the form is ever reset or reinitialized.
Validate the correctness of the flagged issue. If correct, How can I resolve
this? If you propose a fix, implement it and please make it concise.
```
</details>
##########
superset-frontend/packages/superset-ui-chart-controls/src/types.ts:
##########
@@ -486,12 +486,16 @@ export type ConditionalFormattingConfig = {
toAllRow?: boolean;
toTextColor?: boolean;
useGradient?: boolean;
+ columnFormatting?: string;
+ objectFormatting?: string;
Review Comment:
**Suggestion:** The `objectFormatting` field in the conditional formatting
config is typed as a generic string even though there is a dedicated
`ObjectFormattingEnum`, so TypeScript will not prevent invalid values and
downstream comparisons against the enum may silently fail at runtime. [type
error]
<details>
<summary><b>Severity Level:</b> Major ⚠️</summary>
```mdx
- ❌ Conditional formatting UI misses Cell Bar application.
- ⚠️ Unit tests may silently allow invalid config values.
- ⚠️ Developer typos create runtime mismatches.
```
</details>
```suggestion
objectFormatting?: ObjectFormattingEnum;
```
<details>
<summary><b>Steps of Reproduction ✅ </b></summary>
```mdx
1. Open the updated types file where the ConditionalFormattingConfig is
declared:
`superset-frontend/packages/superset-ui-chart-controls/src/types.ts` and
inspect the
property at line 490 (`objectFormatting?: string;`). This is the type that
callers use for
the formatting target.
2. In the test referenced by the PR (run as instructed):
`src/explore/components/controls/ConditionalFormattingControl/FormattingPopoverContent.test.tsx`
create or observe a test fixture that constructs a
ConditionalFormattingConfig object and
assigns `objectFormatting: 'INVALID_OPTION'`. TypeScript accepts this at
compile time
because the property is typed `string` (see types.ts:490).
3. Run the test suite (or render the component). The ConditionalFormatting
UI component
(`src/explore/components/controls/ConditionalFormattingControl.tsx`,
referenced from
types.ts comments) performs runtime comparisons against the enum values
(ObjectFormattingEnum.CELL_BAR etc.). Because the test supplied an
unexpected string, the
equality checks do not match the enum branch that applies cell-bar
formatting.
4. Observe the concrete symptom: the cell-bar formatting branch is not
executed (cell
bars/options do not appear or are not applied). This demonstrates that using
`string`
allows invalid values through the type system and leads to missing
conditional-formatting
behavior at runtime.
```
</details>
<details>
<summary><b>Prompt for AI Agent 🤖 </b></summary>
```mdx
This is a comment left during a code review.
**Path:** superset-frontend/packages/superset-ui-chart-controls/src/types.ts
**Line:** 490:490
**Comment:**
*Type Error: The `objectFormatting` field in the conditional formatting
config is typed as a generic string even though there is a dedicated
`ObjectFormattingEnum`, so TypeScript will not prevent invalid values and
downstream comparisons against the enum may silently fail at runtime.
Validate the correctness of the flagged issue. If correct, How can I resolve
this? If you propose a fix, implement it and please make it concise.
```
</details>
##########
superset-frontend/src/explore/components/controls/ConditionalFormattingControl/types.ts:
##########
@@ -32,6 +32,8 @@ export type ConditionalFormattingConfig = {
toAllRow?: boolean;
toTextColor?: boolean;
useGradient?: boolean;
+ columnFormatting: string;
+ objectFormatting: string;
Review Comment:
**Suggestion:** The two new formatting properties are declared as required
strings while all other config fields are optional, but existing saved
configurations and partially created rules will not include these new fields,
so any code that assumes they are always present and calls string methods on
them can hit runtime errors when they are actually undefined. Making them
optional keeps the type consistent with the rest of the config and better
reflects the real data shape during migrations and incremental editing.
[possible bug]
<details>
<summary><b>Severity Level:</b> Major ⚠️</summary>
```mdx
- ⚠️ Formatting popover tests may fail TypeScript checks.
- ❌ Loading old saved conditional formats may error.
- ⚠️ ConditionalFormattingControl UI may encounter undefined values.
```
</details>
```suggestion
columnFormatting?: string;
objectFormatting?: string;
```
<details>
<summary><b>Steps of Reproduction ✅ </b></summary>
```mdx
1. Run the unit test referenced in the PR description:
src/explore/components/controls/ConditionalFormattingControl/FormattingPopoverContent.test.tsx.
This test creates ConditionalFormattingConfig fixtures (see test file) that
do not set the
newly added fields.
2. Type-check or build the frontend (run yarn build or tsc). The type for
ConditionalFormattingConfig in
superset-frontend/src/explore/components/controls/ConditionalFormattingControl/types.ts
(lines 32-37) now requires columnFormatting and objectFormatting, which the
test fixtures
lack, producing TypeScript "property is missing" errors at the sites where
those fixtures
are declared/used.
3. Run the UI manually: open Explore -> Conditional formatting UI (component
ConditionalFormattingControl). Load a chart saved before this PR
(server-saved config
objects don't include the new fields). Code expecting strings may access
these properties
(e.g., code in the control/popover components reading .length or .split) and
observe
undefined behavior at runtime.
4. Conclusion: the new properties should be optional (columnFormatting?:
string;
objectFormatting?: string;) to match existing configs and prevent build/test
failures and
runtime undefined access.
```
</details>
<details>
<summary><b>Prompt for AI Agent 🤖 </b></summary>
```mdx
This is a comment left during a code review.
**Path:**
superset-frontend/src/explore/components/controls/ConditionalFormattingControl/types.ts
**Line:** 35:36
**Comment:**
*Possible Bug: The two new formatting properties are declared as
required strings while all other config fields are optional, but existing saved
configurations and partially created rules will not include these new fields,
so any code that assumes they are always present and calls string methods on
them can hit runtime errors when they are actually undefined. Making them
optional keeps the type consistent with the rest of the config and better
reflects the real data shape during migrations and incremental editing.
Validate the correctness of the flagged issue. If correct, How can I resolve
this? If you propose a fix, implement it and please make it concise.
```
</details>
--
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]
