Chameleon

CML，一套代码运行多端，一端所见即多端所见GitHub: https://github.com/didi/chameleon【版本公布】chameleon-tool@1.0.8-alpha.1 反对多页面构建hash、history模式下适配多页面预览页面跳转以及二维码适配本地服务配置反对多页面配置工程化配置适配多页面路由文件反对配置多页面参数【案例/解决方案】web多页面构建demo【官网文档更新】路由配置 路由懒加载配置如何应用动静组件多页面构建【CML2.0】反对typescript ，进度50%【组件扩大】c-design 实现table tag组件

CML，一套代码运行多端，一端所见即多端所见GitHub: https://github.com/didi/chameleon【版本公布】chameleon-tool@1.0.8-alpha.0 公布 反对chameleon-api-miniapp按需加载反对组件动静加载反对路由懒加载根本应用demo参考：https://github.com/chameleon-...【New-Feature】反对web端多页面构建，批改能力点如下： 路由配置反对 web 端多页面配置HtmlWebpackPlugin 适配多页面构建本地开发适配 history 和 hash 路由两种模式预览页面反对 web 端多页面构建调试【小程序端能力加强】chameleon-api-mini chameleon-ui-mini 官网开发进度10%【组件扩大】c-design 实现 radio input-number loading progress 组件【close-issue】内部奉献解决方案

简介Chameleon模板解析引擎承载了模板局部的语法转化、款式适配、事件零碎适配、语法能力扩大和加强，反对CMl和类Vue两套语法，反对多端的模板解析，接下来让咱们来理解下其背地的实现原理吧 作者简介王梦君 滴滴出行资深前端工程师 Chameleon框架外围开发成员 前言Chameleon作为一个优良的跨多端框架，想要实现"跨多端"这个外围指标，除了工程化配置之外，DSL层面对于各个端的转化的能力也是必不可少的，接下来将为大家介绍CML是如何做DSL层面的转化的。 因为这部分只波及到模板局部，也就是template标签中的内容转化，接下来所有提到的DSL都指的是 模板内容 0 DSL转化的指标是？反对两种模板语法，不便小程序和web开发者零老本学习应用一套模板转化出适配多端的代码，一次开发，多端运行反对新端的疾速扩大比方CML的语法 <view c-if="{{true}}">{{message}}<view>要转化成其余端如下语法 比方原生的vue/weex的template模板语法 <div v-if="true">{{message}}<div>原生的小程序端的语法 微信小程序 <view wx:if="{{true}}">{{message}}</view>支付宝小程序 <view a:if="{{true}}">{{message}}</view>百度小程序 <view s:if="true">{{message}}</view>根本的指标是： 1 如何设计实现？整体架构鉴于以上的指标，CML的模板解析的整体架构如下图所示 外围点是利用 babel 转化为 ast 语法树，在对 ast 语法树解析的过程中，对于每个节点通过 tapable 管制该节点的解决形式，比方标签解析、款式语法解析、循环语句、条件语句、原生组件应用、动静组件解析等，达到适配不同端的需要，各端适配相互独立，互不影响，反对疾速适配多端。 目录构造.├── common│ ├── cml-map.js //各端标签替换map│ ├── process-template.js //模板前置解决、后置解决│ └── utils.js //专用函数├── compile-template-cml.js //cml语法解析入口├── compile-template-vue.js //vue语法解析入口├── index.js //入口文件，对vue和cml语法进行辨别└── parser ├── index.js //所有的parser的对立入口 ├── parse-animation-tag.js //解析动画标签 ├── parse-attribute.js //解析标签属性 ├── parse-class.js //解析class，反对动静class ├── parse-condition.js //解析条件语句 ├── parse-directive.js //解析指令语法 ├── parse-event.js //解析事件代理，事件传参等 ├── parse-interation.js //解析循环语句 ├── parse-ref.js //解析ref ├── parse-style.js //解析style节点，反对动静style └── parse-vue2wx.js //解析vue语法所有源码具体参考 ...

CML，一套代码运行多端，一端所见即多端所见GitHub: https://github.com/didi/chameleon最新动态【版本发布】 chameleon-tool@1.0.6-alpha.6 发布 web 端 dev 模式下如何支持跨域构建过程警告信息支持配置是否输出，可以排查重复 npm 包的安装压缩过程删除多余 consolewindows 下 subProject 配置 npmName 的路径适配修复修复项目内安装 cli 通过 npm 脚本构建全局变量校验问题【组件扩展】 c-design 完成 cd-picker cd-icon 组件【规范和建议】 新增 web 端本地开发如何跨域教程，参考优化项目体积优化教程，参考【close-issues】 weex 多 bundle 构建支持 android 和 ios 如何接入 CMl小程序端模板语法问题【外部pr】 text-area 组件 refresh-view 组件 感谢 QwangMobile

Created 2019-4-6 21:57:17 by huqi Updated 2019-4-7 22:54:55 by huqi↑开局一张图，故事全靠编↑CML是啥？变色龙又是啥？自从有小程序以来，小程序的第三方框架便孕育而生，从原始时代的只基于微信小程序多如今多端统一开发框架，可以说前端技术从2018年到2019年又发生了天翻地覆的变化。感觉现在和圈内人吹水，不蹦出几个诸如megalo、Taro、uni-app之类的新词都感觉没法混，哈哈。今天逛掘金的时候，偶然间打开了@Chameleon社区 发布的我们用5分钟写了一个跨多端项目,Chameleon刚刚开源的时候就有关注过，不过一直没有入手，看到开头这个视频教程就有了尝试的冲动(相比某个开源的商业化项目出的教程还需支付一定费用已经很良心了)，三天节假日也已经过去两天了，是该在Copy&Paste一下，不然连这个CP的技能冷却时间会变得更长。一句话介绍CML：cml(Chameleon 变色龙） 作为真正让一套代码运行多端的框架，提供标准的MVVM模式，统一开发各类终端。为什么要入手Chameleon？我觉得Chameleon的思想觉得我们学习，毕竟多端统一对前端来说是个大趋势。五分钟真的能入门吗？答案不肯定的，当然也不是否定的，要根据用户的实际场景实际情况，假如我连前端开发环境都木有，别说入门，就算是装个Cli环境甚至Node环境可能都要花费好几分钟；假如我掌握了一定技巧且有良好的环境，Copy&Paste也轻而易举的事。废话不多说，前提是您至少要用node环境。安装node环境 详见@i5ting 的文章：狼叔：如何正确的学习Node.js全局安装Chameleon构建工具npm i -g chameleon-tool我已安装node@10.14.1、chameleon-tool@0.0.16(展示没看到更新命令，最新0.1.1，并且暂不支持yarn、cnpm等安装方式)创建项目(可选参数:project、page、component)，输入项目名会自动创建项目文件并安装依赖cml init说实话，如果npm不给力，别说5分钟，可能15分钟过去了估计还卡在npm installing… 那就先看看目录结构 ├── chameleon.config.js // 项目的配置文件 ├── dist // 打包产出目录(build之后显示) ├── alipay // 支付宝小程序代码(build之后显示) ├── baidu // 百度小程序代码(build之后显示) ├── wx // 微信小程序代码(build之后显示) ├── mock // 模拟数据目录(目前内置api和template文件夹) ├── node_modules // npm包依赖 ├── package.json // 包文件 ├── npm-shrinkwrap.json // 锁定依赖版本 └── src // 项目源代码 ├── app // app启动入口(包含app.cml) ├── assets // 静态文件夹(包含默认images) ├── components // 组件文件夹(包含默认组件) ├── pages // 页面文件夹(包含默认页面) ├── router.config.json // 路由配置 └── store // 全局状态管理(类似Vuex).cml文件vscode默认是不支持的，不过已经有拓展可以下载如果npm依赖安装不成功，可以手动安装；或者切换成taobao源通过运行help命令查看chameleon的帮助提示cml -h Usage: chameleon [command] [options] Options:-V, –version 输出版本号-h, –help 输出使用信息 Commands:init [options] 初始化变色龙(chameleon)项目的模板dev [options] 启动开发模式build [options] 启动构建模式server [options] 开发环境服务器的工具web [options] Web项目的工具weex [options] Weex项目的工具wx [options] 微信小程序项目的工具baidu [options] 百度小程序项目的工具alipay [options] 支付宝小程序项目的工具运行dev命令启动dev环境，同时浏览器会打开彩蛋cml dev web当然，也许不一定一帆风顺，遇到问题先本地排查，实在解决不了再去chameleon官方仓库翻翻issue，或者直接提出issue。既然是Copy&paste，那就直接把@jalonjs 大佬创建的cml-first-demo直接复制过来，一边看文档一边敲代码，尽走上从入门到放弃的康庄大道！ ...

摘要： 微信小程序开发技巧。作者：coldsnap原文：小程序多端框架全面测评Fundebug经授权转载，版权归原作者所有。最近前端届多端框架频出，相信很多有代码多端运行需求的开发者都会产生一些疑惑：这些框架都有什么优缺点？到底应该用哪个？作为 Taro 开发团队一员，笔者想在本文尽量站在一个客观公正的角度去评价各个框架的选型和优劣。但宥于利益相关，本文的观点很可能是带有偏向性的，大家可以带着批判的眼光去看待，权当抛砖引玉。那么，当我们在讨论多端框架时，我们在谈论什么：多端笔者以为，现在流行的多端框架可以大致分为三类：1. 全包型这类框架最大的特点就是从底层的渲染引擎、布局引擎，到中层的 DSL，再到上层的框架全部由自己开发，代表框架是 Qt 和 Flutter。这类框架优点非常明显：性能（的上限）高；各平台渲染结果一致。缺点也非常明显：需要完全重新学习 DSL（QML/Dart），以及难以适配中国特色的端：小程序。这类框架是最原始也是最纯正的的多端开发框架，由于底层到上层每个环节都掌握在自己手里，也能最大可能地去保证开发和跨端体验一致。但它们的框架研发成本巨大，渲染引擎、布局引擎、DSL、上层框架每个部分都需要大量人力开发维护。2. Web 技术型这类框架把 Web 技术（JavaScript，CSS）带到移动开发中，自研布局引擎处理 CSS，使用 JavaScript 写业务逻辑，使用流行的前端框架作为 DSL，各端分别使用各自的原生组件渲染。代表框架是 React Native 和 Weex，这样做的优点有：开发迅速复用前端生态易于学习上手，不管前端后端移动端，多多少少都会一点 JS、CSS缺点有：交互复杂时难以写出高性能的代码，这类框架的设计就必然导致 JS 和 Native 之间需要通信，类似于手势操作这样频繁地触发通信就很可能使得 UI 无法在 16ms 内及时绘制。React Native 有一些声明式的组件可以避免这个问题，但声明式的写法很难满足复杂交互的需求。由于没有渲染引擎，使用各端的原生组件渲染，相同代码渲染的一致性没有第一种高。3. JavaScript 编译型这类框架就是我们这篇文章的主角们：Taro、WePY 、uni-app 、 mpvue 、 chameleon，它们的原理也都大同小异：先以 JavaScript 作为基础选定一个 DSL 框架，以这个 DSL 框架为标准在各端分别编译为不同的代码，各端分别有一个运行时框架或兼容组件库保证代码正确运行。这类框架最大优点和创造的最大原因就是小程序，因为第一第二种框架其实除了可以跨系统平台之外，也都能编译运行在浏览器中。(Qt 有 Qt for WebAssembly, Flutter 有 Hummingbird，React Native 有 react-native-web, Weex 原生支持)另外一个优点是在移动端一般会编译到 React Native/Weex，所以它们也都拥有 Web 技术型框架的优点。这看起来很美好，但实际上 React Native/Weex 的缺点编译型框架也无法避免。除此之外，编译型框架的抽象也不是免费的：当 bug 出现时，问题的根源可能出在运行时、编译时、组件库以及三者依赖的库等等各个方面。在 Taro 开源的过程中，我们就遇到过 Babel 的 bug，React Native 的 bug，JavaScript 引擎的 bug，当然也少不了 Taro 本身的 bug。相信其它原理相同的框架也无法避免这一问题。但这并不意味着这类为了小程序而设计的多端框架就都不堪大用。首先现在各巨头超级 App 的小程序百花齐放，框架会为了抹平小程序做了许多工作，这些工作在大部分情况下是不需要开发者关心的。其次是许多业务类型并不需要复杂的逻辑和交互，没那么容易触发到框架底层依赖的 bug。那么当你的业务适合选择编译型框架时，在笔者看来首先要考虑的就是选择 DSL 的起点。因为有多端需求业务通常都希望能快速开发，一个能够快速适应团队开发节奏的 DSL 就至关重要。不管是 React 还是 Vue（或者类 Vue）都有它们的优缺点，大家可以根据团队技术栈和偏好自行选择。如果不管什么 DSL 都能接受，那就可以进入下一个环节：生态以下内容均以各框架现在（2019 年 3 月 11 日）已发布稳定版为标准进行讨论。1. 开发工具就开发工具而言 uni-app 应该是一骑绝尘，它的文档内容最为翔实丰富，还自带了 IDE 图形化开发工具，鼠标点点点就能编译测试发布。其它的框架都是使用 CLI 命令行工具，但值得注意的是 chameleon 有独立的语法检查工具，Taro 则单独写了 ESLint 规则和规则集。在语法支持方面，mpvue、uni-app、Taro 、WePY 均支持 TypeScript，四者也都能通过 typing 实现编辑器自动补全。除了 API 补全之外，得益于 TypeScript 对于 JSX 的良好支持，Taro 也能对组件进行自动补全。CSS 方面，所有框架均支持 SASS、LESS、Stylus，Taro 则多一个 CSS Modules 的支持。所以这一轮比拼的结果应该是：uni-app > Taro > chameleon > WePY、mpvue2. 多端支持度只从支持端的数量来看，Taro 和 uni-app 以六端略微领先（移动端、H5、微信小程序、百度小程序、支付宝小程序、头条小程序），chameleon 少了头条小程序紧随其后。但值得一提的是 chameleon 有一套自研多态协议，编写多端代码的体验会好许多，可以说是一个能戳到多端开发痛点的功能。uni-app 则有一套独立的条件编译语法，这套语法能同时作用于 js、样式和模板文件。Taro 可以在业务逻辑中根据环境变量使用条件编译，也可以直接使用条件编译文件（类似 React Native 的方式）。在移动端方面，uni-app 基于 weex 定制了一套 nvue 方案 弥补 weex API 的不足；Taro则是暂时基于 expo 达到同样的效果；chameleon 在移动端则有一套 SDK 配合多端协议与原生语言通信。H5 方面，chameleon 同样是由多态协议实现支持，uni-app 和 Taro 则是都在 H5 实现了一套兼容的组件库和 API。mpvue 和 WePY 都提供了转换各端小程序的功能，但都没有 h5 和移动端的支持。所以最后一轮对比的结果是：chameleon > Taro、uni-app > mpvue > WePY3. 组件库/工具库/demo作为开源时间最长的框架，WePY 不管从 Demo，组件库数量 ，工具库来看都占有一定优势。uni-app 则有自己的插件市场和 UI 库，如果算上收费的框架和插件比起 WePy 也是完全不遑多让的。Taro 也有官方维护的跨端 UI 库 taro-ui ，另外在状态管理工具上也有非常丰富的选择（Redux、MobX、dva），但 demo 的数量不如前两个。但 Taro 有一个转换微信小程序代码为 Taro 代码的工具，可以弥补这一问题。而 mpvue 没有官方维护的 UI 库，chameleon 第三方的 demo 和工具库也还基本没有。所以这轮的排序是：WePY > uni-app 、taro > mpvue > chameleon4. 接入成本接入成本有两个方面：第一是框架接入原有微信小程序生态。由于目前微信小程序已呈一家独大之势，开源的组件和库（例如 wxparse、echart、zan-ui 等）多是基于原生微信小程序框架语法写成的。目前看来 uni-app 、Taro、mpvue 均有文档或 demo 在框架中直接使用原生小程序组件/库，WePY 由于运行机制的问题，很多情况需要小改一下目标库的源码，chameleon 则是提供了一个按步骤大改目标库源码的迁移方式。第二是原有微信小程序项目部分接入框架重构。在这个方面 Taro 在京东购物小程序上进行了大胆的实践，具体可以查看文章《Taro 在京东购物小程序上的实践》。其它框架则没有提到相关内容。而对于两种接入方式 Taro 都提供了 taro convert 功能，既可以将原有微信小程序项目转换为 Taro 多端代码，也可以将微信小程序生态的组件转换为 Taro 组件。所以这轮的排序是：Taro > mpvue 、 uni-app > WePY > chameleon流行度从 GitHub 的 star 来看，mpvue 、Taro、WePY 的差距非常小。从 NPM 和 CNPM 的 CLI 工具下载量来看，是 Taro（3k/week）> mpvue (2k/w) > WePY (1k/w)。但发布时间也刚好反过来。笔者估计三家的流行程度和案例都差不太多。uni-app 则号称有上万案例，但不像其它框架一样有一些大厂应用案例。另外从开发者的数量来看也是 uni-app 领先，它拥有 20+ 个 QQ 交流群（最大人数 2000）。所以从流行程度来看应该是：uni-app > Taro、WePY、mpvue > chameleon5. 开源建设一个开源作品能走多远是由框架维护团队和第三方开发者共同决定的。虽然开源建设不能具体地量化，但依然是衡量一个框架/库生命力的非常重要的标准。从第三方贡献者数量来看，Taro 在这一方面领先，并且 Taro 的一些核心包/功能（MobX、CSS Modules、alias）也是由第三方开发者贡献的。除此之外，腾讯开源的 omi 框架小程序部分也是基于 Taro 完成的。WePY 在腾讯开源计划的加持下在这一方面也有不错的表现；mpvue 由于停滞开发了很久就比较落后了；可能是产品策略的原因，uni-app 在开源建设上并不热心，甚至有些部分代码都没有开源；chameleon 刚刚开源不久，但它的代码和测试用例都非常规范，以后或许会有不错的表现。那么这一轮的对比结果是：Taro > WePY > mpvue > chameleon > uni-app最后补一个总的生态对比图表：未来从各框架已经公布的规划来看：WePY 已经发布了 v2.0.alpha 版本，虽然没有公开的文档可以查阅到 2.0 版本有什么新功能/特性，但据其作者介绍，WePY 2.0 会放大招，是一个「对得起开发者」的版本。笔者也非常期待 2.0 正式发布后 WePY 的表现。mpvue 已经发布了 2.0 的版本，主要是更新了其它端小程序的支持。但从代码提交， issue 的回复/解决率来看，mpvue 要想在未来有作为首先要打消社区对于 mpvue不管不顾不更新的质疑。uni-app 已经在生态上建设得很好了，应该会在此基础之上继续稳步发展。如果 uni-app 能加强开源开放，再加强与大厂的合作，相信未来还能更上一层楼。chameleon 的规划比较宏大，虽然是最后发的框架，但已经在规划或正在实现的功能有：快应用和端拓展协议通用组件库和垂直类组件库面向研发的图形化开发工具面向非研发的图形化页面搭建工具如果 chameleon 把这些功能都做出来的话，再继续完善生态，争取更多第三方开发者，那么在未来 chameleon 将大有可为。Taro 的未来也一样值得憧憬。Taro 即将要发布的 1.3 版本就会支持以下功能：快应用支持Taro Doctor，自动化检查项目配置和代码合法性更多的 JSX 语法支持，1.3 之后限制生产力的语法只有 只能用 map 创造循环组件 一条H5 打包体积大幅精简同时 Taro 也正在对移动端进行大规模重构；开发图形化开发工具；开发组件/物料平台以及图形化页面搭建工具。结语那说了那么多，到底用哪个呢？如果不介意尝鲜和学习 DSL 的话，完全可以尝试 WePY 2.0 和 chameleon ，一个是酝酿了很久的 2.0 全新升级，一个有专门针对多端开发的多态协议。uni-app 和 Taro 相比起来就更像是「水桶型」框架，从工具、UI 库，开发体验、多端支持等各方面来看都没有明显的短板。而 mpvue 由于开发一度停滞，现在看来各个方面都不如在小程序端基于它的 uni-app 。当然，Talk is cheap。如果对这个话题有更多兴趣的同学可以去 GitHub 另行研究，有空看代码，没空看提交：chameleon: https://github.com/didi/chameleonmpvue: https://github.com/Meituan-Dianping/mpvueTaro: https://github.com/NervJS/tarouni-app: https://github.com/dcloudio/uni-appWePY: https://github.com/Tencent/wepy(按字母顺序排序)关于FundebugFundebug专注于JavaScript、微信小程序、微信小游戏、支付宝小程序、React Native、Node.js和Java线上应用实时BUG监控。 自从2016年双十一正式上线，Fundebug累计处理了10亿+错误事件，付费客户有Google、360、金山软件、百姓网等众多品牌企业。欢迎大家免费试用！ ...