跳至主要內容

小程序开发过程中的一些问题及解决方案

init-qy前端开发小程序mpvue大约 5 分钟

前言

最近完成了一个内容分发类的小程序，具体核心功能是提供稿件的编辑，上传，评论等等（公众号 plus）；应用到的框架为 mpvue 和 vant-weapp，框架的选型是我最熟悉的框架，主要原因为项目比较赶，虽然之前研究过 uniapp，毕竟没有用它写过，踩坑也需要时间，所以最终敲定了这个技术框架作为这个小程序的基础。由于这次做的小程序类型之前并没有接触过，但也因此碰到了一些微信不常用组件的问题。

踩坑记录

editor 组件

稿件的编辑是核心功能之一，由于稿件需要同时展示图片及文本，和后端协商后选定了一个最简单的方案，即存储为富文本；小程序端能用 rich-text 组件展示，后台管理端也没有问题，数据库使用 text 存储。后台管理端使用 tinymce 进行富文本编辑，而小程序，我只找到了 editor 组件。

说问题：

  • editor 组件无法上滑，只能使用输入框的光标移动
  • editor 组件在输入到底部时，输入回车，光标会移动到底部不可见，必须输入内容时才会显示
  • editor 组件提供了很多 api，但是很多内容需要自己实现，可以参考这位老哥（富文本编辑器封装open in new window）
  • editor 组件虽然输入功能完善，可以上传图片，修改大小等，功能很全。但是实机体验很差，需要用户的学习成本；组件的 focus 会和自定义按键冲突，键盘会不断唤起。

在这些问题的影响下，最终砍掉了 editor 组件的大部分功能，只保留了最基础的文字编辑功能，更多对样式的编辑留在了 web 后台。这里我有几个改进的想法，具体再看项目后期的需求。

  • 使用 textarea + 图片上传 替换掉 editor 组件，最终合成富文本提交后台。用户可以选择添加段落或图片，操作成本会降低，缺点是无法自定义样式，但同样统一的样式有助于小程序端展示风格的统一。我觉得在没有能力做到和公众号编辑相同的技术力之前，这是最经济的做法。
  • 在编辑时跳转一个只有 editor 组件的页面，去掉其他所有组件，专注于解决键盘的问题。这个方案需要研究，有一定的风险。
  • 可以自己写一个虚拟键盘，将自定义按键做在这个键盘里。这个或许是终极解决方案。（微信官方可以照这个改）
  • 坐等官方改 bug（无限延期）

ios 与安卓实际展现不一样

这个问题由来已久，实际上，微信小程序的创举之一就是双端可以同时运行，在不同机型上有相同的体验（虽然有些特别的机型有特别的 bug，说的就是 iponeX）。但有一说一，是坑就等认，是 bug 就得填。

ios 在 js 中对 new Date()方法格式要求与安卓不同
这个问题是之前的小程序中发现的，这次统一提一下。
一般来说，后台存储的日期格式为yyyy-MM-dd,js 中的new Date()方法可以正确解析这个日期，但是 ios 与众不同,它的 js 只支持解析日期格式yyyy/MM/dd,由于普通安卓手机也支持解析这个格式，所以需要对后台传来的日期字符串做统一处理：

const dateString = "2020-12-14 00:00:00";
const date = new Date(dateString.replace(/-/g, "/"));

感觉麻烦的同学可以要求（威胁）后台做统一的数据处理。。。
一般后台（这里指 Java），可以通过 fastjson 的注解（一个一个加）；或者通过配置统一拦截器对 date 数据格式进行处理（这些配置一般可以使用在 long 转 string 上，因为 js 的 number 类型对 java 的 long 类型有精度缺失）。

ios 的 input 焦点丢失有问题（疑似 bug）
在一般表单设计中，通常涉及 input 和 picker。在 ios 实机体验中，先点击 input 输入框，再点击 picker（原生 picker 或 vant 组件 picker 都一样），键盘无法自动收起。
这里的解决方法是调用一个微信的 apiwx.hideKeyboard()，缺点是开发者工具无法正常显示。

    popup(showPicker) {
      // console.log(this[showPicker])
      // this[showPicker] = true
      // 解决ios键盘不收起的问题,开发者工具时可以注掉
      wx.hideKeyboard({
        complete: res => {
          this[showPicker] = true
        }
      })
    }

ios 中包含 editor 组件的页面中position: fixed;表现与安卓不同
具体信息可以看这个 bug 反馈open in new window
暂时只是体验不好，没有修改。二楼老哥的做法

iOS 的只能获取键盘高度之后手动设置 bottom 距离

可以一试。

思考反思

这次这个项目的规模不算大，共有 25 个页面，其中只有两个页面相似重复（一个 tabbar 页面，一个普通页面，tabbar 页面不好传参）。许多稿件列表页面重用，效果很好。由于项目较赶，没有开发业务组件，一些相似的元素（如列表中的稿件 item）没有重用，修改 ui 需要同步修改，所幸页面不多，能够顾及。
回顾整个开发过程，有几点仍需改进：

  • 需要设计几个常用页面模板（list，detail，info），整理几个常用方法（分页，输入，跳转页面），这样能大大加快开发速率。
  • 使用 ui 组件或许需要自己 fork 一个版本，需要对其进行定制化开发
  • 前后端交互需要文档，不然后期维护非常麻烦
  • 可以根据命名区分模块，方便以后遇到相似业务可以直接迁移模块
  • 学习样式类的模块化开发，方便统一修改
  • 通过 ScreenToGif 软件记录动态效果，方便（水一篇博客）思考反思，学习成长
Copyright © 2024 init-qy