Open jd-solanki opened 7 months ago
This is a good proposal @jd-solanki ! π I couldn't agree more with the 3 problems you stated above.
Although shadcn-vue
provides a good low level way of constructing a component, however I find it difficult for beginner dev or anyone to "just use" the component with props/event/slot ready.
I had a similar idea in mind to create a UI library that handle this exact problem, which is to provide high level components, and at the same time low level (Radix Vue) component with a consistent theming capabilities.
And with your suggestion of framework guidelines with consistent naming convention, I believe that would reduce the fear of updating major version. π
I do however foresee some challenges regarding implementing a framework guidelines that would be adopt by every framework, but we can definitely start somewhere!
Hi, Thanks for the write, I agree with most of the things you mentioned here but one "Mix low-level and high-level API/props"
https://mui.com/material-ui/react-alert/
Component Per Node
is the way β
https://github.com/mui/material-ui/discussions/41085
<script setup lang="ts">
import { Alert, AlertDescription, AlertTitle } from '@/components/ui/alert'
</script>
<template>
<!-- how can I change font-size of description without touching the actual component -->
<Alert title="Heads up!" description="..." />
<!-- this will cause confusion -->
<Alert title="Heads up!" description="...">
<AlertTitle>Heads up!</AlertTitle>
<AlertDescription>...</AlertDescription>
</Alert>
</template>
<script setup lang="ts">
import { Alert, AlertDescription, AlertTitle } from '@/components/ui/alert'
</script>
<template>
<Alert :classes="{ root: { class: 'text-red-900' }, title: { class: 'text-red-800' } }">
<template #title>
Heads up!
</template>
<template #description>
...
</template>
<template #icon>...</template>
</Alert>
<Alert>
<template #icon>...</template>
<AlertTitle class="text-red-800">Heads up!</AlertTitle>
<AlertDescription class="bg-green-600">...</AlertDescription>
</Alert>
</template>
We don't need 10 frameworks that does the same thing differently but 1 framework that does things accurately
I can relate to that quote.
Also every UI framework has its own way of doing the code
Although defineProps
doesn't support node_modules external extended complex types and I'm not fan of defineEmits
, for UI frameworks/libs it's better to stick to the Vue script setup
syntax cause it is more friendly syntax for beginner dev
Today, I had another thought π
I'll address these issues in framework guidelines/solutions
As the framework evolve, Framework author might rename prop, slot or component itself due to name normalization (like initially author introduce data
prop for table rows but later they decide rows
will be much more better name and rename the prop, Woah you have broken code π¬). There might be case where even component can be renamed in cases where component name is confusing, Sidebar
=> Offcanvas
/SlideOver
.
There can also be case where prop's value get transformed. Like for list item we can have icon="i-mdi-home"
initially but later we get option for configuring size as well :icon="{ name: 'i-mdi-home', size: 24 }"
Readers of this issue might be interested in this new repo, Check README.
@jd-solanki I'd recommend putting a node at the top of the official docs and GitHub repo to tell people about the state of the ui framework, so they don't start a brand new project with it.
Every upgrade to the current front-end project, be it a UI library or tool chain, is a disaster
Hi ππ»
I have something to share and I guess you are related to this thing as well.
I'm JD, Author of Vue UI framework Anu. You can read why I created Anu here. After Nuxt UI get released (it was nice lib and can fulfill what I was trying to do with Anu) and due to full time job burden I wasn't able to work on Anu as expected at the start.
I'm writing this because I recently realized few stuff I written below and anu reached the 970+ stars which I thought it won't after taking a break from it.
The Problems
After doing some wild work I found still Vue UI frameworks are not satisfying to me. Every UI framework has its pros and cons. For example,
UI frameworks are not stable with their API because we don't have any guidelines on how we should name our props and what slots we should provide as a framework. This makes framework to introduce new API changes as they evolve and author's mind/vision changes. E.g. Vuetify calls alert detail prop "text" where nuxt UI call it "description" etc. Vuetify made data-table slot name changes recently that broke our existing app and had to rename slots everywhere.
(it might look similar to 2nd point) Years passes and framework changes but project stays the same. After project get finished and you wish to upgrade deps to latest after a year or two, framework that project relies on changes few stuff making framework not future proof and we have to carefully upgrade to latest version using release notes.
The Solutions
AlertTitle
&AlertDescription
. This way, user will have full flexibility with style & structure.is
,should
, etc.The Conclusion
Edit: