Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

v2 #908

Open
zernonia opened this issue May 11, 2024 · 19 comments · May be fixed by #1326
Open

v2 #908

zernonia opened this issue May 11, 2024 · 19 comments · May be fixed by #1326

Comments

@zernonia
Copy link
Member

zernonia commented May 11, 2024

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?

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.

@zernonia zernonia pinned this issue May 11, 2024
@k11q
Copy link
Member

k11q commented May 18, 2024

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
Copy link

gustojs commented May 19, 2024

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
Copy link
Contributor

edtorba commented May 22, 2024

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
Copy link

@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
Copy link
Contributor

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:

@zernonia
Copy link
Member Author

@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.

@teleskop150750

This comment was marked as off-topic.

@yacinehmito

This comment was marked as off-topic.

@teleskop150750

This comment was marked as off-topic.

@zernonia

This comment was marked as off-topic.

@sadeghbarati

This comment was marked as off-topic.

@teleskop150750

This comment was marked as off-topic.

@zernonia zernonia linked a pull request Oct 1, 2024 that will close this issue
@iamandrewluca
Copy link

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

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

@MickL MickL mentioned this issue Oct 20, 2024
11 tasks
@mary-ext
Copy link

mary-ext commented Oct 24, 2024

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
Copy link

mkeyy0 commented Nov 20, 2024

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
Copy link

mkeyy0 commented Nov 20, 2024

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.

@teleskop150750

This comment was marked as off-topic.

@zernonia
Copy link
Member Author

zernonia commented Nov 22, 2024

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
Copy link

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.