浅谈 UI 组件库

我在某天尝试了几款不同的组件库之后，写下了一些想法

主流与小众

主流 UI 组件库，使用人群多，维护与开发稳定。如 Bootstrap、Element、Antd。通常在正常学习过程当中，就能知道它们存在。并不是说没有其他组件库了，而是先学习一种最常用的

后续我会将 UI 组件库简称为组件库

能够应对日常开发，再考虑其他个性化。

且主流组件库通常会影响后续出现的组件库，成了一个大众的模板，在 API 上便是大同小异

或者说，这几乎成了 UI 组件库的通用模板

个人组件库，比如 Naive UI。在我学习 Vue3 ，正在挑选合适的组件库时，就收到了推荐（尤大），效果确实非同凡响，官方文档也是跟段子站点一般，很“不正经”。但这种“不正经”的官方文档反而更受欢迎，这也是自由思想

不过，这种组件库很难在一开始就受到关注。甚至说成型之后，如果没有牛人推荐，很多人是不会知道它们的存在，哪怕这个组件库已经成型，可以应对所有开发

不存在最爱的，只是没有遇到更好的

相比之下，在大厂孵化出来的产物，比如最近出现的 Semi Design，社区知晓度会高很多

灵活与封装

某天，我想看看 Antd 之外的世界，于是看到了 Material-UI

后续简称 MUI

但是，那次给了我一种非常的可怕体验，感觉糟糕透了。有太多，感觉是伸手就来的东西，但是在 MUI 当中都是不存在的

比如 <Form/>，很难想象一个组件库当中居然都没有。深入了解之后，发现验证都需要自己手写，这样的一种出界体验让我又缩回了 Antd 的怀抱。那时候就感觉很迷离，这样的组件为什么还有这么多人使用？

对比两者的下拉框组件，我将对其进行了提纯，仅展示基本使用

// MUI
import React from "react"  
import Select from "@mui/material/Select"  
import MenuItem from "@mui/material/MenuItem"  
  
export default function BasicSelect() {  
  return (  
    <Select fullWidth defaultValue="Ten">  
      <MenuItem value="Ten">  
        Ten  
      </MenuItem>  
      <MenuItem value="Twenty">  
        Twenty  
      </MenuItem>  
      <MenuItem value="Thirty" disabled>  
        Thirty  
      </MenuItem>  
    </Select>  
  )  
}

// antd
import React from "react"
import { Select } from "antd" 

const { Option } = Select

export default function BasicSelect() { 
  return (
    <Select defaultValue="lucy"> 
      <Option value="jack">
        Jack
      </Option> 
      <Option value="lucy">
        Lucy
      </Option> 
      <Option value="disabled" disabled>
        Disabled
      </Option> 
    </Select>
  )
);

当前来看差异不大，还有一个参数似乎应该存在，options

// 必要字段
export interface Option {
    
      
  label: string  
  value: string  
}

可以通过传入参数动态渲染

import React from "react"
import { Select } from "antd" 

const { Option } = Select

export default function BasicSelect() { 
  return (
    <Select  
      defaultValue="lucy"  
      options={[  
        {  
          title: "Jack",  
          value: "jack"  
        },  
        {  
          title: "Lucy",  
          value: "lucy"  
        },  
        {  
          title: "Disabled",  
          value: "disabled",  
          disabled: true  
        }  
      ]}  
    />
  )
)

能清楚的是，这只是组件帮忙使用了 map() 来渲染。(⊙﹏⊙)于是， MUI 就没有提供该选项

真的是 MUI 难用吗，相对而言太难了，很多感觉很平常的东西都不存在，需要自己手动组装。不过，这同时也是 MUI 的特点，一种超然的灵活在其中

当我以学习者的角度再去尝试 MUI 时，便可以明白一些常用的组件是如何完成封装的。利用小部件自行封装复杂的 <Table/> 与 <From/>，对个人的组件化思维很有提升

当然，还有一点没有提，就是为什么要换组件库？选择适合自己且熟悉的，不就够了吗

我自己的回答会是这些

审美疲劳，想换个风格
尝试新事物，或许会有意外的收获与惊喜
太多人使用了，我想显得与众不同一点，至少说别让人看到界面就知道使用的是什么组件库

结束语

看似上面我说了很多 MUI 的坏话，怎么看都不好使，因为组件库的通常定位是：追求高效且美观

两者都是极佳的产品，存在多样性，不会让人没得选

并不存在，只选择其一使用，如同 Vue 与 React 一般，那能说只学一样吗，都需要接触一下，~~说不定另一个就是自己的小情人~~。个人偏向不可避免，但别捧一踩一。

主流与小众

灵活与封装

结束语

猜你喜欢