Vercel

我们能够专注于在 Radix 基础组件之上构建可靠的用户体验。对于希望快速行动的产品团队来说，UI 组件存在太多难以解决的难题。

¥We’ve been able to focus on building solid user experiences on top of Radix Primitives. With UI components, there are just too many angles and rabbit holes to cover for product teams that wish to move quickly.

请描述一下你正在使用 Radix Primitives 的项目类型？

¥Describe the type of project you are using Radix Primitives on?

我们在设计系统的某些部分、多个中大型公共和内部 Next.js 应用、营销网站以及我们实验的内部原型中使用了 Radix Primitives。

¥We are using Radix Primitives on some parts of our design system, multiple mid to large size public and internal Next.js apps, marketing websites, and internal prototypes that we experiment with.

正如你所看到的，项目各不相同。有些项目主要由几位工程师贡献，而有些项目则有超过 20 位工程师每天贡献代码。项目也处于不同的阶段。我们既有长期持续多年的项目，也有可能尚未面世的实验。

¥As you can tell, the projects vary. Some have only a few engineers primarily contributing, others have 20+ engineers contributing daily. Projects are also in very different stages. We have long-standing multi-year projects, but also experiments that may not see the light of day.

Radix Primitives 在哪些方面帮助了你和你的公司？

¥In what ways have Radix Primitives helped you and your company?

Radix Primitives 为我们节省了大量时间，无需从头开始重新实现常见的 UI。我们能够专注于在它们之上构建可靠的用户体验。对于希望快速行动的产品团队来说，使用基础组件时，需要处理的角度和问题实在太多。

¥Radix Primitives have saved us a bunch of time on not re-implementing common UI from scratch. We’ve instead been able to focus on building solid user experiences on top of them. With primitives, there are just too many angles and rabbit holes to cover for product teams that wish to move quickly.

在 Radix 之前，我们的“基础组件堆栈”也非常分散。部分组件是定制的，无障碍覆盖率可能较差，其他组件则来自 Reach UI、React Spectrum 或任何其他第三方。如今，我们可以更轻松地依赖 Radix 作为我们所有基元需求的供应商。知识在组件之间更容易迁移，并且我们还可以避免在其内部实用程序之外引入新的第三方依赖，从而节省包大小。

¥Our “primitives stack” before Radix was also very scattered. Some components were custom-built, with possibly poor accessibility coverage, others were from Reach UI, React Spectrum, or any other 3rd party. Today, it’s a lot easier for us to rely on Radix to be the vendor for all of our primitive needs. Knowledge is a lot more transferable between components and we possibly also save bundle size by not introducing new 3rd party dependencies along with its internal utilities.

你对 Radix 开发者体验有何看法？

¥What are your thoughts on Radix developer experience?

DX 非常棒。我喜欢文档和组件之间 API 的一致性。学习单个组件的同时，还能将一些细微的差别延续到其他组件上，就像 forceMount、as、data-state 那样，这很棒。我认为这是维系稳固用户群的关键。用户会一直使用，因为它已经很直观且有效。对我个人而言，动画非常重要，因此能够在不了解任何字段知识或使用外部库的情况下，轻松地在顶部添加一个进入/退出 CSS 动画，这真是太棒了。

¥The DX is phenomenal. I love the documentation and API consistency between components. It’s great that you can learn a single component and also expect some of the nuances to carry on to others, à la forceMount, as, data-state . I think this is key to maintaining a solid user base. Folks will always come back because it’s already intuitive and works. Animations are a huge deal for me personally, so being able to easily throw an entry/exit CSS animation on top with little domain knowledge or external libraries is superb.

在某些情况下，我发现了一些不一致和错误，但 Radix 团队总是反应迅速、积极主动，并乐于提供临时的解决方法，以便我在他们解决问题期间能够继续前进。抱歉，这里只有赞美之词。 🙌

¥In some cases, I’ve found a few inconsistencies and bugs here and there, but the Radix team is always super responsive, proactive, and keen to provide temporary workarounds so I could be unblocked and move forward while they resolve. Sorry folks, nothing but praise to mention here 🙌

你对 Radix 文档有何看法？

¥What are your thoughts on Radix docs?

刚刚试用了最新版本的文档。它写得非常好，并提供了精彩的示例来说明实际用例。如果能像 Hero 组件一样渲染示例，那就太好了。现在回想起来，我其实并不需要经常使用文档。仅用于复制起始代码。其余理念源自经验。 - 使用 open 和 onOpenChange 等。

¥Just played around with the latest version of the docs. It’s extremely well written with great examples that illustrate real-life use cases. It’d be neat to render the examples as well, similar to the hero. Now in hindsight, I don’t really need to use the documentation that often. Only to copy the starting code. The rest of the philosophies carry over from experience - using open and onOpenChange and such.