-
-
Notifications
You must be signed in to change notification settings - Fork 231
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
Comments
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 🚀🚀🚀 |
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. |
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. |
@zernonia does this means that there are going to be breaking changes in v2? |
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: |
@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 @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 |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
@zernonia, in the issue description, the link to the project seems to be incorrect |
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 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) |
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. |
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. |
This comment was marked as off-topic.
This comment was marked as off-topic.
Yup @mkeyy0 ! we are working on updated version of shadcn-vue with |
|
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
Important
We understand that these changes may require some major adjustments in your project, and we apologize for any inconvenience in advance.
The text was updated successfully, but these errors were encountered: