对构建可复用WebUI组件的思考

去公司内部的交流活动参数了一个讲“构建可复用的 WebUI 组件模型”的交流，前面对 WebUI 差异性的分析引发了我的一些思考。

与软件（我猜指的是桌面软件）的 UI 实现不同，WebUI 的实现变动大。我会认为，给予了更多我的实现手段。

造成差异的原因:

关于第一点，不同的人，希望看到的界面是不同的，具体来说，界面上的 CSS 不同，图不同， DOM 结构不同。

关于第二点，因为交互的需求不同，同时因为不同的程序员和不同的实现思路，那么写出来的所有代码都可能不同。

我们的目的，是在于包容上面两种差异的情况下，来实现组件的复用。（不过，我没有在 topic 中听到怎么去解决）

提到了几种手段：

这些手段我们都知道，不过，任何一种，至少在现在，我看都不太容易完善地解决以上两种差异产生的问题。

要把界面外观，和交互实现相分离，同时实现复用，我个人认为，必须使两方面在某个点，以约定的规则进行无须沟通的统一。而这个规则的实现，才是我们应该思考的。 任何单方面的去考虑怎么去封装 js 代码，然后让前端开发者去复用，都不可能解决上面所说的差异。

需要同时考虑前端开发者的复用，和前端设计师的复用。而且，这两者复用，还要统一，无须沟通。

一个美丽的远景是：

前端开发写代码时不关心具体的页面是什么样，写出的代码没问题，则界同上的交互没有问题。 设计做页面不关心交互的流程，页面通过规则验证，则可以保证交互实现不会出问题。

无法完美实现的话，我们只是经常考虑在哪些方面妥协。

基于Quartz编写一个可复用的分布式调度任务管理WebUI组件 创业小团队，无论选择任何方案，都优先考虑节省成本。关于分布式定时调度框架，成熟的候选方案有XXL-JOB、Easy Scheduler、Light Task Scheduler和Elastic Job等等，其实这些之前都在生产环境使用过。但是想要搭建高可用的分布式调度平台，这些框架（无论是否去中心化）都需要额外的服务器资源去部署中心调度管理服务实例，甚至有时候还会依赖一些中间件如Zookeeper。
dy-ui组件库之页面部署 vuepress的部署在官方文档中，有涉及，其实并没有很详细。在此，dy-ui-doc项目部署到https:// USERNAME .github.io/ REPO 的详细部署步骤如下：
mPaas组件的安全设计介绍 由于金融行业的特殊性，对安全的要求很高，所以mPaas内很多模块都采用了很多安全策略，包括RPC的加签加密，离线包的签名校验，移动同步的tcp+ssl机制，热修复的加密配置等。本文主要介绍下我对常见mPaas模块的安全设计的理解，方便后续更好的使用。
【转】前端——实用UI组件库 Angular UI 组件 ngx-bootstrap 是一套Bootstrap 组件 官网：https://valor-software.com/ngx-bootstrap/#/ github: https://github.
通过本文，你将学习到 Uber ，Pinterest ，Shopify 和 Airbnb 等知名网站如何利用组件构建统一的UI / UX 设计规范 。