触屏版开发总结

摘要：概述前段时间刚刚完成公司触屏版项目，我觉得很有必要写一篇文章总结下自己的心得和踩过的坑。小结个人觉得整个开发流程就是一体的，没有绝对的前后端分离。细数下开发过程中遇到的坑。最近在看模板，貌似很吊的样子总结学习就是不断踩坑的过程啊

前段时间刚刚完成公司触屏版项目，我觉得很有必要写一篇文章总结下自己的心得和踩过的坑。每次回头看看自己写的代码，都有不一样的体会，不过大致感觉都是惊人的相似：这TM写的是啥？这TM写的又是啥？

Java+Node。尝试了前后端分离，Java端负责业务逻辑处理，提供接口。Node端负责页面渲染、SEO等balabala一堆非业务逻辑，两者通过HTTP接口交互。前后端分离确实带来了好处：

分工明确，不会出现占着茅坑不拉粑粑的情况，一人一个坑蹲着

职能清晰，设计写SASS，前端写JavaScript，后端写Java

提高了代码的复用性，Java端的接口可供多个应用调用

前后端分离只有好处? No! 多了Node，实际上多了层请求，这个过程是需要花费时间的，不过这点性能的损耗同提高维护性来比是微不足道的，咋不纠结这个！真正来说，前后端的过度分离让每个人只关注自己的任务，等到联调的时候会发现出现很多问题，举个几个简单的例子：

一般都是设计跟据视觉稿先编码，做好HTML页面，然后丢给我们前端开发。我套页面的时候，发现有个幻灯片效果，然后去找了个插件xxx.js，大部分的幻灯片插件对HTML结构都是有要求的（你懂的），所以我只好找到设计，让他重新写下这部分结构，设计欣然接收，改了！做着做着又发现某个div的需要fixed布局，又得找设计改SASS，某个div需要添加 overflow:hidden,还是得找设计改，如此反复，设计心里肯定会默念：我去年买了个表！说到这里我不得不说一点了，作为一个合格的设计，在编写HTML时，要根据交互效果编写CSS代码，站在套页面人的角度去编码。也需要将CSS模块化，便于维护啊！当然了，作为一个合格的JSer，也要善于同设计交流，提前沟通，避免出现上述的情况。不沟通的结果就是这样的：

    



$("#btn").click(function(){
    $(".someDiv").css({overfolw : "hidden"}).show();
});

来来来，放学别走！

交互说，点击这里，我需要duang的效果，点击那里我需要duang duang的效果，点那那里，我需要duang duang duang的效果。我一看，希望用尽量少的代码实现，同交互交流希望统一UI，保留一种效果就可以了，交互坚持！交互坚持，交涉无果，不得不多写额外的代码，然并卵！下次需求，又换交互效果！

不同的列表页，有着相同的HTML结构，本次相同代码不写两遍的原则，抽出了结构：

     {{comName}}
    //...

但是后端返回的数据结构一处叫comName，一处叫companyName。问后端，他说数据库就是这样设计的。

个人觉得整个开发流程就是一体的，没有绝对的前后端分离。产品、交互、设计、JSer、后端、库表设计都会对我们的代码产生影响。及时沟通是一方面。处了自己的本职外，也需要了解他人的工作，当你对整个流程都特别熟悉，那就是所谓的架构师了。还在前端摸爬滚打的我，还差得远啊。

Zepto是一个轻量级的针对现代高级浏览器的JavaScript库， 它与jquery有着类似的api。选择Zepto是因为它轻量高效，并且封装好了移动端的touch事件。细数下开发过程中遇到的坑。

直接从官网上下载了Zepto，马上编码

$("#btn").on("tap",function(){
    //todo
});

发现压根不起作用，再到官网上看下，我就呵呵了

看黄色部分，默认只添加了Effects、iOS3和Detect这三个模块，最最重要的Touch模块居然没有！所以大家要下载Zepto还得自己定制模块
Zepto Builder
附上模块说明：

总所周知，默认click事件，会有300ms的延时问题，Zepto的tap事件很好的解决了这个问题。但是也挖了一个大坑。

Zepto的点透应该也是大家比较熟悉的了。当两个层叠加的时候，上层绑定的tap事件触发后会穿透到底层，恰好底层有个a标签，页面就跳转了。为了解决这个问题，我不得不把tap事件换成click事件，由于click事件有延时，还得引入了第三方的类库FastClick。

一个很简单的Tip提示，例如‘操作成功’、‘登录失败’等等简单的提示，Tip在show之前，我会计算让Tip居中显示：

var left = ($(window).width() - $pop.width()) / 2 + $(window).scrollLeft();

然而$pop.width()始终为0，对于不可见元素，获取的宽高度始终为0，但是jQuery就能正常获取到，我又不得不采取如下的处理方式：

var cssShow = {visibility: "hidden", display: "block"};
var cssHide = {visibility: "visible", display: "none"};

$pop.css(cssShow);
var left = ($(window).width() - $pop.width()) / 2 + $(window).scrollLeft();
$pop.css(cssHide);

 $pop.css({
     left: left > 0 ? left : 0
 });

Zepto相对于JQuery来说确实比较轻量，但是成熟度还差得远，当出现点透和计算宽高失效的时候，我对Zepto有点灰心，希望Zepto后续能够及时升级解决这些问题，不然就使用jQuery了，特别是jQuery升级到版本2，也是相当不错的选择。

当页面弹出一个选择框。滑动屏幕，背后的页面跟着滚动，特别是在safari下，那效果太恶心，所以我选择禁用body的滚动。最暴力的解决方式是：

$(document).on("touchmove",function(e){
    e.preventDefault();
});

这样会同时禁用掉弹出层的滚动效果，明显不可取，所以我才用下面的方式：

.alpha {
    height: 100%;
    overflow: hidden;
    position: relative;
}

.alpha body {
    height: 100%;
    overflow: hidden;
}

当遮盖弹出的时候或者隐藏的时候让html切换class alpha
$("html").toggleClass("alpha");

对于PC端，直接这样写，就会有一个向上平滑滚动的效果，然而对于移动端来说，并没有什么卵用：

$("body,html").animate({scrollTop: 0});

还是使用了第三方的插件模式出这个效果的scrollToTop。

前后端分离后，Node端要干的事情太多了，URL重写这个模块是我一个前辈写的，配置放在JSON文件里，就像这样：

{
    "product.detail": {
        "in": {
            "from": "^/chanpin/(.+).html$",
            "to": "/product/$1",
            "last": true
        },
        "out": {
            "from": "^/product/(.+)$",
            "to": "/chanpin/$1.html",
            "last": true
        }
    },    
    "special": {
        "in": {
            "from": "^/special/(.+).html$",
            "to": "/special/$1",
            "last": true
        },
        "out": {
            "from": "^/special/(.+)$",
            "to": "/special/$1.html",
            "last": true
        }
    }
}

就是这货：

我同样采用JSON文件管理所有页面的推广代码，就像这样：

{  
  "catalog": {
    "title": "产品目录–$1",
    "keywords": "产品目录,$1",
    "description": "$1，产品目录。"
  }, 
  "search.product": {
    "title": "产品搜索–$1",
    "keywords": "产品搜索,$1",
    "description": "$1，产品搜索。"
  }  
}

自己编写了个模块，可以指定某个文件下的js文件作为路由，路由代码写起来就像这样的：

module.exports = {
    mapping: "/vo",
    get: {       
        /**
         * 登录
         */
        "/login": function (req, res) {
            res.render("vo/login");
        },
        /**
         * 注册
         */
        "/register": function (req, res) {
            res.render("vo/register");
        }            
    },
    post: {
        /**
         * 登录
         */
        "/login": function (req, res) {
            //todo
        },
        /**
         * 注册
         */
        "/register": function (req, res) {
           //todo
        }        
    }
};

详细使用请看这里Express-Mapping

模板引擎使用的Handlebars。Handlebars的if判断不支持type==="2"这种逻辑判断的，然而我们的数据库里有很多字段是使用数字1,2,3,4来标识不同状态的，碰到这种情况就得在Node端预先处理，这个是很坑爹的！碰到列表展示的嵌套循环更是坑爹了。有时候还得写这种代码：

{{#if a}}
    {{#if b}}
        {{#if c}}
            //todo
        {{/if}}
    {{/if}}
{{/if}}

真实的业务场景更是复杂，额外的处理代码总是会带来维护的负担。最近在看nunjucks模板，貌似很吊的样子！

学习就是不断踩坑的过程啊！