为什么选择nPro #

nPro是基于uniapp/weex的一套组件库与工具集,可以高效且规范地开发出uniapp支持的各端应用(APP/各家小程序/H5/快应用)。所有组件兼容nvue页面和vue页面。

nvue页面对应的app端依托weex编译为原生,具备良好的性能与体验。

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

组件库很多,但是像我们这样经过顶层设计与思考的却少之又少。开发组件容易,但是开发一个顺手而又高质量的组件库却是需要消耗很多的精力和功力的。

nPro从一开始就在考虑如下几个问题:

  • 怎么写出的项目代码易懂且规范;

  • 换人了或者长时间不接触的项目,还能看得懂吗;

  • 团队协作下应该怎样才能更有效率;

  • 在小程序下,怎样才能降低包体积;

  • 如何适应当前流行的换肤、多语言等趋势;

  • 如何快速获取动画能力,nvue下很多css动画实现不了,怎么破;

  • 一个组件,他到底应不应该封装成一个基础组件,他到底是降低了开发成本还是增加了适配成本;

  • 需要哪些样式就能满足大多数应用的样式要求;

  • 怎么样的设计,才能让整体框架的可扩展能力变强;

  • 怎么才能让开发者越用越快,减少文档依赖,减少记忆成本;

  • 各端的兼容往往会导致各端的差异化适配,而差异化的适配往往会降低开发的效率,如何在保证性能的基础上提高开发的效率;

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

下面我们就来回答这些问题,这也是我们推荐您使用nPro的真正原因,也是nPro的真正魅力所在。您也能从nPro的代码与设计中感受到一个真正在代码一线的工作者的经验与哲学。

作者经历过 Objective-c swift Python go Javascript 等多语言开发,前后台都有涉及,绝对有信心和能力维护好一套优秀的组件。

可自定义的主题设计 #

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

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

并且基于这些scss变量,以及应用的布局所需,我们提供了一份能满足大多数应用的基础样式。

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

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

如果您有一些零碎的主题需求,您还可以随意覆盖、增加变量与样式,而且不需要去直接修改我们的代码。

更多主题配置的内容将在 主题配置 讲解。了解主题相关的内容,绝对会让你的开发速度提升几倍。

快捷配置与灵活订制 #

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

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

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

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

语义化与统一规范 #

如何快速上手?如何降低学习成本?如何了解一个就是了解全部?如何减轻记忆压力,放下文档依赖?凭什么团队之间协作成本低?凭什么别人也能看得懂代码?

这一切都离不开 语义化的字段设计统一规范的字段设计 以及 基于主题的设计

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

这些规范涉及到了:

  • props的命名规范与统一,各种命名后缀都有特定的含义;

  • 响应事件的规范:buttonClicked cellClicked ... 都是无需记忆的事件名字;

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

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

如果您规范的使用,而且以nPro的样式为主,那么您的代码将会变得异常清晰易懂,哪怕换个人来接手,也能快速开始。

正是因为nPro的命名规范与统一,给予了快速开发的能力。也正是因为nPro的主题配置,给予了快速定制的能力,以及一键换肤的功能。

抹平差异,减少配置 #

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

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

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

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

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

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

我简单说下我的取舍:

  • 失去了什么:小程序端原生navbar比自定义的要好,但是这点性能基本上忽略不计了。因为我们都能够接受小程序端scroll-view自定义的下拉刷新。而在nvue-app,就更不要考虑这个性能的问题了,不过自定义的navbar会存在渲染上快慢的差异。

  • 得到了什么:统一的开发方式,高效便捷,好维护。而且可实现全屏弹层,并且可以非常灵活的处理navbar层,适应各种设计;

具体选择,根据自己的项目设计需要而定。如果只是小程序,一般会设计的比较规范,这个时候用系统的navbar/tabbar就行。

如果APP,基本上使用自定义navbar的比较多。

在选择面前,我们不可能什么都兼顾,选择合适的就是好的。很多人纠结用这用那,其实在nvue出来之前,自己连vue页面都能够接受,结果nvue出来了,又在为这里那里纠结个不停。

实在是得不偿失。赶紧动手,实现为上。去实现,去完成,去努力,去发光发热。

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

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

复用与缓存,降低成本 #

在开发的过程中,有些内容是多次需要的,而且很有可能是只需要计算一次的。

但是因为某些原因,我们不得不重新获取或者计算。我们应该避免这种重复的行为,一是不太好维护,二是有些接口调用起来比较消耗。

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

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

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

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

性能优化 #

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

  • bingdingX的运用;

  • 减少不必要的UI刷新;

  • 在必要的时候创建实例;

  • 及时销毁不需要的监听等;

  • 提前准备数据;

  • 限制渲染的内容,比如多个tabs下的swiper优化;

优秀的组件库 #

我一直在想,一个优秀的组件库,应该备具哪些特质。我想前面列出的都具备的无疑是一个优秀的库。

综合起来,应该可以总结为几点:

  • 规范;
  • 质量;
  • 可定制;
  • 适配成本低;

规范是高质量、高效率,协作开发的基石。可定制才能适应用户,创造各种可能。适配成本低才是一个基础组件真正应该的样子,不然还不如直接复制粘贴修改一下。

一个组件库应该是经过设计和思考的。开发组件容易,但是开发一个适应于多数人的组件库就需要考虑很多。

一个组件库,最优秀的能力,就是为一切不可能提供了可能,为一切不便利提供了便利。

自由搭配与完全掌控的页面布局,完全便捷的安全区兼容,十分牛逼的全屏遮罩,以及高校便捷的使用,与内部的不断优化。一切的一切,无疑,都在说明一个事实:nPro是一个优秀的库。

核心竞争力 #

  • header-swiper,不仅只是nvue-app端可以使用,在MP/H5端也能使用,而且支持刷新和加载更多。全端仿咸鱼/58成为可能;

  • chat-list,无视图跳动的下拉加载更多;

  • 性能、设计、快捷开发、效率等的多重考虑;

  • 页面管理非常灵活,没有做不到,只有想不到;

  • 体验最好的popup,根据使用环境选择是初始化一次,还是每次都初始化;

  • 支持手势的抽屉;

  • 自定义的swiper以及更多手势组件支持;

  • 最顺手的高度管理与计算,非常灵活的安全区兼容;

  • 作者具备前后端,以及原生app的开发经验。具备 Objc Swift Python Go JS 等语言开发经验。尤其在效率、规范与质量管理上面颇有心得;

  • 减少原生插件的依赖,统一的开发与调试方式,更加便捷;

  • 自由畅想,就等你来;

体验之后,你就会发现:真棒!

选我没错 #

说了这么多,其实就是想告诉你:不要纠结,选我没错!

去用,去实现,去完成!没有那么多的为什么,也没有那么多的纠结。去实现、去完成自己的目标即可。有钱之后想换啥都行。

去用,去实现,去完成!

多谢支持。

强烈建议加入wx与qq群,获取更多nPro的动态与帮助