betway必威-betway必威官方网站
做最好的网站

必威官方网站:Taro开发微信小程序的初体验,小

使用Taro

跑去官网,按照步骤,copy了demo运行了一下,大致如下:

npm install -g @tarojs/cli
taro init myApp

# H5端运行
$ npm run dev:h5
$ taro build --type h5 --watch

# 微信小程序端运行
$ npm run dev:weapp
$ taro build --type weapp --watch

起步在这里:Get Started,大致这样就可以跑起来了,分别在浏览器和微信开发工具中运行了一下,都可以看到界面输出,感觉还是不错。

Fundebug经授权转载,版权归原作者所有。

Redux是JavaScript 状态容器,提供可预测化的状态管理。一般来说,规模比较大的小程序,页面状态,数据缓存,需要管理的东西太多,这时候引入Redux可以方便的管理这些状态,同一数据,一次请求,应用全局共享。

文档开发还有欠缺

对比了微信小程序官网和Taro的Gitbook文档,大致上很多东西都是一一对应的,基本的许多场景都可以满足,但是也有欠缺。比如:组件中的RichText在Taro中就介绍不足,在Taro中(可能^_^)和微信小程序中分别是这样调用的:

// Taro
<RichText nodes={nodes} onTap={this.tap} />

// 微信小程序
<rich-text nodes="{{nodes}}" bindtap="tap"></rich-text>

文档中缺乏了nodes以及onTap方法的说明,这可能需要开发者自己调试。但实际上我按照微信小程序的方法加上onTap之后,控制台是报方法未定义的错误,而实际上我是有写的。【这点要是在实际开发中可能欲哭无泪,要么就是引入其他的库或者自己手写,无疑会增加开发成本以及风险】。

必威官方网站 1

有人或许想说,我直接在生成的微信小程序代码文件夹(dist)中加上不就可以了,但是你可能不是太好改,因为代码是这样的:

必威官方网站 2

关于Fundebug

Fundebug专注于JavaScript、微信小程序、微信小游戏、支付宝小程序、React Native、Node.js和Java线上应用实时BUG监控。 自从2016年双十一正式上线,Fundebug累计处理了10亿 错误事件,付费客户有Google、360、金山软件、百姓网等众多品牌企业。欢迎大家免费试用!

必威官方网站 3

前言

Non-Reacter的学习成本

如果作为一个'Reacter',那么用Taro来开发项目的话肯定是没什么上手难度的,但是如果是没有写过react项目的,那么可能最开始还是有学习成本。

  • 作者:coldsnap
  • 原文:小程序多端框架全面测评

必威官方网站 4

建议与总结

如果你的项目足够下,并且没有运用到特别复杂的组件,并且有开发多端代码的需要,你可以尝试使用Taro,因为即使你需要的组件没有,也可以在有限的时间内方便地写出来,而且京东商城小程序貌似也是用Taro写的,以后应该会有更多的支持。除此之外,暂时可以先观望观望 O(∩_∩)O哈哈~

那么,当我们在讨论多端框架时,我们在谈论什么:

示例

Taro初体验

去官网,Github了解了一下,Taro是由京东·凹凸实验室团队开发的,在掘金上看到他们的发稿,大致归(tu)纳(cao)如下:

  • 代码组织与语法:微信小程序需要在js/wxss/wxml/json文件中来回切换
  • 命名规范:微信文档中的各种命名规范(驼峰、小写中划线、小写连写),惨不忍睹
  • 开发方式:不能加载npm包,不能使用Sass/less等预处理器以及手动的文件处理

原文在这里:为何我们要用 React 来写小程序 - Taro 诞生记

作为 Taro 开发团队一员,笔者想在本文尽量站在一个客观公正的角度去评价各个框架的选型和优劣。但宥于利益相关,本文的观点很可能是带有偏向性的,大家可以带着批判的眼光去看待,权当抛砖引玉。

为了更方便地使用Redux,Taro提供了与react-redux API 几乎一致的包 @tarojs/redux 来让开发人员获得更加良好的开发体验。

Taro感受

以下是我自己个人的感受,因为还没有在项目中应用,可能有些地方说得不太妥当,还望指出。

最近前端届多端框架频出,相信很多有代码多端运行需求的开发者都会产生一些疑惑:这些框架都有什么优缺点?到底应该用哪个?

import Taro, { Component } from '@tarojs/taro'
import { Provider } from '@tarojs/redux'

import configStore from './store'
import Index from './pages/index'

import './app.scss'

const store = configStore()

class App extends Component {
 ...
 render () {
  return (
   <Provider store={store}>
    <Index />
   </Provider> 
  )
 }
}

一端开发,多端生成

正如Taro自己所说的,只需要写一个版本的代码,就可以编译生成H5、微信小程序以及RN的代码,在效率上确实会有所提升。

未来

从各框架已经公布的规划来看:

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 也正在对移动端进行大规模重构;开发图形化开发工具;开发组件/物料平台以及图形化页面搭建工具。

1. 目录结构

Taro语法

Taro的开发语法遵循React,基本上写过React的都是很好上手。大致是这个样子的:

import Taro, { Component } from '@tarojs/taro'
import Index from './pages/index'

import './app.scss'

class App extends Component {
  // 项目配置
  config = {
    pages: [
      'pages/index/index'
    ],
    window: {
      backgroundTextStyle: 'light',
      navigationBarBackgroundColor: '#fff',
      navigationBarTitleText: 'WeChat',
      navigationBarTextStyle: 'black'
    }
  }

  componentWillMount () {}

  componentDidMount () {}

  componentDidShow () {}

  componentDidHide () {}

  render () {
    return (
      <Index />
    )
  }
}

必威官方网站 5

摘要: 微信小程序开发技巧。

首先在app.js中引入一开始定义好的store,使用@tarojs/redux中提供的Provider组件将前面写好的store接入应用中,这样一来,被Provider包裹的页面都能共享到应用的store

了解Taro

听说Taro是从几个星期前开始的,在一次饭桌上,一个小伙伴说:“Hey, 你听说了Taro么,听说只需要写一套程序就可以生成H5,小程序以及RN的代码模板,并且类似于React的语法。”“哦?还有这么好的事,赶紧研究一下。”

结语

那说了那么多,到底用哪个呢?

如果不介意尝鲜和学习 DSL 的话,完全可以尝试 WePY 2.0 和 chameleon ,一个是酝酿了很久的 2.0 全新升级,一个有专门针对多端开发的多态协议。

uni-appTaro 相比起来就更像是「水桶型」框架,从工具、UI 库,开发体验、多端支持等各方面来看都没有明显的短板。而 mpvue 由于开发一度停滞,现在看来各个方面都不如在小程序端基于它的 uni-app

当然,Talk is cheap。如果对这个话题有更多兴趣的同学可以去 GitHub 另行研究,有空看代码,没空看提交:

  • chameleon:
  • mpvue:
  • Taro:
  • uni-app:
  • WePY:

2. 编写Todos

生态

以下内容均以各框架现在(2019 年 3 月 11 日)已发布稳定版为标准进行讨论。

1. 开发工具

就开发工具而言 uni-app 应该是一骑绝尘,它的文档内容最为翔实丰富,还自带了 IDE 图形化开发工具,鼠标点点点就能编译测试发布。

其它的框架都是使用 CLI 命令行工具,但值得注意的是 chameleon 有独立的语法检查工具,Taro 则单独写了 ESLint 规则和规则集。

在语法支持方面,mpvueuni-appTaroWePY 均支持 TypeScript,四者也都能通过 typing 实现编辑器自动补全。除了 API 补全之外,得益于 TypeScript 对于 JSX 的良好支持,Taro 也能对组件进行自动补全。

CSS 方面,所有框架均支持 SASSLESSStylus,Taro 则多一个 CSS Modules 的支持。

所以这一轮比拼的结果应该是:

uni-app > Taro > chameleon > WePY、mpvue

必威官方网站 6

2. 多端支持度

只从支持端的数量来看,Tarouni-app 以六端略微领先(移动端、H5、微信小程序、百度小程序、支付宝小程序、头条小程序),chameleon 少了头条小程序紧随其后。

但值得一提的是 chameleon 有一套自研多态协议,编写多端代码的体验会好许多,可以说是一个能戳到多端开发痛点的功能。uni-app 则有一套独立的条件编译语法,这套语法能同时作用于 js、样式和模板文件。Taro 可以在业务逻辑中根据环境变量使用条件编译,也可以直接使用条件编译文件(类似 React Native 的方式)。

在移动端方面,uni-app 基于 weex 定制了一套 nvue 方案 弥补 weex API 的不足;Taro则是暂时基于 expo 达到同样的效果;chameleon 在移动端则有一套 SDK 配合多端协议与原生语言通信。

H5 方面,chameleon 同样是由多态协议实现支持,uni-appTaro 则是都在 H5 实现了一套兼容的组件库和 API。

mpvueWePY 都提供了转换各端小程序的功能,但都没有 h5 和移动端的支持。

所以最后一轮对比的结果是:

chameleon > Taro、uni-app > mpvue > WePY

必威官方网站 7

3. 组件库/工具库/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 > chameleon

必威官方网站 8

4. 接入成本

接入成本有两个方面:

第一是框架接入原有微信小程序生态。由于目前微信小程序已呈一家独大之势,开源的组件和库(例如 wxparseechartzan-ui 等)多是基于原生微信小程序框架语法写成的。目前看来 uni-appTarompvue 均有文档或 demo 在框架中直接使用原生小程序组件/库,WePY 由于运行机制的问题,很多情况需要小改一下目标库的源码,chameleon 则是提供了一个按步骤大改目标库源码的迁移方式。

第二是原有微信小程序项目部分接入框架重构。在这个方面 Taro 在京东购物小程序上进行了大胆的实践,具体可以查看文章《Taro 在京东购物小程序上的实践》。其它框架则没有提到相关内容。

而对于两种接入方式 Taro 都提供了 taro convert 功能,既可以将原有微信小程序项目转换为 Taro 多端代码,也可以将微信小程序生态的组件转换为 Taro 组件。

所以这轮的排序是:

Taro > mpvue 、 uni-app > WePY > chameleon

流行度

从 GitHub 的 star 来看,mpvueTaroWePY 的差距非常小。从 NPM 和 CNPM 的 CLI 工具下载量来看,是 Taro> mpvue > WePY 。但发布时间也刚好反过来。笔者估计三家的流行程度和案例都差不太多。

uni-app 则号称有上万案例,但不像其它框架一样有一些大厂应用案例。另外从开发者的数量来看也是 uni-app 领先,它拥有 20 个 QQ 交流群(最大人数 2000)。

所以从流行程度来看应该是:

uni-app > Taro、WePY、mpvue > chameleon

必威官方网站 9

5. 开源建设

一个开源作品能走多远是由框架维护团队和第三方开发者共同决定的。虽然开源建设不能具体地量化,但依然是衡量一个框架/库生命力的非常重要的标准。

从第三方贡献者数量来看,Taro 在这一方面领先,并且 Taro 的一些核心包/功能(MobX、CSS Modules、alias)也是由第三方开发者贡献的。除此之外,腾讯开源的 omi 框架小程序部分也是基于 Taro 完成的。

WePY 在腾讯开源计划的加持下在这一方面也有不错的表现;mpvue 由于停滞开发了很久就比较落后了;可能是产品策略的原因,uni-app 在开源建设上并不热心,甚至有些部分代码都没有开源;chameleon 刚刚开源不久,但它的代码和测试用例都非常规范,以后或许会有不错的表现。

那么这一轮的对比结果是:

Taro > WePY > mpvue > chameleon > uni-app

最后补一个总的生态对比图表:

必威官方网站 10

// src/reducers/index.js

import { combineReducers } from 'redux'
import { ADD, DELETE } from '../constants/todos'

// 定义初始状态
const INITIAL_STATE = {
 todos: [
  {id: 0, text: '第一条todo'}
 ]
}

function todos (state = INITIAL_STATE, action) {
 // 获取当前todos条数,用以id自增
 let todoNum = state.todos.length

 switch (action.type) { 
  // 根据指令处理todos
  case ADD:   
   return {
    ...state,
    todos: state.todos.concat({
     id: todoNum,
     text: action.data
    })
   }
  case DELETE:
   let newTodos = state.todos.filter(item => {
    return item.id !== action.id
   })

   return {
    ...state,
    todos: newTodos
   }
  default:
   return state
 }
}

export default combineReducers({
 todos
})

多端

笔者以为,现在流行的多端框架可以大致分为三类:

1. 全包型

这类框架最大的特点就是从底层的渲染引擎、布局引擎,到中层的 DSL,再到上层的框架全部由自己开发,代表框架是 Qt 和 Flutter。这类框架优点非常明显:性能高;各平台渲染结果一致。缺点也非常明显:需要完全重新学习 DSL,以及难以适配中国特色的端:小程序。

这类框架是最原始也是最纯正的的多端开发框架,由于底层到上层每个环节都掌握在自己手里,也能最大可能地去保证开发和跨端体验一致。但它们的框架研发成本巨大,渲染引擎、布局引擎、DSL、上层框架每个部分都需要大量人力开发维护。

2. Web 技术型

这类框架把 Web 技术(JavaScript,CSS)带到移动开发中,自研布局引擎处理 CSS,使用 JavaScript 写业务逻辑,使用流行的前端框架作为 DSL,各端分别使用各自的原生组件渲染。代表框架是 React Native 和 Weex,这样做的优点有:

  1. 开发迅速
  2. 复用前端生态
  3. 易于学习上手,不管前端后端移动端,多多少少都会一点 JS、CSS

缺点有:

  1. 交互复杂时难以写出高性能的代码,这类框架的设计就必然导致 JSNative 之间需要通信,类似于手势操作这样频繁地触发通信就很可能使得 UI 无法在 16ms 内及时绘制。React Native 有一些声明式的组件可以避免这个问题,但声明式的写法很难满足复杂交互的需求。
  2. 由于没有渲染引擎,使用各端的原生组件渲染,相同代码渲染的一致性没有第一种高。

3. JavaScript 编译型

这类框架就是我们这篇文章的主角们:TaroWePYuni-appmpvuechameleon,它们的原理也都大同小异:先以 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都有它们的优缺点,大家可以根据团队技术栈和偏好自行选择。

如果不管什么 DSL 都能接受,那就可以进入下一个环节:

而Taro也非常友好地为开发者提供了移植的Redux。

$ yarn add redux @tarojs/redux redux-action redux-logger
# 或者使用 npm
$ npm install --save redux @tarojs/redux redux-action redux-logger

本文由betway必威发布于网页设计,转载请注明出处:必威官方网站:Taro开发微信小程序的初体验,小

Ctrl+D 将本页面保存为书签,全面了解最新资讯,方便快捷。