webui: fix preset sorting order and ESLint issues

[Mahi1801]

Hi @0xgouda, thanks for the feedback!

I’ve moved the changes to a dedicated branch as suggested and updated the preset
sorting order to:

minimal
basic
standard
exhaustive
full
aiven
azure
gce
rds
pgbouncer
pgpool
unprivileged
recommendations
prometheus-async
exhaustive_no_python
debug

The same ordering is now used as the default in the Presets tab as well.
All checks are passing locally.

Please let me know if anything else is needed 🙏

[0xgouda]

Thanks! The preset ordering in the sources form works as expected, but let's make this the default ordering in the presets tab too.

As you can see, they are not ordered by default:

[pashagolub]

Thanks for your input!

I don't think name list can cover all the situations. What if one wants to rename the preset? What if one adds their own preset and want to put it to the top? What if one is not happy with some preset and want to move it down? What if we delete some preset one day, e.g. unprivileged?

Should preset have some order float property that can be controlled via UI, so users may apply their own preferences?

[Mahi1801]

Thanks for the thoughtful feedback!

I agree that a static name-based ordering cannot cover all future scenarios
like renaming presets, user-defined presets, or custom prioritization.
A configurable ordering (e.g. an explicit order/weight field controlled via UI)
would definitely be a more flexible long-term solution.

For this PR, I intentionally kept the scope limited to:

• fixing the current inconsistent ordering
• matching the expected default order across the source form and presets tab

This aligns with the existing backend data as it is today.
I’d be happy to explore or help with a follow-up improvement
if the project decides to support user-controlled preset ordering.

Please let me know how you’d like to proceed.

[0xgouda]

please take a look at #1086 (comment)

[Mahi1801]

Okay i got it. I will work on that.

[Mahi1801]

Thanks for the clarification!

I've now applied the same predefined preset ordering as the default ordering
in the Presets grid as well. Presets not present in the predefined list are
placed after them.

Please let me know if you'd like this to be configurable in the future.

[0xgouda]

I've now applied the same predefined preset ordering as the default ordering in the Presets grid as well.

You haven't pushed any updates; it's still the same.

[Mahi1801]

Hi @0xgouda, thanks for pointing that out -my apologies.
I’ve now pushed the update that applies the same predefined preset ordering to the Presets grid.
Please let me know if it looks correct now.

[coveralls]

Pull Request Test Coverage Report for Build 20452701529

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 73.807%

---

Totals
Change from base Build 20326776768:	0.0%
Covered Lines:	3804
Relevant Lines:	5154

---

💛 - Coveralls

[Copilot]

Pull request overview

This PR addresses preset sorting order inconsistencies and fixes ESLint issues in the webui. The changes implement a standardized preset ordering across the application, prioritizing common presets (minimal, basic, standard, etc.) followed by cloud provider-specific presets, then special-purpose presets.

Key changes:

• Implemented custom sorting for presets in both the Presets grid and the Source form metrics step
• Refactored code to fix ESLint issues, improving type safety and code quality
• Added proper type definitions for preset options with descriptions

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 6 comments.

File	Description
internal/webui/src/pages/PresetsPage/components/PresetsGrid/PresetsGrid.tsx	Adds PRESET_ORDER constant and implements custom sorting logic for preset display in the grid
internal/webui/src/containers/SourceFormDialog/components/SourceForm/components/SourceFormStepMetrics.tsx	Adds PRESET_PRIORITY constant, implements sorting for preset dropdown options, and improves type definitions

[Copilot]

The PresetMeta type is defined inside the component function. Type definitions should be moved outside the component scope to improve code organization and prevent recreation on each render.

[Copilot]

The constant names are inconsistent between files. This file uses PRESET_ORDER while SourceFormStepMetrics.tsx uses PRESET_PRIORITY for the same purpose. Consider using a consistent name across both files, such as PRESET_ORDER or extracting this to a shared constant to avoid duplication.

[Copilot]

This code duplicates the preset ordering list defined in PresetsGrid.tsx. The same ordering array appears in both files with different names (PRESET_PRIORITY here vs PRESET_ORDER there). Consider extracting this to a shared constant file to maintain a single source of truth and prevent inconsistencies.

[0xgouda]

LGTM, but please check the reviews from copilot.

[Mahi1801]

Thanks for the review!

I’ve addressed the Copilot feedback by extracting the preset ordering into a shared constant and reusing it in both the Presets grid and Source form, removing duplication and improving consistency.

Formatting issues were also cleaned up.
Please let me know if everything looks good now

[0xgouda]

Why add a new constants/ folder and not use the already existing consts/ folder?
(I am not an experienced front-end dev, correct me if I am missing smth)

[pashagolub]

Front-end should not rely on the predefined preset list. We make assumption that no information is available at design-time. All information is available only through REST API