Closed nathan-de-pachtere closed 3 days ago
@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.
Hi @nathan-de-pachtere, I have a few queries regarding the changes:
Constant variable naming. CAPS_SNAKE_CASE doesn't seems right. It can be short enum also IMO like Direction.Top
.
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.
@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).
@rahul-vashishtha
For the CAPS_SNAKE_CASE subject :
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.const <variable> =
but is not mutable because of the as const
. Just typescript syntax for doing that. {} 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. ;)
@rahul-vashishtha Can you reopen that merge request ? I'm currently doing some change to it for speed props and documentation mistakes
For now, I'm still using Interface but will change when we choose one option.