我的第一个微信小程序–蜂巢账单

说正题之前,想多说点别的。不想看可以直接往下拉,到加粗的地方是正文。

感谢区块链天然追求自由的精神让我萌生了创建一个组织的想法,看到每个区块链项目的网站这么炫酷,我也一拍脑袋就打算学习网页开发,进而了解了前端,然后成为一名合格的前端工程师就变成了我实现最初想法的第一步。虽然我离最终的目标还存在天地之间的距离,但我相信滴水穿石,任何微不足道的积累都有意义。

最近在网上翻实习公司,前两天在知乎上搜知道创宇,发现一位叫余弦的在相关话题中很活跃,点进去仔细看了下,果然是位大牛,是个黑客,大学却并不是计算机专业,自学Flash和编程入了计算机行业,之后便是网页编程,从事了Web安全领域,大学期间提供了不少的解决方案和病毒专杀,大三大四获得学校机房管理权,最后就是两位知道创宇创始人拉他入伙。看到这里,我觉得我真的在眼睁睁看我的大学时光流逝,虽然今天的时代和他那时0几年有很大的不同,但我确实该为大学期间的无作为而反省。

跳过中间余弦大大各种出彩表现,说到今天。后来我关注了他的微信公众号lazy-thought,他已经离开了知道创宇两年多,而他今天在从事的领域是区块链生态安全,链圈很多人都知道的慢雾就是余弦及若干大牛创立的,而我知道慢雾是先于认识他,在链圈当下这种浮躁的大环境下,我一点儿都不看好慢雾,我觉得就是来分羹抢风头的,区块链都还没稳定下来就在考虑安全问题简直就是主次不分。当我看了余弦的好几篇文章之后,我才真正明白他眼光的超前性,而且他是很认真地在做这个事情,当然做这些事情其实报酬也不小,毕竟区块链创业公司都有钱。但我欣赏的并不是他现在和曾经的荣耀,而是他的思想和由此而散发出的气场,不停探索,保持敬畏,持续输出,这种气质你只能从理想主义的人身上看见,永远在改变,而创造世界未来的弄潮手永远都是这样的一批人。

说了这么多并没有特别想表达什么,每当看到这些很厉害的人都会点燃我心中的一把火,就想把想说的写出来,释放和鼓励下懒惰的自己:成功路上没有捷径。

说正题了。—————————————–

小程序的名字叫蜂巢账单,该账单的思想借鉴了区块链的广播特性,拥有账单明细意见这个特性,本质就是账单的每笔明细都需要达到一定的条件才能被视为有效,每位加入当前账单的用户都有权利确认或者拒绝这笔明细,目前我设置的条件为:意见为同意的数量超过当前账单用户总数的一半时,该笔明细状态转为确认。意见为拒绝的数量大于或等于当前账单用户总数的一半时,该笔明细状态转为拒绝,被拒绝的明细的消费额不被计入账单总消费额。如果我加入权重这个功能,就可以使账单从去中心化转型为弱中心化,更贴合实际需求。

账单的组成和普通账单没有多大不同,只是账单不再交由某一个人去负责记录,而是交给代码,用户只需要提交明细即可,之后按照上述的规则去确认明细,明细的状态被定下之后就不会再更改。所以该小程序去掉了记账人,每个人都有权确认明细的真实性。

上面所说的基本已经将该小程序的目标说得很清楚了,所以该APP本来就是一个为特殊情景而开发的作品,应用范围非常狭窄,熟人之间不会用,大规模的场景也不可能用一个小程序。满足的可能只是我个人对区块链美好的想象,最终下场可能只是一个练手作品。

虽说它的结局可能会很凄凉,但作为我的第一个微信小程序,它的意义很重要,为了实现各种功能,我对开发微信小程序有了更多了解,对整个小程序框架和结构有了更深刻的认识,对我的前端开发成长有很大的帮助,另外我也用eggjs作为后端框架来处理前端数据,对后端也有了一点基本认识,开发小程序的各种想法和思路都可以用于今后其他的情况。

接下来说一下整体的结构,上两张图片,感觉更容易说清逻辑。看不清可以右键->查看图像。

先说一下整体数据的结构。JSON保存一个数组,该数组由bill这样的无数个对象组成。除了图片中的说明外,我再解释一些可能存在的疑点。

initTime和initId。因为initTime是不重复的,而又不可能存在同一个用户同时创建两个账单的情况。所以这两个信息用于定位一个账单。

name。账单名可以重复,因为定位账单不是通过账单名。但如果加入了两个账单名相同的账单可能会比较伤脑筋。

util.formatTime(new Date())。new Date()确实可读,但是有点臃肿,用方法将new Date()的内容进行了更改得出的可读性更好。

billHash。sha1加密的内容只要发生一点细微变化,加密出的字符串都会完全不同,因此很适合用来作为判断内容是否变化的标志。所以刷新时先发送本地的billHash到后端,后端判断billHash是否有区别就可以知道客户端这边的信息是不是最新的,不是最新的才发账单信息,而不是每次一刷新后端就直接发一个账单信息过去,这样可以减小后端的压力。

hash。为了防止被怀疑后端篡改账单信息,每一笔被确认的明细都会对自身进行一次sha1加密并将结果保存到明细中。原计划每次被确认后,都通过模版消息发送该hash给该账单的所有用户,存疑的用户可以根据提供的账单结构还原明细信息,从在线工具网站加密进行对比,因为模版消息是即时发送的,代表当时的账单信息,我无法修改这些既定信息,即使后边篡改了也无效,只要数据被改了,hash绝对是不一样的。后来考虑到用户量可能为0,以及需要高于平常人的电脑水平,搁浅了,但是这个属性依旧保留了下来。

 

其次是页面结构。

app加载周期进行登录操作,从成功回调中获得用户code发送到后端获取openid,定义一个数组,通过openid从后端遍历所有账单查找group属性中是否有该openid键名,如果有则存入数组,此处可以用filter方法快速完成。然后下发openid和数组回到前端。前端将openid直接存入全局变量id,将数组与本地缓存的黑名单数组配合进行过滤后得到的数组,存入全局变量bills并备份到本地缓存bills。至此app加载周期结束,其他逻辑处理交给入口页index。

index入口页有两个方向,一是直通bill Tab,一是重定向到share-solve转发处理页。onLoad周期先确定是否有页面参数,如果有判断为通过转发页面进入,将参数存入全局变量share,然后重定向到share-solve,index页销毁,周期结束。如果没有,则为正常进入,获取用户设置查看是否已经获得userInfo scope授权,如果获得,直接调用对应API获取userInfo并存入全局变量userInfo,跳转至bill Tab。如果没有获得,显示一个button用于获取用户授权,余下逻辑与之前相同。

转发处理页面share-solve,需要账单信息即全局变量bills,但会有share-solve页面已经加载完毕而app加载周期还没有取得bills的可能性,因此需要添加一个回调函数。之前保存的share参数为对象,保存了分享的账单的initId和initTime用于定位账单,定位到账单之后,判断该账单的group中是否有当前用户,如果有则提示用户已经加入本账单并跳转至bill Tab,如果没有则发送initId和initTime以及用户信息userInfo和当前时间到后端,后端完成修改后将经修改的当前账单传回,前端将该账单入队到bills数组,然后跳转至bill Tab。

来到bill Tab页。和share-solve页同理,因为bill Tab同样需要全局bills,也会发生share-solve页的情况。所以需要添加一个回调函数。之后将bills存入data,用wx:for把各个账单数据传入bill-intro组件处理,完成bill Tab页面渲染。该页面添加了编辑能力,稍为复杂一些,暂述最关键的逻辑。

bill Tab页其实有一个功能键,可以在非编辑模式下导航到new页面。new页面会读入一串字符,为新账单的名字name,点击确认会向后端发送details为空的账单并将该账单入队到全局bills,给全局billIndex赋值1,之后重定向到bill-detail页。

通过在非编辑模式下点击bill-intro组件也可以进入到bill-detail页。在传递数据给bill-intro组件时,同时也把index传给了bill-intro,而该index实际就是该账单在全局bills中的位置,触发点击事件会将index赋值给全局billIndex,然后导航到bill-detail页。

bill-detail页的核心在于全局billIndex,billIndex会指挥bill-detail渲染某一指定的账单,即把bills[billIndex]传入data进行渲染。用wx:for把该账单明细数据传入bill-single-detail组件处理,完成bill-detail页面关键信息的渲染。另外bill-detail的onShow周期会用API触发刷新,刷新事件函数会向后端获取当前账单信息并更新当前账单信息,触发页面重渲染。

bill-single-detail组件会检查当前用户对本笔明细的意见,然后调整渲染的信息。如果当前用户还没有对本笔明细表态,会提供两个选项,确认或拒绝,两个选项会向后端发送opinion信息和账单定位信息(initId,initTime)以及明细定位信息(master, startTime),然后用API触发刷新,使刷新事件函数运行。点击组件和bill-intro同理,将index赋值给全局detailIndex,进入到detail-opinion页,页面自然会渲染bills[billIndex].details[detailIndex]的用户意见。

bill-detail页有一个功能键可以导航到new-bill-detail页。new-bill-detail页面会读入至少一串字符即明细消费额,还可以选填备注。点击确认会向后端发送一个用户意见均为待确认的detail和当前账单定位信息initId和initTime,然后页面回到bill-detail页。

bill Tab及衍生页面的逻辑大致说清楚了,转到userInfo Tab页。

该页面主要有三个导航。

第一个导航到log页面,log页面负责渲染本地缓存logs,而logs保存的是登录时间的数组。即使用记录页。

第二个导航到忽略组页面,指被用户人为放入黑名单的账单信息会再次显示,并且提供恢复功能,恢复后需要到bill Tab页刷新才能看到账单,因为重新获取整个并过滤bills只存在于app加载周期和bill Tab页的刷新事件函数中,提供bill Tab onShow周期刷新对后端的压力比较大,所以只提供bill Tab手动刷新能力。

第三个导航到关于页面,是该小程序的简单介绍以及免责声明和我的联系方式。

到此我讲完了小程序大概的整个逻辑处理。

虽然是第一次开发小程序,总体而言我觉得我尽力去做了,可惜本身应用面太狭窄,确实是很遗憾的事,这次整个开发过程权当练习和致敬区块链这个如蜂巢一般美妙的设计。再接再厉,回头复习JS和框架知识了。希望暑期的实习能让我快速成长。

用微信扫一扫扫描下方小程序码或者微信搜索“蜂巢账单”,就可以看到我的实物作品啦。

发表评论

电子邮件地址不会被公开。 必填项已用*标注