Fe/feature/ri 7231 replace eui unify components style

[pd-redis]

Rearrange and Rename Base Components (RI-7231)

Summary

This PR reorganizes and renames custom components in the base directory to improve consistency and maintainability. The implementation standardizes naming conventions and export patterns across the codebase.

Changes

• Renamed components with consistent 'Ri' prefix (e.g., RiText, RiPopover, RiTooltip)
• Reorganized directory structure for better component categorization
• Updated exports from base components (layout, text, tooltip, shared, popover, link)
• Added GlobalStyle theme component for consistent theming and CSS variables
• Standardized styling approach using styled-components
• Updated component imports across the application to use the new structure
• Fixed tests to accommodate the renamed components

Why

This change improves code organization and maintainability by:

• Establishing consistent naming conventions for custom components
• Creating a more intuitive directory structure
• Centralizing theme variables through GlobalStyle
• Making component imports more consistent throughout the application

Testing

• Updated and fixed affected tests to work with the renamed components
• Verified that all components render correctly with the new structure

[github-actions]

Code Coverage - Frontend unit tests

St.❔	Category	Percentage	Covered / Total
🟢	Statements	81.77%	19702/24094
🟡	Branches	67.23%	8541/12705
🟡	Functions	75.55%	5222/6912
🟢	Lines	82.2%	19287/23464

Test suite run success

5089 tests passing in 666 suites.

Report generated by 🧪jest coverage report action from 9e2833e

[dantovska]

Nice! I think that in a separate effort we can remove all these "--size-xxs" variables and just replace the in the components we use theme with the theme ones. Components are not that much I think (list, horizontal rule, horizontal spacer, loading content, spacer and few more occurrences), and since you've mapped the values here it would be easy to just replace.

[pd-redis]

Well, purely for brevity using var(--size-s) is far shorter to type than ${({ theme }) => theme.core.space.space025} so I am not sure which one to leave in.

This is all open for discussion.

[dantovska]

I see this uiBase/index is used here and few more places. Is there a reason why not just use uiBase/display instead?

[pd-redis]

No reason, just that EVERYTHING is exported in index and this is one thing that we should decide on

[dantovska]

I know this is draft and not ready for merge, but few small things I noticed breaking:

[dantovska]

and not to forget to remove this 😄

[pawelangelow]

Uh, nice! ❤️

[pawelangelow]

Should we keep the props with the same name convention as components? A.k.a. RiCallOutProps?

[pd-redis]

It is probably not a bad idea!

[valkirilov]

+1

[pawelangelow]

Do we need something that resets all the browser defaults for margins, paddings, etc.. Something like https://www.npmjs.com/package/reset-css

[pd-redis]

I think redis ui styles have something like that -

RedisInsight/redisinsight/ui/src/contexts/themeContext.tsx

Line 8 in 75b6799

import '@redis-ui/styles/normalized-styles.css'

[pd-redis]

But never actually looked at the css, so ti can be something entirely different

[pawelangelow]

I'm just brainstorming here, but what if we introduce https://www.npmjs.com/package/styled-system ?

What is the problem that bugs me: We'll introduce (and we already did) a lot of components with small styling fixes, causing a lot of boilerplate:

const RiRow = ... // this is OK

// This is necessary because we can't use <RiRow pt="18px" />
const SummaryContainer = styled(RiRow)`
  padding-top: 18px;
`

// Our end goal would be to remove the hardcoded pixels
<RiRow pt="small" /> or <RiRow pt={3} />

So what do you think?

Ofc, this is dead project, so as styled-components, but I guess it will help us if we migrate to something similar to tailwindcss in the future.

[pd-redis]

The issue I have with this is where we stop with the props.
Do we do margins, font styles, colors etc too?
There will always be edge cases. I would love for us to have a lego style design system, where you have just predefined components and props and only ever use that ( i think this is @ArtemHoruzhenko's dream)
But the design and dev effort required makes me think it is not going to happen.

But I am very much open to suggestions. Abstracting the components the way we did means, that changing them in one place will be reflected everywhere so that is already a small win

[KrumTy]

so is this barrel file going to be used for accessing the base components?

[pd-redis]

It is possible to access them all from here, unfortunatelly it has to be like from "@uiBase/index" and honestly I still like it more like import {RiRow, RiTable} from "@uiBase/layout" it makes it grouped more contextual.
BUT - if most of the team prefers base barrel file, then we'll use it

[KrumTy]

barrel or no barrel imports; mix is a bit confusing imo

[pd-redis]

All imports here are barrel imports, the only confising thing for me is why inputs are not part of the forms subtree, but the reallity is that I don't care that much where are things stored

[KrumTy]

default export + a single barrel file that does export { default as RiImage } from ... could resolve the suggested auto import issue

[pd-redis]

Or just export const ...
why introduce extra files that don't do anything meaningful? Single file per single export ....

[KrumTy]

looks like you need to run format on the branch

[pd-redis]

format runs on safe, but will do it again

[KrumTy]

can this have a type?

[pd-redis]

I am not sure, I don't think I have implemented this one

[KrumTy]

see my comment in RiDestructiveButton.tsx

[pd-redis]

Again, a design system is the one that has defined looks for primary, secondary, success, failure, danger, info states and typing RiPri will give you this button instead a button where you have to then add variant, then select the variant.
This is both more semantic and more ergonomic and there are 3-4 button variants, I don't think you will sturggle that much remembering them.
And finally, there is export for the BaseButton and if you hate that much semantic buttons feel free to use that one.

[KrumTy]

what is the reason behind these button wrappers? Is it to prevent the consumer from passing variant prop?
If so, it might be better to have a single RiButton wrapper on our end with allowed variants and their implementations

[pd-redis]

Nope, it is to avoid variants.
To me this is more semantic than <RIButton variant="danger"

[valkirilov]

Follow up on the following suggestion https://github.com/redis/RedisInsight/pull/4841/files#r2292865447

Looking at this example, here we don't alter the base interface in any way, but since we're implementing RiComponents as a middle layer between RedisInsight and the outer world, does it make sense to define our own interfaces for each component we wrap?

export interface RiLinkProps extends LinkProps {}

export const RiLink = ({ color, ...props }: RiLinkProps) => (

This way, our codebase will be bound to RiLinkProps and in case we need to switch the components library (once again), we'll do it in a single place (in theory).

Yes, it will look a bit meaningless, but I'm thinking out loud.

[valkirilov]

Note: I see we prefer using mostly string literal union types (size: "S" | "M" | "L"), and I see it to be inconsistent across the codebase and the different components.

Here, in this component, the size is with a capital "S". In other components, we rely on lowercase strings (without a union type). In other components, we do lowercase everything and then apply some custom handling to transform the size into rem/px.

And while it's not a big deal, I feel it will look way more consistent if we use enums. Yes, it's my own personal preference, maybe, but we'll no longer care whether it's a capital or lowercase "S", and even if it's type checked or we entered something invalid. We simply put Size.M and that's all.

PS: This is not related in any way to the changes introduced in this pull request, it's a general note.

[pd-redis]

the inconsistency in casing is because EUI uses lowercase, redis-ui upper case - hence the mix
And with or without enums, you will have to transofrm the logic to px, em or whatever - if you want to use theme values

[valkirilov]

nit: I've already mentioned this in other comment, but this is a great example in which using enum will make it simpler.

And yes, it's a subjective statement, I'm aware of that "more readable" is not a strong argument 😀

export enum Direction {
  Asc = 'asc',
  Desc = 'desc'
}

[valkirilov]

Tremendous effort, nice job! I really like how things are getting more organized now!

Looking at this changeset, I think it could be helpful if we wrote down some of these internal conventions so we can follow them consistently in the future. Maybe something simple like an inline README in markdown that acts as a mini style guide.

It doesn’t need to be complex, just a quick reference with things like:

• prefixing components with RiComponent
• how to structure and export files
• how to handle interfaces
• and maybe generic patterns we want to follow

That way, it's easy to get started, or to check later on how we prefer to do things.

Additionally, I know we've raised this a few times, but I think it would really help to have a place where we can see all the components we have and how to use them. Having an internal Storybook might be too much effort to maintain (though it would be a great addition), but even just bringing back the playground you prepared would be a solid starting point.

This is, of course, an additional task, complementary to this refactoring. I'm just mentioning it as a reminder so we can decide which path we want to follow and plan accordingly.