uiwjs/uiw

v5 的开发计划

Opened this issue · 0 comments

jaywcjlove commented

自发布 v4 以来，积累了积累了一些问题和想法，希望在 v5 中处理好这些问题，是时候为未来的 v5 版本做一个计划了。这个计划没有明确开发时间，没有确定开发计划之前 v4 将会一直维护，在这里讨论一些 v5 开发的开发计划。

文档（英文文档）

很早有人提出英文文档需求 #75，我们仍然没有计划和实力提供英文文档（因为我们没有这个需求），但是，我们计划提供一个“架子”，供社区自己补充英文文档。

  • 所有组件文档支持在 GitHub 中完美预览，同时在文档网站中，支持示例预览和编辑。
  • 探索组件 API 文档通过 TypeScript 自动生成 (@microsoft/api-extractor)。
  • 文档支持明暗 🌓 主题切换，已经有具体探索，成果 dark-mode。
  • 文档示例预览使用 react-code-preview 探索更佳方法。 #785 @SunLxy

重新设计所有组件

老的版本也有设计，当初没有找到好的展现方式，设计文件丢失。新的 v5 将会使用 Sketch 设计，使用 Measure 将 Sketch 文件生成可预览的 HTML 文件，使用 Github 的 pages 功能进行展示，类似于 @uiw/icons 的图标设计展示。

  • 对已有的组件尺寸颜色进行规范。
  • 方便协同开发组件，提供在线设计预览。
  • 明暗主题设计。

升级图标组件

v4 之前使用了字符串命名图标 API，将所有 svg path 放到 json 文件中，通过字符串匹配，获得 svg 图标的 path 数据，生成图标。虽然体积做到了最小，但是全量引入 svg 的 path 数据，随着图标增加体积一样增大。所以我们对图标生成工具(svgtofont)进行升级，支持将每个图标生成一个单独组件，想使用哪个图标就引入哪个图标的 React 组件。这个特性 @uiw/icons 图标库已经支持了。

import { Adobe, Alipay } from '@uiw/icons';
import { Alipay } from '@uiw/icons/Alipay';

<Adobe style={{ fill: 'red' }} />
<Alipay height="36" />

在 v5 版本应该使用以下方法，处理组件库中的图标库使用：

- import { Icon } from 'uiw';
+ import { Alipay } from '@uiw/icons/Alipay';


- <Icon type="alipay" />

+ <Alipay style={{ fill: 'red' }} />
+ <Alipay height="36" />
  • 图标支持 web components ，升级 svgtofont 工具。

React 18

React 18 正式版已经发布，我们将所有不兼容的组件并一一修复。这在我们 v4.20+ 已经开始处理兼容问题，我们使用 React.StrictMode 严格模式组件，帮助我们处理：

  • 识别不安全的生命周期
  • 关于使用过时字符串 ref API 的警告
  • 关于使用废弃的 findDOMNode 方法的警告
  • 检测意外的副作用
  • 检测过时的 context API

React.StrictMode 严格模式组件下，我们处理在 React 17 上的警告，在未来将帮助我们在 v5 丝滑过渡升级 React 18

CSS IN JS

从 2017 年起，CSS 在 JS 中的流行度只增不减！工具众多，随着现代组件驱动的前端框架的出现，样式表驱动样式（无论是 .scss、.less、.css 还是其他样式语言）的主要改进是提高模块化、减少 I/O、简化类名/样式的重复数据删除，提高可读性，和或以其他方式简化 UI 开发。

为什么在我的 JS 中使用 CSS？

使用 CSSINJS 工具能更方便的利用工具支持周边生态，如 nextjs，虽然目前的方式也很好，我们通过 next-remove-imports 剔除包中引入的 css 文件，通过手动引入打包好的 CSS 文件，来解决这一问题，但是这将引发新的主题切换问题，样式打包引入顺序问题，服务端渲染，等一系列问题，现在想通过选型一个 CSSINJS 工具来解决这一系列问题。

  • 开放支持 CSS 变量切换主题（包括明暗主题），dark-mode 工具类似的支持。
  • 支持 className 样式名，用于冲样式（希望能继承现有的命名）。

Web Component

对部分没有任何依赖的组件，可能会重新封装成 Web Component，我们在 dark-mode 中进行尝试。对于一些没有第三方依赖的组件，独立出去使用单独的仓库进行维护，如 Layout、Split 组件。

我们在部分组件开始使用 web component 慢慢替换，例如 react-github-corners，它支持 react 和 web component 两种方式使用，后面大部分组件都会支持这两种方式使用。对于组件库我们需要一些提升生产力的工具，例如 Lit或者更像 react 的 Stencil 使用它们封装 web components 组件变得更简单。

在选择工具的时候，我们需要满足几个目标：

  1. 拥有足够小的体积。
  2. 尽量不需要编译工具参与。
  3. 对生态有支持，如 ssr。
  4. 更加接近原生 web component 特点。

目前看到 tonic 恰好满足我们的需求，根据我们造轮子的能力， 三百来行代码完全没有压力。

经过一些尝试，还没有找到针对 web components 更为舒服的操作

  1. dark-mode 封装对明暗主题操作的，已经应用起来，存在变量声明冲突问题，如果你使用 <script type="module" /> 去加载这个组建，规避冲突问题，又引发了新的问题，切换到暗主题，刷页面页面会出现 先 亮 主题到 暗 主题的闪屏切换过程。
  2. markdown-style 封装了一个 markdown 样式的 web components 组件，试图利用 web components 特性，将 css 集成到组件中，不受样式冲突，避免全局样式污染，结果 markdown 的锚点定位页面位置功能又失效了。使用 web components 的插槽 <slot> 来解决这个问题，将样式生成到 <head> 中，😮‍💨 这样，就这样吧，感觉白折腾了了一通儿，还不如直接引入 css 更加直观。
  3. github-corners 继续尝试，寻求支持 react/web components 两个同时支持的方案，对 style 属性的操作同样存在冲突的问题。

在原生 web components 封装进行尝试，仍然没有找到非常舒服，没有烦恼的操作，后面有机会针对 tonic 和 Lit 等工具的尝试。

vs Ant Design

在很早 2017年 就有人提出了这个问题 #5，但是好像忘记了回答。

最早我们使用 antd 开发我们的中台系统，部分组件我们自己基于 react 16 封装，我们不想改自己的组件，降级支持 react 15，我们采取的方案是将报错的组件重新封装（我们使用得不复杂），在 antd 支持 react 16 之际，我们再切换回去。

在一点一点的积累过程中发现回不去了，我们新增了 antd 没有的组件和 api，还有一些想法。现在你们应该能看出一些区别吧。

uiw 只是 react 众多生态其中之一的组件库，如果你有不喜欢 uiw 的某些组件，你可以单独安装某一个组件使用，如果你看者它就烦，这里awesome-uikit搜集了很多 ui 组件库供你们选择。

重新造一个轮子？

我们一开始就不是为了重新造一个轮子，是为了解决一些项目中的问题，实践和实现一些想法，例如：我们不想安装所有 antd 组件，只想使用其中一个组件，我们想更改某个组件的需求等等。所以，uiw 不光是我们自己的组件库，同时它也是实践我们自己想法的一个项目。 :)