拍卖源码架构在拍品详情页上的探索

前言

原文地址：github/Nealyang

没有想到之前写的一篇一张页面引起的前端架构思考还收到不少同学关注。的确，正如之前在群里所说，一个系统能有一个非常好的架构设计。但是仅仅对于前端项目页面，其实很难把架构一词搬出来聊个天花乱坠。

但是！好的代码结构的组织的确能够避免一些不必要的采坑。当然，这其中也不乏对前端工程师的工程师素养约束。

一言以蔽之，对于前端项目的架构（代码组织）而言，好，好不到哪里去。但是坏，却可以令人头皮发麻。

当然。。。我还是在尽可能的希望好_{这也是这篇文章的目的所在。<u>此处权且抛个砖，如果你有更好的见解和想法，欢迎随时交流}

拍卖详情页

图上的点我会在下文中挨个介绍

特点

• 稳定性要求极高 （这一点区分手淘和天猫，毕竟拍卖…你品）
• 需要详细的日志打点
• 模块之间的通信非常多（拍品状态、倒计时、出价等）

对于手淘和天猫的商品，一般都是多个人对多个物品。即使出了问题，也不影响购买，大不了问题修复再购买（最坏的情况）。

但是对于拍卖的拍品。对多对一、价高者得的属性。并且具有一定的法律效应。所以稳定性的要求极其之高。同时拍卖又具有非常高时效性要求，所以 apush、轮询啥的都要求实时更新拍品的状态。

综合以上因素的考虑。最终我们没有选择大黄蜂搭建页面的形式构建起详情页。就先走了源码链路的开发。至于后续是否会推进落地，可能还有待商榷。

整体架构

如果你阅读过上一篇文章一张页面引起的前端架构思考，那么可能会对接下来要介绍的目录组织结构比较熟悉。下面简单介绍下改动的部分以及添加的一些东西。

项目级别

目录的职责划分在之前的一篇文章中已经都介绍到了。这里就说下目前的一些改动点：

• 新增 count-dow
• 新增loop
• 移除EVENTS

Count-down 和 loop 都是详情页强相关的，但是由于项目名称为 pm-detail 所以，这里就提到 pages 以外的了。其实提不提的原则很简单。该文件是否可（需）共用

也是秉持着上面的原则，将 EVENTS 文件夹修改到页面容器里面了。毕竟，跨页面的广播需求基本是不存在的。

关于页面容器的介绍，也在之前的一篇《Decorator+TS装饰你的代码》一文中介绍到。这里也不赘述了。

count-down 的简单抽离

倒计时的“递归”交给 RAF 搞定。当然，这里是CountDown上的一个方法。

    /**
     * 开启倒计时
     */
    start() {
   
        let that = this;
        function rafCallback() {
   
            that.time -= new Date().getTime() - that.lastTime;
            that.lastTime = new Date().getTime();
            if (that.time < 0) {
   
                that.time = 0;
            }
            that.updateCallback(that.time);
            that.countDownRaf = window.