1. 第9天的起点从看得懂到写得动的一次转折前端0基础自学小程序开发这个系列从Day1一路磕磕绊绊走到今天说实话前几天的状态一直是看得懂、写不出。随便给我一段WXML代码我能大致说出每个标签是干嘛的app.json里配了什么页面、window设置了什么颜色我也能头头是道讲一阵。但真要让我自己从零写一个页面脑子还是一片空白——不知道从哪一行开始不知道哪些东西需要自己写哪些东西框架已经帮我们准备好了。Day8结束的时候我做了一个最原始的静态页面一个商品展示卡片。所有内容都是写死的图片地址是网络上的一个固定链接商品标题直接写在标签里价格也是纯文本。跑通那一刻确实挺高兴但冷静下来又觉得不对劲这不就是用打字的方式做网页吗真要做一个小程序商品数据应该从后端来、从数据库来用户点了加入购物车页面得有反应轮播图得能自己滑动……这些全都和动态有关。所以今天我给自己定了一个阶段性的小目标把小程序里让页面动起来的机制搞清楚。具体拆成三件事——数据绑定、列表渲染、事件交互。这三件事在Day9这一天花了我几乎所有的学习时间但也是前8天里投入产出比最高的一天。如果说前8天是在认识小程序的零件今天的重点就是把零件接上电看看它们是怎么协同工作的。先说结论小程序这个框架最核心的一句话就是数据驱动页面。页面长什么样不取决于你手写多少标签而取决于JS逻辑层里data中的数据变成了什么样子。你以为你在写页面其实你是在维护一份数据页面只是这份数据的一张快照。这个思维转变是我今天最大的收获也是0基础自学的人最难跨过的一道坎。今天的路径我走得比较笨先是看官方文档再按文档敲一遍示例代码然后自己写一个小功能验证理解是否正确。后面几节我会把学到的核心机制和踩过的坑都记录下来给同样在自学的人一个参考。尤其是如果你也卡在静态页面看得懂、动态交互写不出这个阶段这段记录应该能帮你少走一些弯路。2. 双大括号与setData页面内容跟着数据走的底层逻辑2.1 插值表达式WXML里原来可以算出来小程序页面里WXML标签中任何需要动态的内容靠的都是一对双大括号包裹起来的表达式。比如最基础的一段代码view{{ message }}/view这个{{ message }}会被替换成JS文件里data对象中message的值。我在Day3的时候看到这个语法当时以为它只是模板字符串的替代品把变量替换进去而已。今天深入一测才发现它的作用比我想象的大得多——双大括号里不只是放变量名还可以放简单的表达式view{{ count 1 }}/view view{{ isShow ? 显示 : 隐藏 }}/view view{{ 前缀- name }}/view也就是说WXML具备一定的计算能力你可以在模板层直接做字符串拼接、三元判断、简单的加减运算。但这里有个非常重要的边界它只能做表达式不能写完整的JS语句。比如{{ if (...) }}这种写法是直接报错的一是因为WXML没有这个能力二是模板层本来就不应该承担复杂的逻辑。我第一次看到属性绑定的时候也踩了个小坑。以前写静态页面图片地址都是直接写死成srcxxx但图片地址如果来自数据需要这样写image src{{ imageUrl }} /同样的逻辑也适用于动态切换样式类名view class{{ isActive ? active : normal }}状态/view这一步弄明白之后我才意识到静态页面和动态页面的本质区别根本不在于标签用得多花哨而在于标签的属性和内容有多少是算出来的。写死的叫模板由数据驱动的模板才是页面。2.2 setData唯一的官方数据更新通道如果只在data里定义了变量页面是不会自己变的。我第一次犯的错误特别经典——在JS文件里写this.data.message 新的内容发现页面纹丝不动console里输出data确实改了但页面就像被焊死一样。查了一圈文档才明白小程序逻辑层里的this.data只是数据的存储副本直接改它并不会触发视图更新。正确的做法是用setDataPage({ data: { message: hello }, onLoad() { this.setData({ message: 你好小程序 }) } })只要调用了this.setData框架就会把新数据从逻辑层传递到渲染层然后页面就会重新渲染。这个过程在小程序底层叫逻辑层与渲染层之间的通信。为什么用setData这么讲究因为它不是简简单单赋值而是会做数据比对和差异更新——你改了哪个字段框架就只更新页面上对应的那一小块而不是整个页面全部重画。这也是性能优化的一个基础认知以后写复杂页面时setData的频率和体积都要克制因为每一次setData都是一次跨层的通信开销。2.3 异步陷阱setData之后立刻取值可能拿到旧数据setData还有一个容易踩的异步特性。它调用之后data里的值其实是同步更新的至少在我的实测中this.data.xxx紧接着读已经能读到新值但视图层的更新完成时机是不确定的。所以如果需要在更新完成之后做一些事情setData可以加上第二个参数作为回调this.setData({ message: 新内容 }, () { console.log(视图渲染完成) })这个回调今天是没怎么用到但我记下了这个知识点因为我预期后面做页面跳转、动画、弹窗之类的内容时这个回调会派上用场。0基础自学最大的好处就是可以诚实地承认今天用不到但先留着——这种笔记习惯让我后面翻资料的时候省了很多时间。3. wx:for列表渲染没有它你的页面全是复制粘贴3.1 从复制三遍到循环一次的转变今天最有豁然开朗感觉的是wx:for这个指令。我之前做静态商品卡片的时候一个商品卡片是手写一遍view嵌套两个商品就复制两份如果后端返回了50个商品难道要复制50份代码吗显然不可能。函数的做法是把一段代码重复执行模板层面的对应方案就是列表渲染。wx:for的写法非常直白view wx:for{{ goodsList }} wx:keyid text{{ item.name }}/text text{{ item.price }}/text /view这里goodsList是一个数组框架会自动遍历这个数组每次都把当前这一项赋值给item这个变量名。整个view节点包括它内部的所有子节点都会被当作循环模板根据数组长度重新生成对应数量的内容。我第一次跑通这段代码的时候确实有点激动——一份模板管一堆数据。这感觉就像你原来手动一格格填Excel突然学会了拖拽填充。写代码的性价比一下子就不一样了。3.2 关于index和嵌套循环变量名的讲究循环里除了item还有一个默认的index变量代表当前项在数组中的下标。列表要显示序号时可以直接用view wx:for{{ tasks }} wx:keyindex text第 {{ index }} 项{{ item }}/text /view这里有个细节值得注意当循环嵌套的时候外层和内层都用item和index就会发生变量名覆盖。内层循环拿到的item是内层数组的项外层item在嵌套内部就访问不到了。解决办法是给wx:for加别名用wx:for-item和wx:for-index指定名字view wx:for{{ categories }} wx:for-itemcategory wx:for-indexcIndex text{{ category.name }}/text view wx:for{{ category.goodsList }} wx:for-itemgoods wx:for-indexgIndex text{{ goods.name }}/text /view /view这是我在今天实战时实实在在踩过的坑嵌套循环不指定别名内层一用item外层的字段就全访问不到了页面渲染出来一堆undefined。后来我把wx:for-item和wx:for-index当成嵌套循环的必写配置几乎不再出这类问题。3.3 wx:key到底在干嘛文档里反复强调wx:key很重要但0基础的人真的很难理解它为什么重要。我花了不少时间搜索最终用一句话理解了它wx:key是让框架能够识别同一个元素的身份标识。举个例子一个列表里每条数据都带唯一id。用户删掉了第二条数据剩下的数据顺序重新排列。如果没有wx:key框架可能搞不清楚哪条数据被删了只能把整个列表重新渲染如果有wx:key框架就能精准地知道删除的是哪一项复用剩下的节点。这个差异在列表数据量大、改动频繁的时候非常明显该用而不用轻则性能下降重则引发渲染错乱比如input输入框里的内容串位。wx:key的值通常是数组中每项数据的一个唯一字段名view wx:for{{ goodsList }} wx:keyid{{ item.name }}/view如果数组项是纯字符串、纯数字没有对象字段可选可以用*this作为key值表示这一项本身。但注意我后来被提醒不要用index作为wx:key的值——因为数组一旦发生增删index会变身份标识就失效了起不到应有的作用。这一点我在下面的列表场景里会有更深的体会。4. bindtap与dataset传参点击事件背后的数据通道4.1 给页面绑上耳朵今天的第二个大头是事件交互。静态页面再好看用户点一下没反应那就只是个展示物。小程序里的事件绑定非常直白在WXML里给组件加一个bindtap然后在JS里写对应的处理函数view bindtaphandleTap点击我/viewPage({ handleTap() { console.log(被点击了) } })这里有个思维转换点WXML组件默认是不会接收点击事件的bindtap是给它添加了一个事件监听相当于给组件安了一只耳朵。用户手指点下去、松开的瞬间事件就会冒泡传到逻辑层触发对应的函数。4.2 event对象与currentTarget/target的区别处理函数会收到一个event对象里面装了和这次点击相关的大量信息。最常见的需求是我想知道用户点的是哪一项这就涉及event.currentTarget和event.target这两个容易混淆的属性。我用一个比较粗浅但实用的理解来区分它们target是事件触发的原始节点也就是用户真正手指碰到的那一刻的那个元素。currentTarget是事件绑定所在的节点。如果事件绑在父元素上子元素被点击时target是子元素currentTarget是父元素。在uni-app、原生小程序开发中这两个属性的区分值直接决定了你能不能取到正确的数据。我的建议是在事件绑定的那个节点上取参数优先用event.currentTarget.dataset如果事件是冒泡到父级才处理的就要想清楚你到底想拿哪一层的数据。4.3 dataset从WXML给JS透传参数的轻量通道还有一个绕不开的点就是前端传参里最常见的一种方式——dataset。很多时候循环列表里的每一项都有id用户点击其中一项处理函数怎么知道是哪一个做法是在WXML上挂data-*属性view wx:for{{ goodsList }} wx:keyid>handleItemTap(e) { const id e.currentTarget.dataset.id const index e.currentTarget.dataset.index console.log(点击的商品id是, id, 下标是, index) }>Page({ data: { inputValue: , todos: [] }, onInput(e) { this.setData({ inputValue: e.detail.value }) }, addTodo() { const val this.data.inputValue.trim() if (!val) return this.setData({ todos: [...this.data.todos, { id: Date.now(), text: val, done: false }], inputValue: }) }, toggleTodo(e) { const index e.currentTarget.dataset.index const key todos[${index}].done this.setData({ [key]: !this.data.todos[index].done }) }, deleteTodo(e) { const index e.currentTarget.dataset.index const todos [...this.data.todos] todos.splice(index, 1) this.setData({ todos }) } })对应页面的WXMLview classtodo-container view classinput-bar input value{{ inputValue }} bindinputonInput placeholder输入新的待办 / button bindtapaddTodo添加/button /view view classtodo-list view wx:for{{ todos }} wx:keyid classtodo-item {{ item.done ? done : }} >.todo-item { display: flex; justify-content: space-between; padding: 20rpx; border-bottom: 1px solid #eee; } .todo-item.done .todo-text { text-decoration: line-through; color: #aaa; }5.3 细节一数组更新用展开运算符不要原地改我在deleteTodo里特意写了let todos [...this.data.todos]然后再splice。这看起来比直接this.data.todos.splice()多了一行代码但意义完全不同前者是创建一个新数组交给setData去更新视图后者是直接修改this.data里的数组引用。虽然setData最终也能刷新但直接改内部数据再setData的做法容易让自己逻辑混乱尤其在复杂项目里会埋下难以追踪的bug。使用展开运算符还有一个原因this.data里的数据是框架托管的状态尽量保持不可变更新的习惯——每次生成新的数组再整体setData这样任何时刻的数据变更都可以被追溯。对0基础的人来说先养成这个习惯比以后花大力气排查数据莫名其妙变了要省心得多。5.4 细节二todos[index].done 这种key值可以吗toggleTodo里用了一个比较高级的写法——把key写成todos[0].done这样的字符串。setData允许这种路径形式的key意思是只更新todos数组中第0项对象的done属性。我第一次见这个语法的时候愣了一下真去试了才确认setData会把字符串解析成路径然后精准修改对应位置。这个写法的价值在于不用把整个数组重设一遍更新的目标更明确。对于今天的待办场景todos就几条数据性能差异其实感知不到但理解这个语法之后我对setData按路径更新的能力有了更深的认识。以后如果做列表的单项状态切换、表单字段局部更新这就是很顺手的手法。5.5 细节三catchtap为什么放在删除按钮上还有一个值得展开的细节也是我今天反复测试后彻底记住的。删除按钮和整行的点击事件是怎么区分的如果两者都用bindtap用户点删除按钮时事件会冒泡到父级触发toggleTodo——结果就是点删除的同时那条待办被标记成完成了还要再点一次才删除体验非常分裂。解决办法是用catchtap替代bindtap。两者的区别在于bindtap是监听事件但不管它怎么冒泡catchtap是处理完事件并阻止它继续冒泡。删除按钮上用catchtapdeleteTodo点击删除时deleteTodo执行完事件不会往上冒泡父容器的toggleTodo就不会被触发。这个阻止冒泡的概念来自原生Web开发小程序里同样适用而且非常常用。今天这个小实战等于把事件流的概念也实际操作了一遍。5.6 跑通之后的复盘最爽的那一刻是数据闭环写完代码点进模拟器输入文字、点添加、列表出现新条目再点一下删除线出来再点删除整条消失——整个流程第一次完整跑通的时候我感觉自己突然开窍了。小程序页面不再是一堆写死的模板而是一条看得见的数据流动管道用户在页面的操作通过事件传回逻辑层逻辑层修改data再通过setData把新数据推回渲染层页面自动发生变化。这个闭环说复杂不复杂但对0基础的人来说能亲手把这条链路打通后面的学习进度会快很多。我特意又试了一遍修改todos后不调setData直接看页面变化页面果然纹丝不动。这个对照实验非常重要它让我从知道要用setData升级成理解setData在闭环中的位置。6. 今天踩的三个坑0基础选手几乎都会遇到6.1 坑一input输入框的值不会自己存进data做待办清单时我一开始天真地以为在input里打了字data.inputValue就会自动更新——毕竟页面就是由数据驱动的嘛。结果是完全没有反应。后来才搞清楚input组件只是一个输入控件它产生的文本只是组件内部的UI状态跟逻辑层data没有自动关联。要想同步必须在bindinput事件里手动取e.detail.value再setData。这就是为什么代码里onInput函数是必须的onInput(e) { this.setData({ inputValue: e.detail.value }) }这个手动同步的设计一开始我觉得很啰嗦多写一个函数而已。但后来我想明白了框架不自动同步是为了让你确定哪些数据需要变成全局状态哪些只是临时UI状态。如果每个输入框都自动同步到data业务复杂以后会出现大量的无用setData性能和可维护性都扛不住。6.2 坑二循环里的input内容会串位置这个坑是网上搜索前端口诀时看到的但我今天差点踩上。假如待办列表里每条都内嵌一个input用来编辑内容那么input是复用的——框架会根据数组数据渲染列表但不会强制把input当前显示的内容和data中的字段绑定。你在第一条input里打了字列表重新渲染后文字可能出现在另一条input里。这个现象在Web前端里也是经典坑。解决方案是把输入框内容存到对应数据的字段里并且用wx:key保证每条数据的身份唯一。我的待办清单没有把input放进循环里避开了这个复杂场景但我知道后面做编辑功能时一定会撞上所以今天先把它标记为高风险注意点。6.3 坑三setData一个超大对象页面卡到怀疑人生今天最后我做了一个压力测试用一个for循环生成1000条待办然后一次性setData。结果模拟器明显卡了一下真机如果数据更多会更严重。这给我提了个醒——setData是逻辑层与渲染层之间的高性能通道但不是无限量的。每次setData都有一份完整的数据快照从逻辑层传过去虽然框架做了diff但数据量大时成本依然可观。后续的优化方向我记在笔记里列表用分页加载、长列表用虚拟滚动、频繁变更的字段单独setData而不是整个页面一刀切、多个setData合并成一次。这些现在还用不上但至少让我养成了一个直觉setData要小而精不要大而全。0基础学编程很容易只盯着功能能不能跑忽略性能和工程质量今天这个卡顿测试算是提前给我打了个预防针。6.4 今天的排错方法总结回顾今天踩的坑能用比较短的时间解决很大程度靠的是一个笨办法把问题拆到最小可复现单元。比如发现页面不更新我先打印this.data看到底变了没有——没变就是逻辑层的问题变了但页面不变就要怀疑setData有没有被调用setData也调了但没效果就得去看key写法和路径写法是否正确。这个方法看起来没什么技术含量但对0基础的人来说比瞎猜效率高得多。以后不管遇到什么bug我都建议从数据有没有到setData有没有执行渲染有没有生效这三层去排查八成的问题都能定位。今天学到的所有东西最终都指向同一个核心小程序的页面本质上是数据的投影。你在JS里改数据页面跟着变你在页面上操作数据跟着变。理解了这条双向通道接下来不管是学习云开发、对接后端接口还是写更复杂的组件都会顺很多。Day10的计划我准备开始试试wx.request接口调用让待办清单的数据真正从本地写死变成远程获取。到时候再来记录新的坑。