v2

[zernonia]

Announcement: Changes Coming to Radix Vue

Introduction

First and foremost, we really want to express appreciation for all the effort put in by the Radix UI team in creating the absolutely powerful, unstyled, high-quality, and accessible components that this project was originally ported from.

Background

However, as feature requests grew, Radix Vue began to add more components and features, and modify certain behaviors specifically tailored for Vue. As a result, Radix Vue started to feel like a unique component library rather than just the ported version of Radix UI. Therefore, we are planning to give it a different identity.

What's Coming in v2?

• Brand change
• NPM registry change
• Some component refactoring link to project https://github.com/radix-vue/radix-vue/labels/v2

Note

1. We will still be pushing bug fixes and introducing some new primitive components prior to the v2 release.
2. We are still brainstorming the new identity name. Please share any ideas you have in the comments below.
3. We are open to suggestions for areas of improvement. Please ensure that any suggestions are sensible and would result in a general improvement rather than addressing only a specific edge-case.

Important

We understand that these changes may require some major adjustments in your project, and we apologize for any inconvenience in advance.

[k11q]

Hi @zernonia ! Big decision! I had my concerns but after several thought and looking back at the project, I think a rebrand is a really good idea! I think what you and other contributors have been building and currently building has turned this library into a very big project, and in many sense it has grown larger than the radix primitives. I think a rebrand is sign of growth and by detaching from the previous radix brand, it removes a significant blocker, allowing decisions to be made without the concern of fitting the radix brand. Overall i'm very excited for the future of the library and see what you'll come up with 🚀🚀🚀

[gustojs]

How about something that works both ways? Can be regarded as something separate, but still points at the origins. Vuedix, for example.

Similarily to how Nuxt and Next exist as separate entities that both influence each other.

[edtorba]

Just a hint, you can also look into Latin words, at least it seems that's what the Radix team did, e.g., radix = root (it seems). What you want is something simple and catchy, while also being unique.

[Rolanddoda]

@zernonia does this means that there are going to be breaking changes in v2?
I think there might be a lot of people evaluating Radix Vue and if 1.x is going to be stale after a few months, then that should be made clear.

[cyyynthia]

While the project doesn't follow semver, a major version bump is always indicative of some breaking changes. I don't think the project has a clear list of what's going to break, but form-related components are planned to go through changes such as #1017, internal changes that may affect their behavior (backing hidden field, exposed API, ...)

Radix Vue published breaking changes for components in alpha in patch-releases, and these patch-releases often contain features.

As someone who recently adopted Radix Vue, I can say for those looking to adopt it it's very promising and we're having great results in the project it's being used in, but don't underestimate the alpha label on components (see prev. remark on breaking changes), and remember that the project is quite young so there are a handful of areas where it can improve 😅

I don't think v2 will bring huge breaking changes, but I'm not a maintainer of the project and haven't been in its internals for long enough to know what needs to change. So long your project follows a healthy component structure (you generally shouldn't use raw components and wrap them with your own styles first; or use something like shadcn-vue which is versioned separately) the changes shouldn't be too bad - but, I'm not a maintainer just a user who really enjoyed using this lib thus far 😃

Possibly relevant issues tagged https://github.com/radix-vue/radix-vue/labels/v2:

• [Feature]: Refactor form dependant components #1046
• Improve API clarity for the PaginationRoot component #1043
• [Refactor]: change form component from v-model:checked/v-model:pressed to v-model  #1017
• [Feature]: Combobox rendering optimization #498

[zernonia]

@Rolanddoda Yes in the description we mention that v2 will have breaking changes (major adjustments in your project). Worry not that we will mentioned all of that breaking changes in the changelog, and will be releasing rc's earlier too.

@cyyynthia Currently we try our best to follow semver 😁, especially for the breaking changes part. In minor version we have new changes but with deprecation warning, unless for alpha component. But we try to minimize the breaking in alpha as well and aimed to publish major changes in the same minor version.

[iamandrewluca]

@zernonia, in the issue description, the link to the project seems to be incorrect

https://github.com/orgs/unovue/projects/3

[mary-ext]

thoughts on exposing components like FocusScope, FocusGuards, and DismissableLayer as public API?

I get that Radix (React) has them as internal APIs as well but we're currently having problems at work adapting Dialog due to their clunky design, so at the very least we want to have some consistency with other Radix components we are using.

right now we're considering just patching Radix Vue here but it'd be brittle because the library is bundled and mangled, which would mean we'd have to redo the patch every time we want to upgrade Radix Vue.

---

To summarize my issue with the Dialog component, they aren't exactly great because the "intended" way of writing them would be like so:

<DialogRoot>
  <DialogTrigger>
    open modal
  </DialogTrigger>

  <DialogPortal>
    <DialogContent>
      <HelloWorldDialog />
    </DialogContent>
  </DialogPortal>
</DialogRoot>

This is the "intended" way for dialog states to only be inited on mount and thrown away on unmount.

If this was React, I would've written this like so, where I would have a file defining both <HelloWorldDialog /> and <HelloWorldInnerDialog />

export const HelloWorldDialog = (props) => {
  return (
    <Dialog.Root>
      <Dialog.Trigger asChild>{props.trigger}</Dialog.Trigger>

      <Dialog.Portal>
        <Dialog.Content>
          <HelloWorldInnerDialog />
        </Dialog.Content>
      </Dialog.Portal>
    </Dialog.Root>
  );
};

const HelloWorldInnerDialog = () => {
  const [count, setCount] = useState(0);

  return <div>Hello world!</div>;
};

Unfortunately, this is not React, and we are not using JSX but rather Vue's templating language, so if we want this, we'd have to make two component files, one for the exported component and one for the actual dialog component. This is super cumbersome to use, and I'd prefer we'd avoid this even if it means we won't be able to have dialogs return focus to the trigger button on unmount (we can simply write workarounds, to be fair, our dialogs aren't always coming from a trigger button anyway)

[mkeyy0]

Regarding the name, I don't have a specific proposal. But I agree with @gustojs proposal. It's better to keep some kind of reference that this library was created using Radix as a reference. The reason is I read some discussions on Reddit and other forums many people see the radix library in React and are searching for an alternative in a Vue world. And that's how I initially found this great library. I've just searched Radix with vue and found this library. I guess some people found this library in this way as well.

[mkeyy0]

Also, I have a question regarding breaking changes. I'm using the shadcn vue library with Radix as well. I don't know if this question is to you specifically, but are you considering that shadcn heavily relies on Radix components during the development? Because it would be nice to keep the connection between those 2 libraries.

[zernonia]

Also, I have a question regarding breaking changes. I'm using the shadcn vue library with Radix as well. I don't know if this question is to you specifically, but are you considering that shadcn heavily relies on Radix components during the development? Because it would be nice to keep the connection between those 2 libraries.

Yup @mkeyy0 ! we are working on updated version of shadcn-vue with reka-ui. Once that is ready we will release both together 😁

[jd-solanki]

we are working on updated version of shadcn-vue with reka-ui

• I think this will be based on TW v4 beta right?
• Is we're rebarding shadcn-vue to something else?
• I'm just starting new project with shadcn-vue so can we start with new alpha or current stable?

[romansp]

VueUse released v12 with Vue 3 support only. One could dream about bumping it as well in v2.

I guess we could even do this in v1 as Vue 2 was never supported by radix-vue afaik?

[zernonia]

Thanks @romansp ! That sounds like an amazing news! We can include this upgrade in v2 😁

And yes, radix-vue only support Vue 3, so we can technically upgrade it as well. But since it's a major version upgrade, I afraid that would incur some unforeseen breaking changes, so best not to upgrade first 😬

[zernonia]

Yooo @jd-solanki !

• I think this will be based on TW v4 beta right?

I don't think this is in shadcn's roadmap for now. But we shall see 😁

• Is we're rebarding shadcn-vue to something else?

Nope, shadcn-vue will stays, but we will have reka-ui version of shadcn-vue hosted under @next tag
https://next.shadcn-vue.com/

• I'm just starting new project with shadcn-vue so can we start with new alpha or current stable?

Currently reka-ui still in alpha, so you should use shadcn-vue for now, and the upgrade to next.shadcn-vue should be relatively straightforward by just running npx shadcn-vue@next add <needed component> when it's ready 😁

[Radiergummi]

@zernonia I'm just now migrating our product from Vue 2+Vuetify 2 to Vue 3+radix-vue (it's… gruesome, I tell ya) and wonder if I should just use Reka UI now? From what I see, the changes (for now) should be limited to import paths? Or would you suggest waiting for the stable release?

[HummingMind]

Thanks @romansp ! That sounds like an amazing news! We can include this upgrade in v2 😁

And yes, radix-vue only support Vue 3, so we can technically upgrade it as well. But since it's a major version upgrade, I afraid that would incur some unforeseen breaking changes, so best not to upgrade first 😬

It's a non-breaking release, and is equivalant to v11.3. The major version bump was to drop Vue2 support. I don't think anything else changed.

[zernonia]

@HummingMind correct. I mention breaking change because radix-vue still using [email protected] 😁