Background Pattern - Rebuild

[nathan-de-pachtere]

• Add new unique component with variants
• Add class-variance-authority
• Don't rely on @inspira-ui/plugins for background patterns

For now, I'm still using Interface but will change when we choose one option.

[nathan-de-pachtere]

@rahul-vashishtha Lot of stuff to discuss on this component rebuild (as example for other components). It's inspired by Shadcn-vue + some other cool stuff for clean and reusable code.

And I have an issue to display .ts files in the docs, as the CodeViewer components is locked for .vue files.

[rahul-vashishtha]

Hi @nathan-de-pachtere, I have a few queries regarding the changes:

1. Constant variable naming. CAPS_SNAKE_CASE doesn't seems right. It can be short enum also IMO like Direction.Top.

2. The reason I was using speed prop as number and then updating internally in seconds or milliseconds inside the component was making it simple for user, but now user has to provide string or use from Constant value.

Also, I'm preferring not to bind Inspira UI with any specific component library or design system. Developers should be able to use it freely with their preferred design system or component library.

Regarding Inspira UI plugins, it sets up the base for all the components at once, there are few more updates I'm planning to perform with Inspira UI.

[rahul-vashishtha]

@nathan-de-pachtere We can go with interface as discussed in https://github.com/unovue/inspira-ui/pull/23.

Regarding the speed prop we can make it number (for milliseconds or seconds).

[nathan-de-pachtere]

@rahul-vashishtha

For the CAPS_SNAKE_CASE subject :

• used to have CAPS_SNAKE_CASE syntax for shareable constant that are immutable, in order to identify them. In that example, PATTERN_BACKGROUND_DIRECTION is immutable for the developer using it.
• PATTERN_BACKGROUND at the beginning is to identify to which part of the project it's belong to. As multiple component will have their own DIRECTION constant and others. If not prefixed this can lead to wrong import when project build up.
• This make it easier to know what you import between Interface/Type, classes or constant
• It's using the normal const <variable> = but is not mutable because of the as const. Just typescript syntax for doing that.
• It's clearly identifiable inside a project
• This is quite normal in strongly typed languages
• I never use Enum in Typescript as its mess up with typing. It's way more simple, useful and convenient to have {} as const. Did use Enum in the past, but now it's a 'no thanks'.

PATTERN_BACKGROUND_DIRECTION is the immutable variable PatternBackgroundDirection is the Type/Interface corresponding to it Direction can be a Classe or an Interface/Type

If we use only Direction this become confusing as there will be 2 code elements named the same, or we need to specify something like DirectionInterface or DirectionI (this is not recommended as well)

For example, I also use EVENT_CamelCase for events in a project when I have a global Event Pub/Sub system like Mitt. The reason is the same: they are immutable, easy to identify within the project, and it's clear while coding that EVENT_OnPostBook is an event. I enforce this convention using custom ESLint rules, which specify that variables shouldn't be uppercase unless they start with ROUTE_, EVENT_, or other predefined prefixes. This is just an example and not related to any actual project. ;)

[nathan-de-pachtere]

@rahul-vashishtha Can you reopen that merge request ? I'm currently doing some change to it for speed props and documentation mistakes