v3

Question

v3

benjamincanac opened this issue 9 months ago · 168 comments

Answer 1 · 2024-01-31T22:09:30.000Z

I would like to help, if I'm able to. Is there going to be a dedicated branch or will it be done in the dev one?

Answer 2 · 2024-02-01T10:03:09.000Z

Once we start this, there will be indeed a new branch with auto-release so we can try it out and especially keep working on the v2 as it might take some time. I'll create new issues once this gets started with the remaining things to do 😊

Answer 3 · 2024-02-09T04:59:47.000Z

Hi @benjamincanac

I have few design ideas if you are open to this I would like to share it for the future of Nuxt UI 3. Should we discuss this in this issue or it'll be better to discuss design ideas in seperate discussion thread?

Answer 4 · 2024-03-04T15:05:03.000Z

@jd-solanki You can share them here!

Answer 5 · 2024-03-05T20:56:39.000Z

Since it is supposed to be a refactoring to all components, could we give the possibility of compatibility with unocss?

Answer 6 · 2024-03-06T09:27:48.000Z

@sawa-ko It will be made with Tailwind v4. To what end would you make it compatible with Uno?

Answer 7 · 2024-03-06T15:07:26.000Z

I've started working on this in a private repository of mine, I'll open-source it once I'm satisfied with the base so you guys can check it out 😊.

A lot has changed since @nuxt/ui was made open-source (May 2023), so the plan here is to rewrite every component from scratch alongside their config. For example, at the beginning the config was split in many keys for the same div to give more flexibility, but since then we introduced tailwind-merge which now allows us to group those keys together.

I'll post regular updates on this issue.

Answer 8 · 2024-03-08T15:57:39.000Z

Please tell me how long it will take for this upgrade to be available.
Very much looking forward to this upgrade

Answer 9 · 2024-03-08T16:05:24.000Z

I have no idea how long it will take and it's not entirely up to us, I hope to release it at the same time as the official release of Tailwind v4.

Answer 10 · 2024-03-13T06:48:51.000Z

That's awesome. The new version of nuxt-ui uses exactly the tech stack I expected.

I tried to build my own UI library using radix-ui and tailwind-variants, but I immediately found that even with radix-ui, it is not easy to build a full UI library.

But I got an idea with an API that works with any design language. If you are interested, here is my demo repository:
https://github.com/vincajs/vinca-ui

Answer 11 · 2024-03-13T09:45:53.000Z

@robin-dongbin It's already in the making. There are already 13 components done, 36 more to go 😅

Answer 12 · 2024-03-13T09:54:01.000Z

Since the component library is based on radix-ui without styles, I thought it would be nice to provide an api that is abstracted from various design systems, so you can switch styles from one system to another at any time.

If people want to implement another design system, they can just customize it, share files, or even contribute to a repository.

Taking things a step further, it is possible to switch between different design systems at runtime.

Of course, I'm just offering an idea, and if you think it's too late, that's fine

Answer 13 · 2024-03-13T10:29:15.000Z

This is actually already what we're doing with the App Config. You can customize the classes for every part of every component.

Answer 14 · 2024-03-13T19:32:47.000Z

Thanks for the work!
i’m impatient to try this!

Just one question :

The biggest change is the switch to tailwind-variants, this will cause lots of breaking changes if you've used the ui prop or app.config.ts to override the config.

app.config.ts is deprecated and it will not port in v3? Or it’s something else?

Answer 15 · 2024-03-13T20:25:29.000Z

No we keep the app.config.ts, what I meant is since we now use tailwind-variants the config itself changes.

For example the Kbd component, its config looked like this:

export default {
  base: 'inline-flex items-center justify-center text-gray-900 dark:text-white',
  padding: 'px-1',
  size: {
    xs: 'h-4 min-w-[16px] text-[10px]',
    sm: 'h-5 min-w-[20px] text-[11px]',
    md: 'h-6 min-w-[24px] text-[12px]'
  },
  rounded: 'rounded',
  font: 'font-medium font-sans',
  background: 'bg-gray-100 dark:bg-gray-800',
  ring: 'ring-1 ring-gray-300 dark:ring-gray-700 ring-inset',
  default: {
    size: 'sm'
  }
}

Here is the new version:

export default {
  base: 'inline-flex items-center justify-center text-gray-900 dark:text-white px-1 rounded font-medium font-sans bg-gray-50 dark:bg-gray-800 ring ring-gray-300 dark:ring-gray-700 ring-inset',
  variants: {
    size: {
      xs: 'h-4 min-w-[16px] text-[10px]',
      sm: 'h-5 min-w-[20px] text-[11px]',
      md: 'h-6 min-w-[24px] text-[12px]'
    }
  },
  defaultVariants: {
    size: 'sm'
  }
}

This is a breaking change if you've overridden its config in your app.config.ts or through the ui prop. I'm thinking of a CLI or something that would help people migrate from v2 to v3 without too much trouble but it might not be easy to achieve. Everything is fully typed so this will give some indications at least.

Answer 16 · 2024-03-13T20:49:29.000Z

Ok !

Effectively, it's a breaking change but it seam ok for the future to have a better granularity with the variants.

Thanks for the explanation and the example 🙏🏻

Answer 17 · 2024-03-14T11:59:24.000Z

Here are some thoughts on the new version:

VerticalNavigation / HorizontalNavigation should be NavigationMenu with an orientation prop
Notification should rename to 'Toast', now we have Notification component and 'useToast' function, that is confused. and for new version I hope we support runtime placement.
Table should be a simple wrapper of primitive table no more features. (Building a complete data table is very complex)
As an alternative provide a DataTable component for more complex usage. Recommended use https://github.com/TanStack/table.
InputMenu rename to Autocomplete
SelectMenu rename to Combobox . In fact, I recommend the same naming for everything as radix, which makes more sense.

Answer 18 · 2024-03-14T12:04:09.000Z

This is actually already what we're doing with the App Config. You can customize(自定义) the classes for every part of every component.

I think the API I envision is better in this regard.
Because you can provide multiple design system presets in the repository for users to choose from, switching styles is easy.
For now, of course, you can just provide one preset, nuxt style
But it does reserve an easier way to extend it to implement more design systems.like Material Design, Ant Design and so on

Answer 19 · 2024-03-14T12:13:43.000Z

I agree with everything @robin-dongbin said, except for the Table I am not sure about this one.

Notification should rename to 'Toast', now we have Notification component and 'useToast' function, that is confused. and for new version I hope we support runtime placement.

Otherwise useToast() could be named useNotification() instead. I mean why is it named toast in the first place? I am not a native english speaker but I couldnt find another translation for toast than the bread (toast is not actual bread but you know what I mean).

Answer 20 · 2024-03-14T13:49:02.000Z

@MickL Toast is widely used in UI/UX for a quick message that shows up and then disappears, just like how toast pops out of a toaster when it's ready.

In Radix the component name is Toast https://www.radix-vue.com/components/toast.html

Answer 21 · 2024-03-14T13:53:52.000Z

Hello,

I'm really sorry but decision to use radix vue is the worst thing happening to this library. It will be a pain in the future for sure.

I don't like how tailwind team abandoned silently headless-ui but at least it's being supported and proven to work without much issues.

You shouldn't be relaying on the library that has over 33 open issues and the author doesn't even know how to fix some issues.

Just my 2 cents.

Answer 22 · 2024-03-14T13:58:07.000Z

@divine I'm sorry but I completely disagree with you, @zernonia has been doing an amazing job on Radix Vue with weekly releases https://github.com/radix-vue/radix-vue/releases, 33 issues is nothing for a UI library.

Answer 23 · 2024-03-14T14:02:22.000Z

@robin-dongbin Thanks for the suggestions! Regarding the NavigationMenu component replacing VerticalNavigation and HorizontalNavigation, do you think it should use https://www.radix-vue.com/components/navigation-menu.html underneath?

As for the Table component, as mentioned in #653 I'll try @tanstack/vue-table.

What is your suggestion for the preset system?

I'm not sure about the InputMenu / SelectMenu rename though as the Combobox is a primitive that will be used in multiple components like CommandPalette much like the Dialog being used in Modal and Slideover.

Answer 24 · 2024-03-14T14:10:14.000Z

@divine I'd argue that Nuxt UI adopting Radix Vue will make Radix Vue even better and in turn Nuxt UI, benefitting both. Also, most issues are feature requests and not bugs (7 out of 33)

Answer 25 · 2024-03-14T14:17:12.000Z

@messenjer thanks for clarifying! I would still propose to rename useToast() to useNotification() as it is way more clear than the image of a jumping toast.

P.S. I am very excited for v3 :)

Answer 26 · 2024-03-14T14:23:27.000Z

Also my view on the naming of "notifications". There is also the browser's notification for desktop/mobile notifications.
Some could argue that this would be confusing as well.
VueUse named it useWebNotification so the imports do not conflict but still...

Answer 27 · 2024-03-14T14:25:08.000Z

I think I will rename it to Toast to match Radix Vue component as suggested by @robin-dongbin and keep useToast(). This prevents any breaking change as you don't have to instantiate this component yourself.

Answer 28 · 2024-03-14T14:31:36.000Z

Also my view on the naming of "notifications". There is also the browser's notification for desktop/mobile notifications. Some could argue that this would be confusing as well. VueUse named it useWebNotification so the imports do not conflict but still...

It is not named browser toasts tho, as well as notifications on the desktop or smartphone are not named toast. They are all notifications and toast is confusing imo :)

Answer 29 · 2024-03-14T15:11:34.000Z

@benjamincanac Yes, I mean to use https://www.radix-vue.com/components/navigation-menu.html under the hood

In fact, I think if radix provides relevant components, I think we should use the components provided by radix as much as possible to obtain better accessibility and reduce the maintenance burden.

On the basis of ensuring the implementation of all the components provided by radix, we should build some basic components that radix does not provide, such as Button, Input etc., as well as combined components based on the combination of basic components and radix components, such as Drawer

After that, I don't know if radix plans to provide more advanced components. Like Datatable,Uploader, After all, they just provided the Calendar,In my opinion, this is an advanced component. All the advanced components I think mean complexity. It takes a lot of time to build such components. If radix does not plan to provide them, maybe we can choose mature open source third-party headless components. Such as tanstack/vue-table.

About the preset system, That's what I said above. I tried to make a demo myself. https://github.com/vincajs/vinca-ui, just has a few base component, But it can already explain the api to you that I imagined. If you are interested, just take 2 minutes to check the repository.

Answer 30 · 2024-03-15T05:28:58.000Z

@jd-solanki You can share them here!

Thanks, I'll write everything I have in mind for Anu v1 and as Nuxt UI 3 is going to use Radix I don't want to write another lib that does the same thing. Below list will also have my own thoughts & opinions so feel free to discuss or skip them.

Along with components like Alert that has props like icon, title, description if we provide low level components like AlertTitle, AlertDescription as well that will cover all the cases like we might want alert with some weird or special structure in other parts of site like landing pages. You can even consider collapsible component which can be used in admin side and also completly differently on landing pages for FAQ.
Supporting above point, Providing component locally like shadcn will make users of the lib adopt the lib. Here's why: We built admin templates and we're now going for RadixVue but we decided to go fo Shadcn for now instead of nuxt UI because in worst case scenario if the bug or issue come up we can fix that locally and make a new release without relying on third party lib. Another case can be, We may want some change that lib author might not prefer adding to their own lib so in this case having component locally can also benefit both user of the lib and lib author. I strongly support this point and would love to see local components with Nuxt UI 3.
Naming & Component API should be carefully picked considering future CSS & HTML updates to avoid introducing breaking changes after v3 release. For example, we're discussing about toast & notification. Another example is chip, If you ask me it's better named as badge instead of chip because chip is generally like this (Chip & badge are two different things and can co-exist).
In case of breaking changes we can use soft deprecation to avoid more work for users.

You can also read my thoughts here.

Unfortunately, I don’t have enough time these days to fully contribute to the v3 project. However, if you are willing to provide components locally, I would be more than happy to help in any way I can.

Answer 31 · 2024-03-18T17:10:12.000Z

What do you guys think of removing the USelect in favor of USelectMenu (would be renamed to USelect)? Is there some cases where we specifically need native <select>?

Answer 32 · 2024-03-18T18:17:36.000Z

Questions I have on this:

Is the USelectMenu just as accessible as the native <select>?
What about mobile? I like to have select menu's native behaviour on mobile if I don't need any styling. Do we lose this?
Do you think having something like a prop (<USelect native>) would be a good idea? Does it make sense?

Mostly the mobile behaviour is what concerns me a little.

Answer 33 · 2024-03-18T18:21:47.000Z

If we use the Select from Radix Vue, it will be accessible yes: https://www.radix-vue.com/components/select. It renders an hidden <select> underneath. You can take a look on mobile how it behaves.

Not sure how we can handle the search with this though.

Answer 34 · 2024-03-18T19:53:49.000Z

It would be great if Modal will have some variants like small, medium, large, fullscreen. Currently it is very cumberstone to change the width of it.

Answer 35 · 2024-03-20T14:23:45.000Z

@MickL You can actually change the width quite easily by using :ui="{ width: 'sm:max-w-xl' }", in v3 you will even be able to do this directly with class.

Answer 36 · 2024-03-20T14:28:07.000Z

I know but it would be nice to have some options like small, medium, large, fullscreen. It is the same as you would say we can change color of a button easily but it is nice to have color and variant props.

Answer 37 · 2024-03-22T02:23:51.000Z

wow! vue compatibility, thanks for the work!

Answer 38 · 2024-03-22T10:03:23.000Z

How about rename leading and trailing to prefix and suffix. This is how most UI libraries are named

Answer 39 · 2024-03-23T12:17:24.000Z

Just a small thought: with the radix-vue implementation, is it planned to drop popperjs? This was discussed in #409(comment) but not updated here

Answer 40 · 2024-03-23T16:04:26.000Z

It's implicit yes as Radix Vue uses Floating UI underneath (the new version of popper) so we don't have to.

Answer 41 · 2024-03-24T12:42:22.000Z

@sawa-ko It will be made with Tailwind v4. To what end would you make it compatible with Uno?

Because it can be done.
Because UNOCSS is better.
Because it was created by a member of the nuxt team.

Answer 42 · 2024-03-25T02:14:33.000Z

When is the expected release of the new version?

Answer 43 · 2024-03-26T04:59:28.000Z

Do you intend to implement virtual scroll for UTable or you gonna leave it to the users to decide how they want to do it?

Answer 44 · 2024-03-26T13:34:59.000Z

Thanks for the amazing work I was coming here to suggest a better config setup and I found it was already changed to a better one!

I'd like to suggest also integrating tailwindcss-animate plugin.

Answer 45 · 2024-03-26T13:38:03.000Z

It would be nice if Tailwind CSS v4 had plugins 😅 We'll have to wait and see how they implement it.

Answer 46 · 2024-03-26T14:13:21.000Z

Oh you're right forgot about that

Answer 47 · 2024-03-26T16:46:37.000Z

What do you guys think of removing the USelect in favor of USelectMenu (would be renamed to USelect)? Is there some cases where we specifically need native <select>?

The new USelect must allow group management (as <optgroup> native element) ;-) available in https://www.radix-vue.com/components/select

Answer 48 · 2024-03-27T01:05:32.000Z

Can ui 2.x.x be upgraded to ui 3.x.x?

Answer 49 · 2024-03-27T10:20:52.000Z

Can ui 2.x.x be upgraded to ui 3.x.x?

Yes, but not without some effort from your part.
Breaking changes are listed at the initial post.

Answer 50 · 2024-03-28T03:46:40.000Z

Just a thought ( you could ignore it if it's out of scoop) But it would't be great to have a switch for Styled / Unstyled components as Primevue did ?

Answer 51 · 2024-03-28T09:59:18.000Z

@Celibioux I guess this would technically be possible but I'm wondering what would be the benefit here. If you'd have to rewrite the entire config, why not write the component yourself by using radix-vue directly for example?

Answer 52 · 2024-03-28T10:10:48.000Z

One thing I've been struggling with: consistent rendering of rich text content within components. Mainly pulling from YML content files. For example, I want a bolded word in the primary text colour within the title of a particular UI component.

It would great to have minimal markdown support without having to override slots and use the <MDC> component. Though perhaps that's not a good default, so maybe some sort of config option to trigger when this happens?

Even when overriding slots and using the <MDC> component explicitly there's one problem that occurs a fair bit: since the MDC component always wraps the content in a <p> tag it often happens that this ends up with invalid HTML from the server (e.g. this markdown generated <p> tag is now within a <p> tag because that component's slot is wrapped in a <p> tag already). This results in a hydration error on the client. So I've ended up sometimes having MDC components, and sometimes using v-html, in overridden slots, which is unfortunate (and messy).

(Apologies if this is the wrong place to put this — I'm happy to split this out into a separate issue / discussion).

Answer 53 · 2024-03-28T10:14:24.000Z

@jits I'm aware of this issue and the only solution we have right now would be to replace every <p> by <div> which would not be great for SEO. There is an open issue about this for the Alert component: #1551. We do have the same issue in all @nuxt/ui-pro components.

Answer 54 · 2024-03-28T10:25:00.000Z

Thanks @benjamincanac for the quick response. Great to know it's on your radar.

I agree that replacing <p> tags automatically with <div> is not the best solution. One way I've tackled this before (when consuming content from a CMS) is to allow the developer of the template to configure which element (if any) to use as the wrapper. I guess this is more a feature request for https://github.com/nuxt-modules/mdc — I'm thinking the <MDC> component already has the tag prop, so you could introduce a contentWrapperTag: string | false prop as well, to define what the markdown parser should do.

Just to say: I'm making extensive use of Nuxt UI (and UI Pro) and loving it! Keep up the amazing work.

Answer 55 · 2024-03-28T18:20:45.000Z

This commit 49b73aa made me think that NuxtUI could automatically use <NuxtImage> if installed and fallback to <img> otherwise

Answer 56 · 2024-03-28T19:29:55.000Z

I was hesitant about do a PR to add a UImg component which returns either an img or nuxtimg element depending on whether the nuxt image module is present.

Answer 57 · 2024-03-28T19:58:27.000Z

@benjamincanac thanks for your quick answer and you're right but the idea came from seen many folks ask for unocss integration so unstyled could be possible to use unocss for styling ? And Yes there is Radix_vue and many out there but We Are NUXTERS 😂 We Love Nuxt and All its Ecosys

Answer 58 · 2024-03-29T01:28:07.000Z

@benjamincanac thanks for your quick answer and you're right but the idea came from seen many folks ask for unocss integration so unstyled could be possible to use unocss for styling ? And Yes there is Radix_vue and many out there but We Are NUXTERS 😂 We Love Nuxt and All its Ecosys

The preset api I mentioned above solves this problem as well. It decouples nuxt-ui from tailwindcss, giving the user the freedom to use any css tool of their choice to provide the styles.

The ui library can even remove the tailwindcss dependency and only provide tailwindcss presets, allowing the user to install the taiwindcss dependency and compile the presets on the user side.

Official presets can provide classes compatible with tailwindcss and unocss. The user is free to choose either unocss or tailwindcss.Even if they prefer another css tool, they can completely redefine their styles using another css tool.

I've been pitching the preset api I came up with, but @benjamincanac don't seem to be interested 😂 .

Answer 59 · 2024-03-31T06:15:11.000Z

I believe what @robin-dongbin is saying about the presets is very similar to what Shadcn UI does with the "default" and "New York" theme to change the appearance of every component. Maybe something like this could exist for Nuxt UI, but I'm not sure, since Shadcn does that by giving you the files for each component.

However, I agree with @benjamincanac saying that if you already intend to use Nuxt UI completely unstyled, try using Radix Vue to build the components yourself. You might find that very useful.

Radix Vue gives you full control over the styling of your components, while providing accessibility and the complex logic of the components for free. Use vanilla CSS, Tailwind, UnoCSS... whatever you consider best.

Nuxt UI is meant to give you good looking, opinionated and pre-styled UI components, but expose the API to customize them when needed. And in my opinion, it does it wonderfully.

I invite you to take a look at Radix Vue to build your own components if you apply to any of the following:

You end up changing the UI of almost every component to match your branding.
You don't agree with the choices for the stack (Tailwind, TanStack Virtual, etc.).
You need a component that is not currently offered by Nuxt UI.
You need to add custom logic/behavior to your components internally.

I won't lie... It can be significantly more work. But it is worth it if you really need it.

Answer 60 · 2024-03-31T06:23:04.000Z

@ChrisGV04 Thank you for your time replying on this really great answer

Answer 61 · 2024-04-25T15:50:43.000Z

I forgot to mention that the repository we're working on is public if you want to check out the progress: https://github.com/benjamincanac/ui3.

The development is going very well, we're only missing 12 components and I can say that maintaining this version will be significantly easier. Also, contributing will be effortless with the internal CLI we created to initialize components: https://github.com/benjamincanac/ui3/blob/dev/cli/templates.mjs.

I can't wait to finally release this 😊

Answer 62 · 2024-04-25T15:57:36.000Z

With v3 can we have table footers? ❤️ #1025

Answer 63 · 2024-04-25T18:15:55.000Z

With v3 can we have table footers? ❤️ #1025

And sticky headers!

Answer 64 · 2024-04-26T13:41:54.000Z

I forgot to mention that the repository we're working on is public if you want to check out the progress: https://github.com/benjamincanac/ui3.

The development is going very well, we're only missing 12 components and I can say that maintaining this version will be significantly easier. Also, contributing will be effortless with the internal CLI we created to initialize components: https://github.com/benjamincanac/ui3/blob/dev/cli/templates.mjs.

I can't wait to finally release this 😊

Awesome work ❤️
What about Vue compatibility? Will we definitely see it in the next major release?

Answer 65 · 2024-04-26T14:29:44.000Z

I was hesitant about do a PR to add a UImg component which returns either an img or nuxtimg element depending on whether the nuxt image module is present.

@benjamincanac I added something similar on @nuxtjs/mdc https://github.com/nuxt-modules/mdc/pull/180/files

Answer 66 · 2024-04-26T14:40:01.000Z

Would it be possible to update UAvatar to be compatible with masks in v3? The Squirqle mask looks amazing! 🤩

I feel like this isn't currently possible with a chip #1627

Answer 67 · 2024-05-03T12:47:03.000Z

~~Nuxt Icon beta implements the offline usage from iconify and supports SSR. Will it be integerate in v3 and drop egoist/tailwndcss module?~~ It already does

Answer 68 · 2024-05-23T09:33:59.000Z

VerticalNavigation / HorizontalNavigation should be NavigationMenu with an orientation prop

I whish that component (especially on orientation="vertical" had some way to keep the NavigationMenuSub expanded when its submenu item is active. For context radix-vue/radix-vue#892

Even better if NuxtUI would have the vertical navigation similar to the one on Naive UI or Ant Design

v3

Overview

Documentation

Breaking Changes

`Accordion`

`Avatar`

`Button`

`Divider`

`Dropdown`

`Form`

`Link`

`Toggle`

`Popover`

`Tabs`

`Tooltip`

`Modal` / `Slideover`

`VerticalNavigation` / `HorizontalNavigation`

Components

Overview

Documentation

Breaking Changes

Accordion

Avatar

Button

Divider

Dropdown

Form

Link

Toggle

Popover

Tabs

Tooltip

Modal / Slideover

VerticalNavigation / HorizontalNavigation