We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
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
自发布 v4 以来，积累了积累了一些问题和想法，希望在 v5 中处理好这些问题，是时候为未来的 v5 版本做一个计划了。这个计划没有明确开发时间，没有确定开发计划之前 v4 将会一直维护，在这里讨论一些 v5 开发的开发计划。
很早有人提出英文文档需求 #75，我们仍然没有计划和实力提供英文文档（因为我们没有这个需求），但是，我们计划提供一个“架子”，供社区自己补充英文文档。
老的版本也有设计，当初没有找到好的展现方式，设计文件丢失。新的 v5 将会使用 Sketch 设计，使用 Measure 将 Sketch 文件生成可预览的 HTML 文件，使用 Github 的 pages 功能进行展示，类似于 @uiw/icons 的图标设计展示。
v4 之前使用了字符串命名图标 API，将所有 svg path 放到 json 文件中，通过字符串匹配，获得 svg 图标的 path 数据，生成图标。虽然体积做到了最小，但是全量引入 svg 的 path 数据，随着图标增加体积一样增大。所以我们对图标生成工具(svgtofont)进行升级，支持将每个图标生成一个单独组件，想使用哪个图标就引入哪个图标的 React 组件。这个特性 @uiw/icons 图标库已经支持了。
@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" />
React 18 正式版已经发布，我们将所有不兼容的组件并一一修复。这在我们 v4.20+ 已经开始处理兼容问题，我们使用 React.StrictMode 严格模式组件，帮助我们处理：
React.StrictMode
React.StrictMode 严格模式组件下，我们处理在 React 17 上的警告，在未来将帮助我们在 v5 丝滑过渡升级 React 18
从 2017 年起，CSS 在 JS 中的流行度只增不减！工具众多，随着现代组件驱动的前端框架的出现，样式表驱动样式（无论是 .scss、.less、.css 还是其他样式语言）的主要改进是提高模块化、减少 I/O、简化类名/样式的重复数据删除，提高可读性，和或以其他方式简化 UI 开发。
.scss
.less
.css
为什么在我的 JS 中使用 CSS？
使用 CSSINJS 工具能更方便的利用工具支持周边生态，如 nextjs，虽然目前的方式也很好，我们通过 next-remove-imports 剔除包中引入的 css 文件，通过手动引入打包好的 CSS 文件，来解决这一问题，但是这将引发新的主题切换问题，样式打包引入顺序问题，服务端渲染，等一系列问题，现在想通过选型一个 CSSINJS 工具来解决这一系列问题。
对部分没有任何依赖的组件，可能会重新封装成 Web Component，我们在 dark-mode 中进行尝试。对于一些没有第三方依赖的组件，独立出去使用单独的仓库进行维护，如 Layout、Split 组件。
我们在部分组件开始使用 web component 慢慢替换，例如 react-github-corners，它支持 react 和 web component 两种方式使用，后面大部分组件都会支持这两种方式使用。对于组件库我们需要一些提升生产力的工具，例如 Lit或者更像 react 的 Stencil 使用它们封装 web components 组件变得更简单。
在选择工具的时候，我们需要满足几个目标：
目前看到 tonic 恰好满足我们的需求，根据我们造轮子的能力， 三百来行代码完全没有压力。
tonic
经过一些尝试，还没有找到针对 web components 更为舒服的操作
dark-mode
<script type="module" />
亮
暗
markdown-style
<slot>
<head>
github-corners
在原生 web components 封装进行尝试，仍然没有找到非常舒服，没有烦恼的操作，后面有机会针对 tonic 和 Lit 等工具的尝试。
在很早 2017年 就有人提出了这个问题 #5，但是好像忘记了回答。
最早我们使用 antd 开发我们的中台系统，部分组件我们自己基于 react 16 封装，我们不想改自己的组件，降级支持 react 15，我们采取的方案是将报错的组件重新封装（我们使用得不复杂），在 antd 支持 react 16 之际，我们再切换回去。
在一点一点的积累过程中发现回不去了，我们新增了 antd 没有的组件和 api，还有一些想法。现在你们应该能看出一些区别吧。
uiw 只是 react 众多生态其中之一的组件库，如果你有不喜欢 uiw 的某些组件，你可以单独安装某一个组件使用，如果你看者它就烦，这里awesome-uikit搜集了很多 ui 组件库供你们选择。
awesome-uikit
我们一开始就不是为了重新造一个轮子，是为了解决一些项目中的问题，实践和实现一些想法，例如：我们不想安装所有 antd 组件，只想使用其中一个组件，我们想更改某个组件的需求等等。所以，uiw 不光是我们自己的组件库，同时它也是实践我们自己想法的一个项目。 :)
The text was updated successfully, but these errors were encountered:
No branches or pull requests
自发布 v4 以来，积累了积累了一些问题和想法，希望在 v5 中处理好这些问题，是时候为未来的 v5 版本做一个计划了。这个计划没有明确开发时间，没有确定开发计划之前 v4 将会一直维护，在这里讨论一些 v5 开发的开发计划。
文档（英文文档）
很早有人提出英文文档需求 #75，我们仍然没有计划和实力提供英文文档（因为我们没有这个需求），但是，我们计划提供一个“架子”，供社区自己补充英文文档。
重新设计所有组件
老的版本也有设计，当初没有找到好的展现方式，设计文件丢失。新的 v5 将会使用 Sketch 设计，使用 Measure 将 Sketch 文件生成可预览的 HTML 文件，使用 Github 的 pages 功能进行展示，类似于 @uiw/icons 的图标设计展示。
升级图标组件
v4 之前使用了字符串命名图标 API，将所有 svg path 放到 json 文件中，通过字符串匹配，获得 svg 图标的 path 数据，生成图标。虽然体积做到了最小，但是全量引入 svg 的 path 数据，随着图标增加体积一样增大。所以我们对图标生成工具(svgtofont)进行升级，支持将每个图标生成一个单独组件，想使用哪个图标就引入哪个图标的 React 组件。这个特性
@uiw/icons图标库已经支持了。在 v5 版本应该使用以下方法，处理组件库中的图标库使用：
React 18
React 18 正式版已经发布，我们将所有不兼容的组件并一一修复。这在我们 v4.20+ 已经开始处理兼容问题，我们使用
React.StrictMode严格模式组件，帮助我们处理：React.StrictMode严格模式组件下，我们处理在 React 17 上的警告，在未来将帮助我们在 v5 丝滑过渡升级 React 18CSS IN JS
从 2017 年起，CSS 在 JS 中的流行度只增不减！工具众多，随着现代组件驱动的前端框架的出现，样式表驱动样式（无论是
.scss、.less、.css还是其他样式语言）的主要改进是提高模块化、减少 I/O、简化类名/样式的重复数据删除，提高可读性，和或以其他方式简化 UI 开发。为什么在我的 JS 中使用 CSS？
使用 CSSINJS 工具能更方便的利用工具支持周边生态，如 nextjs，虽然目前的方式也很好，我们通过 next-remove-imports 剔除包中引入的 css 文件，通过手动引入打包好的 CSS 文件，来解决这一问题，但是这将引发新的主题切换问题，样式打包引入顺序问题，服务端渲染，等一系列问题，现在想通过选型一个 CSSINJS 工具来解决这一系列问题。
Web Component
对部分没有任何依赖的组件，可能会重新封装成 Web Component，我们在 dark-mode 中进行尝试。对于一些没有第三方依赖的组件，独立出去使用单独的仓库进行维护，如 Layout、Split 组件。
我们在部分组件开始使用 web component 慢慢替换，例如 react-github-corners，它支持 react 和 web component 两种方式使用，后面大部分组件都会支持这两种方式使用。对于组件库我们需要一些提升生产力的工具，例如 Lit或者更像 react 的 Stencil 使用它们封装 web components 组件变得更简单。
在选择工具的时候，我们需要满足几个目标：
目前看到
tonic恰好满足我们的需求，根据我们造轮子的能力， 三百来行代码完全没有压力。经过一些尝试，还没有找到针对 web components 更为舒服的操作
dark-mode封装对明暗主题操作的，已经应用起来，存在变量声明冲突问题，如果你使用<script type="module" />去加载这个组建，规避冲突问题，又引发了新的问题，切换到暗主题，刷页面页面会出现 先亮主题到暗主题的闪屏切换过程。markdown-style封装了一个 markdown 样式的 web components 组件，试图利用 web components 特性，将 css 集成到组件中，不受样式冲突，避免全局样式污染，结果 markdown 的锚点定位页面位置功能又失效了。使用 web components 的插槽<slot>来解决这个问题，将样式生成到<head>中，😮💨 这样，就这样吧，感觉白折腾了了一通儿，还不如直接引入 css 更加直观。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 不光是我们自己的组件库，同时它也是实践我们自己想法的一个项目。 :)
The text was updated successfully, but these errors were encountered: