记：开发一个小程序

hnsylitao
1,603 阅读2分钟

最近在搞okr小程序，记录一些碰到的问题。第一次写写的比较烂，勿怪

项目搭建

框架选择 Taro

  • 技术栈尽量相同，在我们的web站点上面也是用 React + mobx + typescript 来完成的
  • 可后续拓展多端方向
yarn global add @tarojs/cli
taro init okr
cd okr
yarn install
yarn dev:weapp

代码编写

我项目中目录结构

├─config                        // Taro config
│  ├─dev.js                     // dev.config
│  ├─index.js                   // index
│  └─prod.js                    // prod.config
├─dist                          // 打包结果
└─src
    ├─assets                    // 资源文件
    ├─business                  // 业务处理层，收集不同store上的方法与数据，提供给containers层进行注入。
    ├─common                    // common
    │  ├─services               // services
    │  ├─decorator              // 装饰器实现
    │  ├─enums                  // 公共枚举
    │  ├─hoc                    // 公共高阶实现
    │  ├─interface              // 公共接口
    │  └─utils                  // 公共方法
    ├─components                // 基础UI组件
    ├─containers                // 业务组件 尽量不要参照复杂业务逻辑处理避免出现问题
    ├─pages                     // 页面
    ├─store                     // store目录
    ├─style                     // 样式、主题、minxins
    └─typings                   // 自定义.d.ts文件

基本上我日常开发经常关注的文件在 pages store common/services containers business

  • pages 页面存放的文件
  • store 统一数据管理
  • services 统一封装处理接口
  • containers 对于有些共有的业务组件 可以放在这里统一管理
  • business 一些不同业务模型的 inject 注意的函数

开发注意

  • 页面传参 由于多端的问题（小程序不会出现），对于传入的参数尽量统一 uriencode uridecode
  • 尽量对于 lodash 这类库组件，需要按需引入，不要把全局全部引入了
  • 对于HTTP 接口尽量统一返回application/json

    由于多端对于request 实现的不同，建议返回统一格式方便出现一些问题

  • 尽量component组件不要写network请求，统一数据都是由外层控制

    小程序的问题，会导致不渲染的component也会执行生命周期的问题

  • 小程序 observer 的组件componentWillReceiveProps props 变化不触发

    github.com/NervJS/taro…

拓展使用

测试发布

测试（小程序）

公众平台 添加体验成员 最多三十个用户（可以发布 test 版本交由测试人员测试）

发布

测试完成后，需要在公众平台提交审核，一般三个工作日就会给到反馈了

注意

微信小程序登录规范调整 地址

大家可以使用一下okr来管理目标2OKR

avatar
文章
阅读
粉丝