Archives for : 前端

第1111天:react mobx 监听数组变化的两个注意点

mobx 监听数组变化,有时可以,有时不行,今天才看出名堂,迟钝。

1. 用 splice 改变数组,mobx 可以直接刷新数据,比如:

myList.splice(index, 1, newItem)

2. 这点很重要。如果要把列表项作为 react 组件,需要把整个列表作为一个组件,而不是把一个 item 作为组件。

以上两点,第 2 点尤其要注意。

小程序 web-view 内嵌的 h5 调用微信头像和昵称

连踩了好几个大坑,太深,记录一下。

小程序端 (wepy)

const userInfo = this.$parent.globalData.userInfo
// 参数值需要用 encodeURIComponent 进行编码
const nickName = encodeURIComponent(userInfo.nickName)
const avatarUrl = encodeURIComponent(userInfo.avatarUrl)
// 不能使用 # 字符拼接参数,在真机微信上会报错,推荐使用 ?...&...
this.src = `result?nickName=${nickName}&avatarUrl=${avatarUrl}`

h5 端 (vue)

const paramStr = window.location.href.split('?nickName=')[1]
if (paramStr) {
  const param = paramStr.split('&avatarUrl=')
  // 使用 decodeURIComponent 解码
  this.nickName = decodeURIComponent(param[0])
  this.avatarUrl = decodeURIComponent(param[1])
}

最后,使用 <img/> 在真机预览时显示不了图像,就算调用同域名下的远程图像也显示不了,正确的姿势是使用 background .

PS:用 vue + wepy 开发小程序很完美。

next.js 的一些坑

971bf7f8-9ac0-11e6-975c-188defd82df1

这阵子在折腾 next.js,用来做 node 服务端渲染真心不错,然而一路捣腾下来,坑也是不少,有四个比较大的坑。

  1. isomorphic-fetch(解决)
  2. node 端代码打包(未解决)
  3. js 放到 cdn 或者 oss(解决)
  4. static 目录下的图片 hash(临时方案)

这四个坑,1 和 3 是必须解决的,2 和 4 可选。

1

fetch 本来不是什么问题,但是涉及到请求签名,就来了点麻烦,需要区分是服务端还是客户端,客户端用 cookie 存储 token,服务端用变量。

2

node 代码其实不需要打包,因为是运行在服务端,不过为了节省 docker 镜像的大小,尝试了打包,主要是想把 node_modules 也打包进去。先是用 webpack,能打包成功,但是运行失败。后面又用 rollup,同样是打包成功,运行失败。可能是因为 nextjs 本身就包含了 webpack,而用打包工具来打包自己,估计 webpack 和 rollup 都没有想过会有这样的场景出现。于是放弃。

3

这个比较坑,所以重点说一下。

nextjs 提供了 assetPrefix 参数,但是这个参数基本没什么用。需要解决两个问题,一是打包目录要把 hash 带进去,把原来的 bundles/pages/xxx.js 目录结构改成 [hash]/xxx.js,这一步可以在打包脚本里处理,通过 BUILD_ID 和 build-stats.json 拿到 hash,直接上代码:

rm -r -f build
mkdir build

# move pages
buildId=$(cat _next/BUILD_ID)
mkdir build/${buildId}
mv _next/bundles/pages/* build/${buildId}
rm -r _next/bundles

# move app.js
appHash=$(cat _next/build-stats.json)
appHash=${appHash#*hash\":\"}
appHash=${appHash%\"*}
mv _next/app.js build/app.${appHash}.js

其中,_next 是 nextjs 的 distDir,build 是需要上传到 cdn 的目录。

接下来在 server.js 里重写 router,用了 express,参考 https://github.com/zeit/next.js/issues/257

const cdnPrefix = 'https://mycdn.com'

server.use('/_next/**/app.js', (req, res) => {
  const appHash = req.originalUrl.replace('/_next/', '').replace('/app.js', '')
  const newUrl = `${cdnPrefix}/build/app.${appHash}.js`
  res.redirect(newUrl)
})

server.use('/_next/**/page/**', (req, res) => {
  const buildHash = req.originalUrl.replace('/_next/', '').replace(/\/page\/.*/, '')
  const pageName = req.originalUrl.replace(/.*page\//, '') || 'index'
  const newUrl = `${cdnPrefix}/build/${buildHash}/${pageName}.js`
  res.redirect(newUrl)
})

4

static 目录下的图片 hash,这个问题也比较次要,暂时可以通过 githooks 来处理图片修改的问题,对于图片只允许增量提交。

.git/hooks/pre-commit

#!/bin/sh
STAGED_IMAGES=$(git diff --cached --name-only --diff-filter=M | grep -E ".(jpg|jpeg|png|gif)$")

if [[ $STAGED_IMAGES ]]; then
  echo $STAGED_IMAGES
  exit 1
fi

还有一些小坑,比如 process.env.NODE_ENV 的问题(如果有三种以上的环境),比如 scss 里面因不同环境插入不同 cdn 地址图片的问题,等等,就不列了。

生产项目:https://www.isspu.com

webpack 的 DllPlugin 很厉害

webpack.dllplugin.powerful

我们的打包机比较烂,所以想尽办法优化打包速度,这次使用了 DllPluginhappypack 进行优化(主要的功臣是 DllPlugin),速度明显提升,效果显著。

生产环境

  • 优化前 ≈ 125 秒
  • 优化后 ≈ 55 秒
  • 提升 ≈ 56%

大约是 DllPlugin 减了 50 秒,happypack 减了 20 秒。

开发环境

  • 优化前 ≈ 40 秒
  • 优化后 ≈ 15 秒
  • 提升 ≈ 62.5%
  • 热构建从 4 秒缩短到 2 秒

小程序审核越来越快了

IMG_4476

(图:等待审核只用了 41 分钟)

回想第一次审核通过,等了三天,春节过后的审核速度一次比一次快,今天又刷新纪录,只用了 41 分钟,不知道是好事还是坏事。往往看起来是个好事的事,不见得就是啥好事。

回归 express

express4-15

用 koa 踩了一些坑后,决定回归 express,等 koa 生态起来以后再用。

再看 express 最近的几次更新,好像今年突然有变勤快的趋势。

Release Change Log

4.15.0 – Release date: 2017-03-01
4.14.1 – Release date: 2017-01-28
4.14.0 – Release date: 2016-06-16

http://expressjs.com/en/changelog/4x.html

如今写本前端书真不容易

WechatIMG30

(图:《Node.js 硬实战》)

新书到手,啪啪啪翻了下,看到一段,说当时写这本书时 grunt 正流行,然后提到了 gulp。心想,如今写本技术书真心不容易,等你写出来的时候,已经过时了,尤其是前端书。

koa2后端项目打包成单个js文件

IMG_0998

(图:这两天爱上拍夜景)

之前发过一篇 node 后端项目文件打包,是用 webpack 把 express 项目打包成单个文件,坑相对少。

最近用 webpack 打包 koa2,踩了两个大坑。

第一坑:不支持 async

koa2 中间件支持三种写法

  • common function
  • async function
  • generatorFunction

可以用 common function 的写法,虽然用不了拉风的 async/await,但好处也有,省去了对 babel 的依赖。

第二坑:any-promise

这个库在打包的时候会报错,看了下它的 package.json,发现 devDependencies 依赖的库并没有 install。然后发现其实并不需要依赖 any-promise,直接用 node 6 及以上的版本就可以了。

编辑文件:

node_modules/koa-compose/index.js

注释掉开头的一行

const Promise = require(‘any-promise’)

填完这两个坑就好办了。

源码:https://github.com/taichenglu/koa-bundle

sublime 文件比对

IMG_1163

(图:Diffy)

之前一直用 sublimerge 这个比对插件,但是最近发现这货居然收费了,从以前的弹出窗口变成了 90 天试用,卖得还不便宜,35 刀。

于是下午找了两款插件配合起来用,效果也还不错。

第一个插件叫 diffy,这货超级简单,甚至可以用简陋来形容。

使用方法:

  1. 开两个窗口
  2. 在任意一个窗口点右键选择 Diffy 的 Compare

但是这样不能同步滚动两个窗口,所以要再装一个插件。

第二个插件叫 syncViewScroll,支持多个窗口同步滚动,但是刚开始用起来会有点不适应,有点小窍门。

比如开 A 和 B 两个窗口,使用方法:

  1. 先在 A 窗口,下拉菜单 -> View -> 勾选 Sync Scroll
  2. 然后在 B 窗口,执行相同操作
  3. 滚动 B 窗口,会同步滚动 A 窗口,但是滚动 A 窗口不会带动 B 窗口
  4. 如果有多个窗口,那就要在最后一个窗口滚动

这两个插件都可以定义快捷键来辅助使用,附上我的快捷键:

// syncViewScroll
{
  "keys": ["super+shift+ctrl+s"],
  "command": "toggle_sync_scroll"
},

// diffy
{
  "keys": ["super+shift+option+d"],
  "command": "diffy"
},

// diffy clear
{
  "keys": ["super+shift+option+c"],
  "command": "diffy", "args": {"action": "clear"}
},

node 后端项目文件打包

IMG_1073

(图:五点不到就天黑了)

node 后端文件理论上不需要打包,但是用了 docker,发现每次创建的镜像都很大。这几天研究了下,使用 webpack,像打包前端代码一样打包后端代码,以便在创建 docker 镜像时过滤 node_modules,使镜像变小,加快 push 速度。

项目地址:https://github.com/taichenglu/docker-node-bundle

参考:https://segmentfault.com/a/1190000006023471