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.

}

const columns: ColumnDefinition<Key>[] = [
const columns: ColumnDef<Key>[] = [
Copy link
Collaborator

Choose a reason for hiding this comment

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

it is easy to extract columns outside the component - just need to put delimiter in a context or access it by other means

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yes, but lets leave it as is for now, the focus of this PR is visuals

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

Comment on lines +30 to +32
.tooltipAnchor {
display: inline-flex;
}
Copy link
Collaborator

Choose a reason for hiding this comment

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

was this style reverted?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Not sure what you mean by reverted, but I needed this style, because without it, the tooltip wrapped content cannot be aligned: center (or otherwise) properly.
In icon that is 20x20 px when wrapped in tooltip, effectively has height of 25 or something like that - the tooltip content container has that size, not the icon, so if it is centerd, it is actually offset by some pixels

@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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

3 participants