Skip to content

Conversation

@pd-redis
Copy link
Collaborator

What

This PR migrates the database analysis page components from SCSS modules to styled-components, adds comprehensive Storybook stories, and resolves circular dependency issues.

Key Changes:

1. Styled-components Migration

  • Charts: Migrated BarChart and DonutChart from SCSS to styled-components with theme integration
  • Database Analysis Components: Converted TopNamespace, TopKeys, TableLoader, SummaryPerData, ExpirationGroupsView, GroupBadge, and TableTextBtn to styled-components
  • Theme Integration: Replaced CSS custom properties with theme values (theme.semantic.color.*, theme.core.space.*)

2. Storybook Stories

Added comprehensive interactive stories for:

  • TopNamespace - 11 stories covering loading, empty states, data views, extrapolation, and custom delimiters
  • TopKeys - 11 stories covering loading, various key types, TTL values, big keys, and custom delimiters
  • GroupBadge - 8 stories covering key types, command groups, compressed mode, delete functionality
  • ExpirationGroupsView - Stories for bar chart TTL visualization
  • DatabaseAnalysisPageView - Full page component stories
  • BarChart and DonutChart - Enhanced existing stories

3. Styled-components Infrastructure

  • Created global styles (globalStyles.ts) with CSS variables for Redis data types and command groups
  • Added reusable mixins in styles/mixins/styledComponents.ts:
    • truncateText - Text overflow handling
    • breakpoint - Responsive media queries
    • scrollbarStyles - Custom scrollbar styling
    • insightsOpen - Insights panel responsive states
  • Made CellText component props overridable while maintaining defaults

4. TypeScript & Testing Improvements

  • Fixed type errors in TopNamespace.spec.tsx by creating createMockedDatabaseAnalysis helper
  • Fixed type errors in TopKeysTable.spec.tsx by properly typing Key arrays
  • Updated component props with proper TypeScript interfaces
  • Renamed components for clarity: TableTopKeysTable and TopNamespacesTable

Testing

Manual Testing

  • Open a database with some content, go to Analysis tab, click on New Report button

Visual Verification

analysis-demo.mov

…rybook stories

- Migrate BarChart, DonutChart, and database-analysis components to styled-components
- Add comprehensive Storybook stories for all major components
- Integrate theme system and create reusable styled-components mixins
- Fix circular dependencies and TypeScript errors
- Remove SCSS modules and barrel exports causing issues
Comment on lines +4 to +21
/**
* Global styles for the application
* These styles are applied to the entire application using styled-components
*/
export const GlobalStyles = createGlobalStyle<{ theme: Theme }>`
:root {
// todo: replace with theme colors at some point
/* Type colors for Redis data types */
--typeHashColor: #364cff;
--typeListColor: #008556;
--typeSetColor: #9c5c2b;
--typeZSetColor: #a00a6b;
--typeStringColor: #6a1dc3;
--typeReJSONColor: #3f4b5f;
--typeStreamColor: #6a741b;
--typeGraphColor: #14708d;
--typeTimeSeriesColor: #6e6e6e;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

new patterns, affecting the whole app, should be ideally introduced in a separate PR with explanation.

Can't we use @ArtemHoruzhenko 's suggestion about extending theme with custom colors instead?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ideally these should not be custom, but I have not gotten a list of theme colors to use.

My suggestion for using css properties instead of even theme overrides is simply practical.

example:

--bg-color-neutral100: ${({ theme }) => theme.semantic.color.background.neutral100};
    // ....
background-color: ${({ theme }) => theme.semantic.color.background.neutral100};
    // vs
background-color: var(--bg-color-neutral100);

If --var is defined at root level, it is accessible everywhere and is a lot shorter to type.

In this case, the colors defined are used in most if not all "key" related components.
In case of theme changes, this can be the single place where we need to apply the changes.
If we use the approach to override the theme, we should not override it but define our theme based on redis-ui theme. Why? Because in case that redis-ui decides to change the structure from theme.semantic.color.background.neutral100 to just theme.components.page.background, it will not be just matter of changing the override, but also everywhere the old path is used.

Of course this is just an opinion, the team can decide if we want to use any sort of override at all.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pd-redis I would prefer to use theme here so it will be aligned with everything else

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For me it looks like we must extend existing theme with another semantic component (e.g. keyType.color = 'json' | 'hash' | ...)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with you @ArtemHoruzhenko on both comments. But the colors in the designs are from the update we're supposed to do next. This will for sure be migrated to the theme once we're on the same page as designers
cc. @KrumTy cc @DimoHG

Comment on lines +25 to +44
{icon ? (
<Row justify={justify} gap="m" align="center">
<ButtonIcon
buttonSide="left"
icon={icon}
iconSide={iconSide}
loading={loading}
size={size}
/>
{children}
<ButtonIcon
buttonSide="right"
icon={icon}
iconSide={iconSide}
loading={loading}
size={size}
/>
</Row>
) : (
children
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is this change needed? Can't you conditionally render just the buttons instead? Also why are both the same?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Its ugly, but allows not to have extra wrapper if you don't pass an icon.
I don't like it as well, maybe we should use different approach.
Right now I need it in order to have "real" text like look of the button

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does it make sense that both left and right icons are the same though?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The idea is (and was since this component exists) to be able to put icon on either side of the button. That is what iconSide prop does

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The change here is not related to how icons are hadled when they are present, it is about what to do when there is no icon

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

<Row justify={justify} gap="m" align="center">

@github-actions
Copy link
Contributor

Code Coverage - Frontend unit tests

St.
Category Percentage Covered / Total
🟢 Statements 82.64% 20706/25055
🟡 Branches 67.82% 8804/12982
🟡 Functions 77.47% 5608/7239
🟢 Lines 83.05% 20275/24414

Test suite run success

5280 tests passing in 689 suites.

Report generated by 🧪jest coverage report action from a9b84ea

@pd-redis pd-redis requested a review from KrumTy November 19, 2025 10:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants