分类目录归档:solution

基于vue的h5页面在微信中打开后自动播放video视频

目前,PC端移动端都禁止video自动播放,除非和用户发生了页面交互动作,比如click,touchstart等事件,在事件回调中可以调用播放方法。若加了muted属性,则可以自动播放,但是静音不是我们想要的。

PC端可以使用iframe引入视频文件地址进行自动播放,但缺点是外观不可控。

H5页面暂无有效手段。

微信内置浏览器提供了WeixinJSBridge对象,若是服务器端渲染的页面,可以试试该对象初始化成功后的事件回调中播放视频:

document.addEventListener('WeixinJSBridgeReady', () => video.play(), false);

但若是基于Vue.js等前端渲染的页面,上述方法未必有用,但是经测试,发现另外一个取巧的方法:

if (typeof WeixinJSBridge !== 'undefined') {
WeixinJSBridge.invoke('getNetworkType',{},function (e){
// 利用该方法进行自动播放
video.play()
});
}

微信基本是社交传播的主阵地,能解决微信就能解决80%以上的硬需求了。

路由设计范式

常见的路由范式,拿产品product举例:

产品列表页: /product
产品详情页: /product/:id
产品编辑新增: /product/edit/:id? 有id表示编辑,无id表示新增
产品删除: /product/delete/:id

比较简单有效,无多余单词,以上供参考。

相对的根据大功能模块扩展,比如文章模块和商城模块,分别在以上范式基础上,加商定的模块前缀:/article 和 /mall

路由一般情况下应可以逐级追溯:例如 /mall/product/:id/comment

第一级:/mall 商城模块主页
第二级:/mall/product 商城产品列表
第三级: /mall/product/:id 某产品详情
第四级: /mall/product/:id/comment 该产品下的评论列表

以上可以作为设计路由时遵循的思路。

莫名其妙的swigjs错误

场景是这样的,有一个自定义的tag,用到了_ctx.__require,代码片段如下:

var s = (ignore ? '  try {\n' : '') +
    'var _compiler = _ctx.__require("' + normalize + '");' +
    '_output += _compiler(' +
    ((onlyCtx && w) ? w : (!w ? '_ctx' : '_utils.extend({}, _ctx, ' + w + ')')) +
    ');\n' +
    (ignore ? '} catch (e) {}\n' : '');

然后之前使用过设置模板内变量的方法:

swig.setDefaults({
  locals: {
    'xxx': '11'
  }
});

一直相安无事,最近改了逻辑,去掉了setDefaults locals,结果一刷新页面(该页面使用了上述自定义tag),页面就报错:

TypeError: _ctx.__require is not a function

并且只是重启node服务后首次刷新页面才会出现,再次刷新就不会出现这个错误。。。搞得莫名其妙的,再次把locals set一下,就不会出现这种报错。 更奇特的是,locals不能是一个空对象{}, 必须至少有一对key:value。

暂时还不明确具体原因。

express请求流中的错误捕捉处理

nodejs中的错误处理还是比较麻烦的,尤其遇到异步回调之类,多层嵌套,简单的try…catch无法处理。

目前在用expressjs,拿此举例说说怎样实践。
第一种,从一介布衣那儿看到的方法,可行:

const domain = require('domain');
app.use((req, res, next) => {
  const reqDomain = domain.create();
  // next抛出的异常在这里被捕获,触发此事件
  reqDomain.on('error', e => {
    // ... 这里统一处理错误,比如渲染或跳转到404,500页面
  });

  return reqDomain.run(next);
});

通过在route定义之前添加如上的中间件,可以捕捉到大部分的错误。

第二种,上面说到是大部分的错误,因为我碰到了一个没成功捕捉到的,就是使用swig模板渲染时的变量报错。

// 设置模板引擎
app.engine('swig', swig.renderFile);
app.set('view engine', 'swig');
app.set('views', `${__dirname}/views`);
app.set('viewExt', '.swig');
// 在某处渲染输出: 
res.render('template/filepath');
// 如果在filepath.swig文件中有变量报错,则第一种方法不能成功捕捉

这时在stackoverflow找到一个方法,

// 依然按第一种方法写错误捕捉
// 然后在route之后再写个中间件

// 最后的错误处理,比如发生在res.render中的错误
// 由于已经设置了响应,因此只能发送状态码,或跳转
// next不能去除,否则无法获取到错误
app.use((err, req, res, next) => {
  // res.sendStatus(500);
  log.error(err);
  // res.redirect(301, '/'); // 跳转到首页
  next();
});

ok,经过验证,上述方法已经能够处理目前所有遇到的问题。

第三种,为什么会有这一种方法呢,纯属个人思维发散,由于是express内部处理了模板引擎,导致res.render方法不能正常抛出错误被外围捕捉,那么我直接用swig方法渲染文件,并把渲染后的结果通过res.send方法响应是不是可以呢?

// 之前是这样渲染的
res.render('template/filepath');
// 改为
res.send(swig.renderFile('/...这里应该是物理绝对路径.../template/filepath.swig'));

经过上面改造,发现只用第一种方法也可以正常捕捉到错误,说明推论正确。

之所以在第二种还能解决的情况下还在寻找其他方案,是因为第二种的最终错误处理只能响应状态码,而不能再渲染页面了。终究不够完美,方法不够优雅。

像第三种方式,完全可以不必设置express的模板引擎了,用res.send + 模板自身的渲染方法即可,封装为一个方法,方便调用。

git使用rebase模式

一、概念上的用法:

1、同分支拉取使用:

git pull --rebase

2、不同分支衍合:

## local machine
(develop)$: git pull origin develop --rebase

## 切换到 feature 分支,衍合develop分支,如有冲突,解决冲突后continue,再次 commit
(develop)$: git checkout feature/user-extension
(feature/user-extension)$: git rebase develop
(feature/user-extension)$: ## ... 解决冲突
(feature/user-extension)$: git rebase --continue

(feature/user-extension)$: git commit origin feature/user-extension

二、本人实际用法:

同分支进行rebase,不同分支间进行merge。

其中同分支有两种情况:

1、本地分支无任何最新提交,远程有新提交。
执行 git pull 直接拉取即可。

2、本地分支有新提交,远程也有新提交。
执行 git pull –rebase 衍合远程分支。

参考:
http://blog.csdn.net/jackystudio/article/details/12309627
http://git-scm.com/book/zh/v1/Git-分支-分支的衍合
http://blog.isming.me/2014/09/26/git-rebase-merge/

http://blog.yorkxin.org/posts/2011/07/29/git-rebase/
http://hy2014.github.io/2014/07/25/git-rebase/
http://segmentfault.com/q/1010000000181403

git阻止本地有冲突文件时候push

目的是防止新手乱操作,老手误操作。

在每个git项目根目录下有个隐藏文件夹.git, 该文件夹下有个hooks目录,复制hooks目录下的pre-push.smaple并更名为pre-push文件,即 项目根目录/.git/hooks/pre-push 文件,编辑粘贴以下代码:

#!/bin/sh
git diff-tree --no-commit-id --name-only HEAD -z -- |
xargs -0 sh -c '
    for f; do
        if git show :"$f" | grep "< <<<<<< HEAD"; then
            echo "$f has some conflicts,can not push"
            exit 1;
        fi
        if git show :"$f" |grep ">>>>>>>"; then
            echo "$f has some conflicts,can not push"
            exit 1;
        fi
    done
    exit 0;
' -

然后保存即可。

来源于:http://blog.sina.com.cn/s/blog_61d8d9640102vaht.html

Git一种分支策略

小团队适用,仅2个常设分支:
1、master
2、tester

master上是稳定线上版本,之后的新功能开发,功能修改,bug处理等都从master开出分支,然后合并到tester分支上,发布测试。
tester可以随意删除,仅从master分出,随时等待其他开发分支合并进来并上测试环境。

1个临时分支:
release

release分支用于上线前,从master开出,各类通过测试的功能分支,bug修复分支等,合并到release分支,进行上线前预测,当release分支没有发现问题后,合并回master,设置tag,然后上线。上线后可删除release分支。

紧急bug处理,需要修复后立即上线的,流程是:由master开出分支fix-xx-bug,合并到tester测试,无问题后直接合并回master并上线。