Ri-7465 auto discovery layout

[pd-redis]

What

This PR refactors the Redis Cloud and Redis Cluster database discovery UI by extracting inline table column definitions
into dedicated, reusable components. These changes bring the current implementation closer to Figma designs while
improving code maintainability, testability, and consistency across the application.

Key Changes:

1. Column Definition Extraction

• For Redis Cluster, Redis Cloud Subscriptions, Redis Cloud Databases and Redis Cloud Databases Result extracted column definitions into dedicated, reusable functions.

2. Custom Hook Extraction

• Created hooks for Redis Cluster and Redis Cloud database discovery logic.

3. Storybook Stories

• Added comprehensive stories for RedisClusterDatabases (15+ variants)
• Added stories for RedisCloudDatabases with different states
• Added stories for RedisCloudSubscriptions with multipage examples
• Added stories for RedisCloudDatabasesResult with success/error states
• Created factory functions for mock data generation

4. UI/UX Improvements (Aligned with Figma Designs)

• Improved DatabaseListOptions component with better styling and stories to match design specs
• Enhanced MessageBar component with variant support and comprehensive tests
• Fixed HoverContent to not wrap non-text titles per design guidelines
• Updated ClusterConnectionForm layout to align with Figma mockups
• Improved endpoint display with consistent copy functionality matching design system
• Updated column sizing and spacing to match Figma specifications

Tech Decisions:

1. Column Component Pattern: Each column is now a factory function returning a ColumnDef
2. Shared Components: Leveraged existing CopyBtn, CopyTextContainer, and CellText components for consistency
3. Factory Pattern: Created factory functions for mock data to support comprehensive Storybook stories
4. Hook Extraction: Moved complex table logic to custom hooks, keeping page components focused on rendering

Testing

Manual Testing:

• Verified Redis Cluster database discovery flow works correctly
  • Note: To test Redis Cluster, a Redis Enterprise installation is needed. One can be found in the tests/e2e/rte/redis-enterprise folder
• Verified Redis Cloud subscription selection and database discovery
• Verified result pages display correctly with success/error states
• Tested column sorting, selection, and copy functionality
• Verified conditional column visibility (Capabilities, Options)
• Tested all Storybook stories render correctly

Automation Tests:

• Added comprehensive MessageBar component tests covering all variants and states
• Existing tests pass without modification (no breaking changes)
• Updated test data-testid attributes remain consistent

Visual Changes:

• Enhanced database options display with better spacing
• Updated message bar to support success/attention variants
• Consistent tooltip positioning and styling across all tables

Screenshots/Recordings:

Redis Cloud

Screen.Recording.2025-11-12.at.16.15.39.mov

Sentinel Cluster

Screen.Recording.2025-11-12.at.16.17.24.mov

Redis Cluster

Screen.Recording.2025-11-12.at.16.16.37.mov

[KrumTy]

re-review was requested but my original requirements were not fulfilled

[jit-ci]

❌ Jit has detected 1 important finding in this PR that you should review.
The finding is detailed as a comment.
It’s highly recommended that you fix this security issue before merge.

Until now, you ignored/fixed 2 findings.

[jit-ci]

Security control: Docker Scan

Image User Should Not Be 'Root'

Running containers with 'root' user can lead to a container escape situation. It is a best practice to run containers as non-root users, which can be done by adding a 'USER' statement to the Dockerfile.

Severity: HIGH

Learn more about this issue

---

Fix suggestion:

This fix suggestion was generated by Jit. Please note that the suggestion might not always fit every use case. It is highly recommended that you check and review it before merging.

Suggestion guidelines

• First of all, check if your container is running as a root user. In most of the cases, you can do it by running a command like this: docker run <image> whoami. If it returns root, then you should consider using a non-root user, by following one of the next steps:
  • If a non-root user already exists in your container, consider using it.
  • If not, you can create a new user by adding a USER command to the Dockerfile, with a non-root user as argument, for example: USER <non-root-user-name>.

Suggested change

	FROM redislabs/redis:8.0.2-17
	FROM redislabs/redis:8.0.2-17
	RUN addgroup --system <group>
	RUN adduser --system <user> --ingroup <group>
	USER <user>:<group>

---

Why should you fix this issue?
This Dockerfile introduces a container vulnerability. In a production environment, using insecure container configurations or outdated base images can lead to significant security risks. If an attacker exploits a vulnerability in the container, it could compromise the entire application or lead to unauthorized access.

---

Jit Bot commands and options (e.g., ignore issue)

You can trigger Jit actions by commenting on this PR review:

• #jit_ignore_fp Ignore and mark this specific single instance of finding as “False Positive”
• #jit_ignore_accept Ignore and mark this specific single instance of finding as “Accept Risk”
• #jit_ignore_type_in_file Ignore any finding of type "Image user should not be 'root'" in tests/e2e/rte/redis-enterprise/Dockerfile; future occurrences will also be ignored.
• #jit_undo_ignore Undo ignore command

[pd-redis]

re-review was requested but my original requirements were not fulfilled

I have looked at your suggeted example and I must say that although it has some merits, it is not ideal.
The *Cell components are extremely well suited for similar static column types. To implement something different, you need a different component anyways.
Passing dependencies as props is much more evident and easier to test, than to get them from context, store or whatever other hidden location.
Bulding flexible column definitions is much harder. To add some new, slightly different behavior will require to extend the features of cell component that already does a lot or just create a new one - which is what I prefer to do.
I prefer my render components to be explicit in what they require, to be testable in isolation without the need to be wrapped in context.

In my opinion both approaches have merit where applicable, and blocking a PR just because you're married to your approach is not very practical.

Finally, here is what beloved AI thinks about the different approaches:

I am sure that with different sort of question, we can get different answer, but never the less I don't see the problem here

[KrumTy]

Good that you're giving the code style guidelines a try

[pd-redis]

You going to bed does not stop you from posting nonsense :)
You don't know what gaslight means, and since you insist on having this conversation on public, lets do it.
How big a PR is, is not a problem, unless you have issues following.

I reviewed in anyway - all you did regarding my main suggestion (how to define table columns) was to lowercase the function names.

The above is factually incorrect.

Let me repeat the solution we've adapted to at least 3 tables so far. You have a static array BASE_COLUMNS, each cell is a standard react component (example) that implements the same interface. If you need to access custom data from the cell, you can use context/redux (example), that way you avoid prop drilling, generators, factories, whatever.

The solution you have adopted (not adapted) is working for your use case. Good for you. However it does not work for mine.
And mine does. So this is moot discussion.

Now lets compare it to yours, which splits table columns into multiple generator functions for some reason and then assembles the array via custom factory function (no AI used btw):

may require prop drilling to access table specific data
Ant the above is the dumbest thing you have said about the pr! It is VERY oblvious what are the dependencies of the component and the function! Which cannot be said about your hidden column dependency pattern.

It uses well established factory pattern, if it is a function or multiple function calls put together is besides the point.

Again, don't give me screenshots, give me actual benchmark code, you claim that there is some inferiority in the implementation.

Take one of the examples, implement it your way and benchmark them. Until then this is just to block the PR, and if you don't present any meaningful arguments, I will ignore your request very soon.

[KrumTy]

discard rc

discard rc