为什么选择mypUI

mypUI 是基于 uniapp/weex 的一套组件库与工具集，可以 高效且规范 地开发出 uniapp 支持的各端应用（APP/各家小程序/H5/快应用）。兼容 nvue 页面和 vue 页面。nvue 页面对应的 app端依托 weex 编译为原生，具备良好的性能与体验。

mypUI 从学习成本、开发经验，以及记忆成本、性能优化、包体积等多方面考虑，不断优化，已经是一个不可多得的优秀框架，绝对能为您带来 稳定、高效、规范 的开发体验。

# 思考

mypUI 从一开始就一直在思考如下几个问题：

主题的支持，以及使用哪些配置可以满足一个恰到好处，不多不少的主题特性？
一个基础的组件，如何做到简单易用，又能够灵活的适配？
UI库往往带有很多组件，如何最大程度的降低学习成本与熟练成本，怎样才能最快上手？
文档的可读性和可理解性，一个细致化的组件开放的属性可能几十个，如何满足新手的可读性与可理解性？
各端的兼容往往会导致各端的差异化适配，而差异化的适配往往会降低开发的效率，如何在保证性能的基础上提高开发的效率？
有很多变量的值，他们可能是计算而得，可能是通过api获取而得，这些值在UI内用到，用户也会经常用到，是不是可以只计算或获取一次？
如何能够让使用者加快开发速度，减少文档依赖，减少记忆成本？
版本的成熟性与稳定性，是不是一直维护？如何兼容版本更新，降低更新成本？
一个组件库最重要的是什么？到底满足什么才能算是一个好的组件库？
如何最大程度的降低包体积？
为什么要用这个库，她能带来什么好处？她的核心竞争力在哪里？

以上的思考，有些是我们开发过程中需要思考的问题，有些是我们在使用第三库时遇到的问题，或者我们在开发库时需要考虑的问题。这些问题得到一个妥善的解决，绝对是一个绝佳的高效工具

下面我们就来回答这些问题，这也是我们推荐您使用 mypUI 的真正原因，也是 mypUI 的真正魅力所在。您也能从 mypUI 的代码与设计中感受到一个真正在代码一线的工作者的经验与哲学。作者经历过 Objective-c swift Python go Javascript 等多语言开发，前后台都有涉及，绝对有信心和能力维护好一套优秀的组件。

# 可配置的主题设计

mypUI 设计规范和技术上支持灵活的样式定制，以满足业务和品牌上多样化的视觉需求，包括但不限于全局样式（主色、圆角、边框）和指定组件的视觉定制。

mypUI 的样式采用了 scss 作为开发语言，并定义了一系列全局的样式变量，您可以根据需求进行相应的调整。

mypUI 的主题设计绝对是经得住推敲与实践的，更是对于app/MP开发过程中不断实践与迭代的结果。

其中包含了主题、文字、边框、圆角、字号、尺寸等多种通用变量，所有的样式变量以及具体的使用说明在这里找到。

如果以上变量不能满足你的定制需求，可以给我们提 issue。

当然，对于您自己添加变量，那也是非常的方便。更多主题配置的内容将在主题配置讲解。

# 快捷配置与灵活订制

mypUI 中的组件几乎开放了所有的可配置项，在满足主题配置的同时，也支持个性化的适配。可以说是精简但功能绝对齐全。

比如 myp-button 组件，可以通过 bgType border radius icon text height 快速实现样式与主题配置。非常方便快捷，也很容易上手。

如果在这些配置的基础上，还不能满足一些特殊的要求，您可以设置各种 style 来满足您的要求，比如 textStyle boxStyle iconStyle 等。

mypUI 组件既能满足一键式的快捷配置，也能满足几乎所有元素的细节配置，而且我们绝对不会携带任何多余的设置。

<myp-button icon="plus" text="左侧带图标"></myp-button>
<myp-button :loading="loadingVisible" bgType="success" icon="wechat" text="点击切换加载状态" @buttonClicked="toggleLoading"></myp-button>
<myp-button icon="circle-wechat" :text="null" radius="ll" iconType="success" iconStyle="font-size: 100rpx;" boxStyle="height: 100rpx;width: 100rpx;" border="none"></myp-button>

具体细节查看各个组件的文档以及主题设计的规范。

# 语义化与统一规范

如何快速上手？如何降低学习成本？如何了解一个就是了解全部？如何减轻记忆压力，放下文档依赖？

这一切都离不开 语义化的字段设计 与 统一规范的字段设计。

mypUI 中组件的props都采用了规范与统一的命名规则。xx xxType xxSize xxStyle，你只需要知道一次，就能知道所有，并且随时都知道，因为没有模糊的设置，而且大家都彼此规则一样。

这些规范涉及到了：

props的命名规范与统一，各种命名后缀都有特定的含义；
响应事件的规范：buttonClicked cellClicked ... 都是无需记忆的事件名字；

myp-button中背景主题色叫做 bgType，myp-cell中背景主题色也是bgType。你只需要了解了这其中的设计规范与规则，开发起来就会事半功倍。

具体字段的设计规范，请查阅设计规范。

# 文档分层，一目了然

写文档是个技术活，看文档也是个难题。很多有用的东西，因为文档不全，或者文档可读性太差，大大提高了使用者的门槛，以及使用成本。

而文档不分层，大量的props说明堆叠在一起，也难以一目了然，很大程度上增加了内容筛选的难度。

mypUI 组件的文档，分为快捷设置，细节配置，进阶设置等层次。常规属性一目了然。降低阅读难度。

# 抹平差异，减少配置

在兼容各端的过程中，差异化的配置或者适配是不可避免的，但是很多差异是可以通过取舍以及封装抹平的。

很多时候，我们既想要优秀的性能，又想得到高校的开发效率。通过封装来抹平差异以及减少差异化的配置等来提高效率是重中之重。

尤其是在app端的时候，导航栏各种设计，或者是tabbar的各种特效，使用自带的navbar或者tabbar很难满足要求，而个别页面自定义的话，又觉得风格不统一。甚至，pages.json中的各种subnvue的配置实在是不够友好。

这种情况，在快捷开发、便利性、统一性，与小程序端使用原生navbar的性能之间进行取舍。到底如何取舍？

我的选择是去除掉系统自带的navbar和tabbar，去除掉page.json中各种设置，pages.json仅仅只是一个页面注册的地方。简单粗暴，快捷高效，各端开发基本统一，减少差异适配。

当然，这仅仅只是我的选择。你依然有自由选择的权利。我们提供了自定义的navbar与tabbar。您也可以继续使用系统自带的。具体的选择权依然在您自己，与组件库无关，不过我们的demo选择了全部自定义。

我简单说下我的取舍：

失去了什么：小程序端原生navbar比自定义的要好，但是这点性能基本上忽略不计了。因为我们都能够接受小程序端scroll-view自定义的下拉刷新。而在nvue-app，就更不要考虑这个性能的问题了，不过自定义的navbar会存在渲染上快慢的差异。
得到了什么：统一的开发方式，高效便捷，好维护。而且可实现全屏弹层，并且可以非常灵活的处理navbar层，适应各种设计；

个人觉得，得大于失。在选择面前，我们不可能什么都兼顾，选择合适的就是好的。很多人纠结用这用那，其实在nvue出来之前，自己连vue页面都能够接受，结果nvue出来了，又在为这里那里纠结个不停。实在是得不偿失。赶紧动手，实现为上。去实现，去完成，去努力，去发光发热。

当然，具体是不是使用自带的navbar以及tabbar，要看自带的是不是能够满足您的设计与需求。完全满足的话，自带的总归是有渲染速度上的优势（我想，如果不是有意设计的话，很少有设计能够符合）。

降低开发差异的另外一种方法，就是封装组件。各端使用不同的组件时，将其封装进入一个组件，提供统一的开放接口和属性配置。比如scroll-view与list。

# 复用与缓存，降低成本

在开发的过程中，有些内容是多次需要的，而且很有可能是只需要计算一次的。但是因为某些原因，我们不得不重新获取或者计算。我们应该避免这种重复的行为，一是不太好维护，二是有些接口调用起来比较消耗。

所以，我们把这些内容初始化一次，存放起来，封装一些方法，每次去取现成的就行。

还有就是，在写代码的时候，某个页面或者组件难免会要求多次计算，但是前面的计算也是有效的，这个时候我们可以缓存已经有的计算，新的计算值不断缓存进去就行。没有必要一直从头开始。

就好比，省市区三级一样，没有必要每一次省变了都去后台拉取市的信息，而是先检查缓存，缓存有就用缓存的，缓存没有才去拉取，拉取之后存入缓存。

这是一种习惯，也是一种节约成本的方式。

同时，大量可复用的mixin，也为你提供了极大的便利。

# 性能优化

性能优化，考虑几个方面。大多数的优化，uni已经帮我们做了。我们应该考虑什么？

bingdingX的运用；
减少不必要的UI刷新；
在必要的时候创建实例；
及时销毁不需要的监听等；

# 更新策略与稳定性

mypUI 组件，基础组件已经趋向于稳定，19年双11的时候，mypUI 就已经有了上线市场的能力，后来在内部使用改版多次，甚至还完全重构了一次，现在已经特别成熟了；
我们会加大落地组件（开箱即用组件）的更新力度，满足一些拿来即用的用户需求。实际上，这些本来是没有什么太大的意义的，有一个快速开发的壳子就够了。但是考虑到很多开发者没有设计，没有产品，那就多多益善吧。或许我们会放出很多的页面模板吧；
每一次版本的更新会考虑对上一版的影响，即使有改动，也会列出来哪些地方做出了改动，用户需要升级调整；