CONSOLE-5055: AsyncComponent type improvements

[logonoff]

• Updated AsyncComponent to be a functional component that uses React.lazy
• Retry duration is now capped to 30s instead of exponentially increasing (previously we would backoff for over a month)
  • To be honest we probably don't need to have any retry behaivour here. But I kept it incase just in case
• Components consuming AsyncComponent now have proper type checking based on the props of the loader

Summary by CodeRabbit

• Bug Fixes

  • Improved reliability of component loading with automatic retry and exponential backoff for better error recovery.

• New Features

  • Added localization support for edit mode in YAML creation workflows.

• Tests

  • Enhanced test coverage for async component error handling and retry behavior with backoff timing verification.

[openshift-ci-robot]

@logonoff: This pull request references CONSOLE-5055 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set.

Details

In response to this:

• Updated AsyncComponent to be a functional component that uses React.lazy
• Retry duration is now capped to 30s instead of exponentially increasing (previously we would backoff for over a month)
• Component consuming AsyncComponent now have proper type checking based on the props of the loader

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: logonoff

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• frontend/OWNERS [logonoff]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[openshift-ci-robot]

@logonoff: This pull request references CONSOLE-5055 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set.

Details

In response to this:

• Updated AsyncComponent to be a functional component that uses React.lazy
• Retry duration is now capped to 30s instead of exponentially increasing (previously we would backoff for over a month)
• To be honest we probably don't need to have any retry behaivour here. But I kept it incase just in case
• Component consuming AsyncComponent now have proper type checking based on the props of the loader

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci-robot]

@logonoff: This pull request references CONSOLE-5055 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set.

Details

In response to this:

• Updated AsyncComponent to be a functional component that uses React.lazy
• Retry duration is now capped to 30s instead of exponentially increasing (previously we would backoff for over a month)
• To be honest we probably don't need to have any retry behaivour here. But I kept it incase just in case
• Components consuming AsyncComponent now have proper type checking based on the props of the loader

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci-robot]

@logonoff: This pull request references CONSOLE-5055 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set.

Details

In response to this:

• Updated AsyncComponent to be a functional component that uses React.lazy
• Retry duration is now capped to 30s instead of exponentially increasing (previously we would backoff for over a month)
• To be honest we probably don't need to have any retry behaivour here. But I kept it incase just in case
• Components consuming AsyncComponent now have proper type checking based on the props of the loader

Summary by CodeRabbit

• Bug Fixes

• Improved reliability of component loading with automatic retry and exponential backoff for better error recovery.

• New Features

• Added localization support for edit mode in YAML creation workflows.

• Tests

• Enhanced test coverage for async component error handling and retry behavior with backoff timing verification.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[logonoff]

/label px-approved
/label docs-approved

[coderabbitai]

📝 Walkthrough

Walkthrough

This pull request refactors the AsyncComponent lazy-loading system from class-based to functional component using hooks and Suspense, introducing exponential backoff retry logic with a configurable retry cap. Type signatures across lazy loaders are updated to expect ComponentType instead of raw props, with corresponding type adjustments in dependent components. Error boundaries are selectively removed from certain lazy-loaded resources. Props are refined to make create and clearFileUpload optional in EditYAMLProps. Test coverage expands for async error and retry scenarios. Data-test attributes are added to buttons for improved testing visibility. Minor type imports are consolidated and React type references are simplified throughout.

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title directly reflects the main change: converting AsyncComponent to use better type checking and functional approach with retry improvements.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

frontend/public/components/import-yaml.tsx (1)

16-25: ⚠️ Potential issue | 🟡 Minor

Fix type safety: initialResource={undefined} violates the required prop definition.

ResourceYAMLEditorProps defines initialResource: K8sResourceKind as required (not optional). Passing undefined conflicts with this contract. In create-yaml.tsx, the pattern correctly uses an empty object {} instead:

const initialResource = useMemo(() => {
  if (!kindObj) {
    return {};  // Always pass an object
  }
  // ...
}, []);

Either mark initialResource as optional in ResourceYAMLEditorProps if undefined should be supported, or pass {} here to align with the type definition and existing usage patterns.

🧹 Nitpick comments (3)

frontend/packages/console-shared/src/components/formik-fields/field-types.ts (1)

166-173: Minor inconsistency between RadioButtonFieldProps and RadioGroupFieldProps value types.

RadioButtonFieldProps.value accepts string | number (line 167), while RadioGroupOption.value is constrained to string only (line 185). If a RadioButtonField is used standalone with a numeric value but the same field is later wrapped in a RadioGroupField, the types won't align.

Consider whether both should consistently use string or string | number. If numeric values are genuinely needed for radio buttons, RadioGroupOption.value should also support number.

frontend/public/components/utils/async.tsx (1)

18-22: sameLoader comparison is fragile — document limitations and consider alternatives.

Comparing functions via name and toString() can produce false positives (different inline functions with identical bodies) or false negatives (minified code where function bodies differ). The current approach handles inline loaders better than referential equality alone, but:

1. Arrow functions typically have empty name properties
2. Minifiers may alter function bodies unpredictably

The comment acknowledges this ("not the best solution"), but consider adding a more robust equality check or documenting that consumers should define loaders outside render cycles when possible.

frontend/public/components/utils/__tests__/async.spec.tsx (1)

98-109: Minor: Missing await after advanceTimersByTime may cause timing issues.

For consistency with other tests in this file, consider wrapping the timer advancement in act or awaiting promise resolution:

await act(async () => {
  jest.advanceTimersByTime(1000);
});

This ensures all pending promise resolutions are flushed before the assertion on line 107.

♻️ Suggested improvement

   await waitFor(() => expect(loader).toHaveBeenCalledTimes(1));

-  jest.advanceTimersByTime(1000);
+  await act(async () => {
+    jest.advanceTimersByTime(1000);
+  });

   expect(loader).toHaveBeenCalledTimes(1);

[openshift-ci]

@logonoff: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/e2e-gcp-console	9cf3f71	link	true	/test e2e-gcp-console

Full PR test history. Your PR dashboard.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.