[设计艺术] 如何评价 Na?ve UI?

天天财汇购物网址万年历小说 | 三峰软件小游戏视频

TxT小说阅读器
↓小说语音阅读,小说下载↓

一键清除系统垃圾
↓轻轻一点,清除系统垃圾↓

图片批量下载器
↓批量下载图片,美女图库↓

图片自动播放器
↓图片自动播放,产品展示↓

首页淘股吧股票涨跌实时统计涨停板选股股票入门股票书籍股票问答分时图选股跌停板选股 K线图选股成交量选股 [平安银行]

股市论谈均线选股趋势线选股筹码理论波浪理论缠论 MACD指标 KDJ指标 BOLL指标 RSI指标炒股基础知识炒股故事

商业财经科技知识汽车百科工程技术自然科学家居生活设计艺术财经视频游戏--

天天财汇 -> 设计艺术 -> 如何评价 Na?ve UI? -> 正文阅读

[设计艺术]如何评价 Na?ve UI?

[收藏本文] 【下载本文】

https://www.naiveui.com/

本以为这又是哪个 KPI 轮子，但一想不对，大厂项目绝不会起这种游走在边缘的名字。再仔细一看文档才感受到，这个项目展示了作者丰富的内心世界。
首先看这名字就知道，这文档里总要有点虎狼之词吧（in English）：

但就好像过度动画容易引发不适一样，真正好的文案也应该是润物细无声的，像这个 Back Top：

这种兼备诙谐与哲理色彩的一句话简介，一般常见于国外的项目中。作者不仅驾驭得不错，还能坚持在中英文版之间一致地同步，这就更难能可贵了。你看这还能在 Button Group 里整一首小诗：

「活着 / 不多 / 不少，活着 / 其实 / 很好，再吃 / 一颗 / 苹果」……不知道作者想再吃一颗的到底是不是苹果。
感觉作者的文案质量已经超越了很多产品经理，像这个放 404 和 403 的 Result 组件（打开链接往后翻更精彩）：

不过你要是觉得文档里都是大白话，那你还是 naive 了。稍微翻一下还能找到很多致敬细节，比如这个 Popconfirm：

「一切都将一去杳然，任何人都无法将其捕获。我们便是这样活着。」
——村上春树《且听风吟》
并且作者显然不只喜欢读小说，还喜欢听歌。比如这个 Ellipsis 的示例，就来自万青的《大石碎胸口》：

除了中文歌以外，还有致敬英文歌的文案。像这个 Message 里的消息，就来自披头士的《No reply》和脍炙人口的《Blowin’ in the Wind》：

这个致敬的层次啊，显然比我这种只懂在测试用例里写 114514 的水平不知道高到哪里去了。另外文档里还有很多能体现作者个人气质的细节。比如这个 Alert 就表明作者日常回家，喜欢躺平，最怕老婆挂电话和穿越到 USSR：

另外感觉作者和天津平山道很有渊源，甚至借助 Notification 组件的功能编冷笑话来宣传。这是在借开源的机会推广自己的故乡吗？感觉这很值得知乎上一些知名天津用户学习：

另外看这个 Dropdown，感觉作者的微信朋友圈应该也很精彩：

最后这个 Thing 里面还黑了一下那些包容万象的业务组件：

翻完一圈文档，诸如此类的细节还有很多，感觉 naive 的竟是我自己。这显然是把项目当作自己的作品在认真做的，没有不少公司内部晋升驱动的 XXX-UI 组件库东拼西凑粗制滥造的感觉。以这样的走心程度看来，相信代码质量应该也是值得信赖的（技术细节可以直接看原作者的回答）。
最后，我建议大家不妨以一定的频率体验下 TuSimple 公司的这个项目，因为俗话说得好嘛，sometimes naive。
@这里是安全的

作为作者就不评价自己的东西了，简单说说自己搞这个的经历吧（写完了看看也不短）。
2019.5 为什么开始做这个
2019 年 5 月我刚到图森，那个时候感觉公司项目的 UI 感觉有很大改进空间，所以就尝试自己搞一个。那时候先在下班的时间弄了几个组件，Button、简单的 Menu 什么的，文档也是纯 Vue 写的。恰好那个时候公司的项目比较简单，我写的这几个也够用了，不够用我再写就是了，于是 naive-ui 就进入了公司的项目当中。值得一提的是，那个时候的设计稿是暗黑模式的，于是所有的组件都是暗色。
之后的几个月
刚开始搞组件库，很多问题都不太了解，比如 Modal 怎么写。现在的开发者很幸福，有 Teleport 能用，20 年的时候我其实对 React.createPortal 十分眼馋。但是在那个时候，我想不出来，就翻了翻 Vuetify 的源码，学到了叫 detachable 之类的 mixin，然后就屁颠屁颠的继续写了。
至于项目的整体结构，当时非常多的参考了 element，BEM 的写法我也是和他们学的，那个 Scss 的 mixin 我看了觉得还真的挺精巧。（至于为什么没用 Less，因为 Scss 长的更像 CSS）
正经的文档
之前提到，一开始的文档使用 .vue 写的，写着写着就会发现冗余代码多到没法看。那时候我看到了 ant-design 的文档都是 markdown 写的，就开始琢磨要不要整个 webpack-loader，用了 marked 当解析库，弄出了一个和现在结构很像的文档网站。
亮色模式
是的，说来很奇怪。这个组件库是先有暗色模式再有亮色的，当时组件数量基本足够业务使用，缺什么我就写什么。但是一个组件库，不能亮起来怎么想都很奇怪。那个时候我开始拓展 SCSS 的 mixin，让他能直接生成两份不重叠的主题样式（比如 font-size 只会出现一次）。
API
那个时候我隐约的能感觉到 API 的设计对组件至关重要，不过还不是很明确，和同事宣扬了一些 API 设计重要性的观念，但是也没有非常深入。这块非常多的受到了 ant-design 的启发，不过我那时候（antd 3.0 时代）还很奇怪，为什么 antd 很多组件只有非受控模式（印象如此，不是很确定。虽然我知道非受控性能更好，但是 v-model 给我带来的惯性让我觉得受控模式就够用了，后来我看 antd 的组件最后也都补上了受控模式），如果你也想写一个组件库，记得每个输入类的组件都应该有受控和非受控模式。
关于 API 设计这块能说的实在是太多了，由于懒惰不太想展开讲，可以关注一下
@二货
的《Ant Design 4.0 的一些杂事儿》系列文章，他的看法我大多数是认同的。
2020.2 疫情来了
闷在家里重构了一堆组件，给 select 加上了社区实现的虚拟列表（后来因为那个库没有及时更新 Vue 3，我就自己写了）。那时候由于 Vue 3 消息不多，公司内部的需求基本也都能满足，所以更新的不是很频繁。
2020.4 css-render
当时我看着 gzip 之后一百多 KB 的样式文件（dark + light），陷入了沉思，太大了。我想时间换空间，看着那么大的 CSS 实在是过于不爽。我调研了一波 JSS/styled 的解决方案，感觉很难满足我保留类名的需求，以及他们都太大了，我印象里 JSS 十几 KB，styled 也不小。明确了一下需求之后，我感觉我想要的只是“能在 JS 层面用类 Scss/Less 的语法写样式，之后把样式挂到浏览器里“。所以开始动手写一个能满足这个需求的库 css-render。最后基本满足了我的需求，维持了原有的 BEM 语法，这段样式重写花费了巨量时间，大概有几个月，因为不光是样式本身需要重写，那些 Scss 变量也需要想办法用合适的 API 转移到 JS 当中。
2020.6 杭州时间
当时去蚂蚁实习了，深入了解了一下 ant-design，从
@偏右悄悄地
和
@二货
老师那里学到了很多东西。当时被豆酱老师带着做了很多东西，很多从 antd 学到的代码最后也被我借鉴（抄）到了 naive-ui 里。如果你们想看 react 组件库的代码，antd 显然是一个很好的选择。不过 antd 整体的架构，我觉对于团队维护还好，但是对于单人太过庞大（下面几十个 react-component 的仓库），因为 github 仓库很多不是很利于单人维护，并且工具链也很长，所以我在之后的改进中也比较在意单人可维护性（因为确实，主要只有我一个人干）和工具链的长度（能短就短）。
我个人的选择是拆库的时候按照功能群拆分，每个功能群是一个可以进行 treeshaking 的仓库。后面在迁移 Vue3 的时候拆了几个库出去，不过也不多。
2020.9 是时候 Vue 3 了
结束杭州的实习，Vue 3 已经基本可用，那时候我决定先把仓库转移到 Vue 3，当时写了一个组件库升级的备忘录，稍微学了一下 composition api 就开始干，新 feature 能上的基本都上了，可维护性提升和 mixin 相比不是一点半点。不过也是花了比我预计长很多的时间。
拥抱 css variables
因为是公司纯内部项目，我不是很在意“兼容性”，那时候虽然样式已经用 css-render 重写了，但是还是会对亮色和暗色单独生成一次样式。那时候恰逢公司新组建了设计团队，想对组件库的样式进行较大的改动，我想把这些改动尽量通过“主题插件调整”的方式实现。经过了几次 API 的修改，终于把原有的样式基于 css 变量实现了出来，功能完全不变，可维护性和样式生成性能都有了提升。
Vite
当时得知 antd-vue 的团队切到了 vite，我觉得不错，花了几天解决了一下，当时打包还是给我坑的挺惨，坑是不少。
2021 年初，上吧 Typescript
当时已经写麻了，感觉这玩意以后如果开源还不是 ts 也太没面子了，用户连类型提醒都用不到。用户可以不用，但是我不能不给，所以就一个组件的一个组件开始改，组件很早以前都是用 template 写的，但是在那时候 vue template 的 ts 支持确实不够用。但是我感觉已经等不了了，所以经过了一点实验，选择了 tsx。最后改了几周，改完了。后面有花了同样多的时间把主题系统改成了基于 typescript 有类型的（当时的时间节点非常好，如果不是 ts 出了模板字符串类型，我的主题系统就写不下去了，因为涉及到 key 的转化）。
到开源之前
查缺补漏，重构了一些组件，增加了一些组件，反正看着啥没有就想补进来。然后就开源了。
说实话搞到现在也没有对 Vue 理解的太深入，只能说用的很熟，虽然提了一些 Bug（十几个是有的），但是对于 PR 只能提一些比较外围的模块。修我提的 Bug 的几个人的 github 头像我倒是认的挺熟的，反正每次就那几个人。
这玩意能搞出来少不了很多人的帮助和指导，以及很多开源社区代码的启发，同事的使用、设计师的意见也都很重要。
希望它未来能稳定的发展下去。

具体还没看太深入，简单评价一下：
从风格上看，应该是深受 Ant Design 影响无疑了。完成度相当高，组件数量很多，很多组件甚至都加上了键盘交互和 ARIA 语义标注。对目前的 Vue 3 生态是一个不错的补充。使用了运行时的主题系统，可能有一些性能损耗，不过也会更灵活易用一些。常见的会出现性能问题的组件都支持了虚拟滚动，很不错。文档文案很有趣，案例也比较丰富，还都自带中英文双语版，可以想象作者付出了多少精力。刚起步，issue 还不多，亟待社区应用以后大量反馈。等着修 bug 吧！
组件库是个上限非常高的方向，仅靠个人力量很难持续维护，还是需要社区的广泛参与才会有未来。

我不是前端开发者，但我见得太多了

没啥好说的，用就完事了~star就完事。
大概是在20年6月份认识的组件库作者，当时我参与了antd的一些贡献，同时作者当时也在阿里蚂蚁那边实习，当时和作者聊到正在开发一个vue3的组件库并且正在开发，当时听了一些描述以及看了ui效果觉得特别流畅和丝滑，然后当时校招去面试图森也有听到那边聊过。
这个项目本身实现我不是特别了解，因为我自身项目开发的场景使用到的vue还是比较少的，但确实有体会到作者在开发过程中付出的努力，因为这个项目实际上是完全在作者研究生期间完成，去年作者还在和我聊虚拟列表的实现，然后是用vue3+自己写的css-render实现了一版，当时想帮作者完善一些feature但无奈时间少以及菜没贡献上hhh。
07akioni/vueuc?github.com/07akioni/vueuc

组件库里面还有个xicons，这个的代码非常短小精悍，有大量的icons图标，当时记得作者使用rollup来进行打包导致时间特别长且会卡顿，最后vite出来之后应该也是在很短的时间内就替换成vite然后性能得到了肉眼可见的提高。
07akioni/xicons?github.com/07akioni/xicons

其他技术相关的可能我就了解不是特别清楚，但聊点题外话，作者确实对这个项目付出了非常大的精力，一个在校生的github commit记录是肉眼可以见得到的绿。而且作者的代码功底也确实厉害「毕竟pku...」，在贡献antd的期间(作者本身也是antd的collaborator)，当时我也大概是第一次参与大型开源项目贡献，有许多不会的问题都会和他咨询，甚至之后我校招去了字节，在字节做一些基础工程的建设，例如在开发monorepo或者类似cli工具的时候，就经常有和作者讨论或者说请教一些技术相关的事情，经常会讨论很长很长时间。作者每天都会开发组件库到深夜，偶尔也会和我交流一些vue3在开发过程中遇到的坑，虽然听不太懂，但确实觉得开拓眼界，有时交流完还会对着一些issue或者是文档去研究一段时间，实在是受益匪浅吧。
最后也希望naive ui能越来越火，最近在忙毕设相关的事情，等结束之后也来研究研究这个vue3的组件库~

这个UI，光听名字就让人非常的兴奋的excited 。
确实可以让我们多学习一个Learn one more thing.

评价一个ui库好不好，第一件事就是要去看看表格做得怎么样。
看完了表格后，我的评价是：中规中矩,比iview略强。当然我没有细看，因此这只是一个粗略的评价。
现代的UI库总是喜欢搞很多动画，实际上很多时候真的很多余。然而：功能永远都是第一位。
再提一下表格：我目前最满意的就是 BluePrint.js的表格，但是BluePrint的缺点是性能。

看起来作者还是个杰伦粉呢

失望地离开了回答区

Naive UI 的最大优点是，对我来说：
自带这几年折磨过我的很多需求；Render 和 Slot 还是比较灵活；目前没有发现 Bug；
利益相关：Naive UI 用户

尤雨溪强推的 NaiveUI 的前端开源组件到底香不香，一探究竟

我更想知道因为评价有多少号没了。。。

说实话，公司名+这个组件库名让人忍俊不禁呐
还没有用过，不过看文档看得出作者是个有趣的人，希望下个项目能用到吧（

从文案到文档质量，从作者的用心程度这个 UI 库爱了。

我觉得我有必要来打一下这个问题。
naive-ui 还是写起来很舒服的，全程 tsx 无红线，类型提示没有问题。最重要的是遇到什么 bug 随时能和作者对接，深入探讨。顺便还水了几个pr。和之前 element-ui 写起来真的是一个天上一个地下。当然这个库还在初期，还需要社区的大力贡献。全程 tsx 写起来真的是很舒服了，除了 vue 本身一点局限性，不能 pass 任意 props 之外，其他写起来比 react fc 还舒服。
仅花了 5 天时间就用 naive-ui 重构了之前 vue2 element 写的后台。
https://github.com/mx-space/admin-vue3?github.com/mx-space/admin-vue3