Willong's Blog


  • Home

  • About

  • Tags

  • Archives

vue-wechat-title使用注意事项

Posted on 2019-07-24

什么是vue-wechat-title

vue-wechat-title是一个npm包,用来解决SPA项目在微信下(iOS only?)title不会变化的问题。原理是在SPA路由发生变化的时候,动态插入一个iframe去请求favor.ico,然后去修改document.title,而微信在发现有请求的时候,就会刷新页面的title。借助这一特征,vue-wechat-title 做了这么一件事情,也算是解决了大家的一个痛点。但是我在使用的过程中,也遇到了一些问题,所以记录下来。

不能“滥用”

当SPA项目需要使用vue-wechat-title时,正确的使用方法应该是在一个根元素上指定 v-wechat-title=”someThing”,someThing这个地方填写一个computed出来的变量或者其他的响应式数据。而不是在每一个路由Page上都写上一个v-wechat-title。

为什么不能滥用

现在官方文档好像已经写了我上面那样的用法,但是其实我之前有一些项目有“滥用”,但是也没什么问题发生。直到后来:公司有一个App需要嵌套一个SSR的页面,然后我们的SSR在client阶段“滥用”了v-wechat-title,结果造成了页面在刷新的时候,vue执行会有一个报错:TypeError: undefined is not an object (evaluating ‘n._enterCb’),通过接入Safari控制台,观察调用栈发现,是vue-wechat-title调用了插入DOM(iframe)之后发生的,之后尝试去掉所有使用v-wechat-ttile的地方后,问题解决。再之后,改成只使用一个v-wechat-title,也没有问题。

个人猜测,应该是iOS的是webview对多次快速插入这个iframe做了一些限制,导致vue后面的回调异常。

使用Charles进行抓包调试以及注意事项

Posted on 2019-07-09

什么是抓包

抓包,就是对某些设备进行正向代理,借此查看其发出的http/https请求。所抓的包就是http请求。抓包一般用于网络调试,观察程序运行状况等情况。抓包工具有很多,比如fiddler、Charles等等。下面以Charles为例进行介绍。

Charles 的安装与配置

Charles的安装就比较简单了,一直按下一步就行了。需要注意的是配置,依次点击:(菜单栏)Proxy–Proxy Settings – Proxies
设置端口号和勾选Enable transparent HTTP proxying

Charles 的使用

当我们需要对网页或者App进行抓包分析的时候,需要先将手机连接上跟电脑同一个局域网,然后打开手机的网络设置-高级-设置代理,IP填写电脑的IP,端口号填上面设置的端口号,一般是8888。然后在手机上操作,就可以看到http的请求了。但是还是看不到https的,因为https是加密过的请求。那我们要看怎么办呢?就需要安装一个证书才行。

证书安装

点击 Help - SSL Proxying,可以看到有多个选项,我们一般选择第三个,install Charles Root Certification on a mobile device or a remote broswer,表示在移动设备或者浏览器安装Charles根证书。点击之后,会提示访问 chls.pro/ssl,在不同平台下的设备有不同操作。

iOS证书安装

在iOS下,用Safari访问后,会询问是否安装描述文件

选择是,然后打开设置-一般设置-描述文件,选择安装

最后在一般设置-关于本机(拉到最下面)-证书信任设置-选择信任证书就好了

安卓手机证书安装

安卓手机的话比较麻烦一些,同样是访问 shls.pro/ssl,但是需要使用非原厂浏览器访问,要下载到rem格式的证书文件,不能是crt(crt下载下来安装不了),然后在网络设置,高级选项,选择安装证书,然后去到下载rem证书文件的目录下选择rem文件进行安装。

我的是小米手机,有这个限制,不知道其他牌子的是不是也一定要rem文件了。

微信返回Vue SPA不刷新页面的问题记录

Posted on 2019-07-07

问题表现

在微信内,打开SAP的页面SPA-a,从SPA-a打开外部页面B,从B再返回SPA-a的话,SPA-a页面会呈现Vue数据绑定特征失效的症状,比如load完接口,loading窗口不会根据v-show变化而消失,点击路由跳转SPA,页面也没有出现变化,但实际上路由的hash已经变化了,但是页面内容没有跟着变化。

问题分析

本来只是以为是页面loading窗口没有隐藏之类的问题,对loading的值进行核对,观察v-show绑定的值是否有变化,实际上,是有对store里面的loadingSHOW进行赋值的,但template没有变化或者没有进行重新render。

问题总结

浏览器前进/后退缓存

这里提到一个概念,浏览器前进/后退缓存(Backward/Forward Cache, BF Cache),当然也有人叫 disk Cache。
BF Cache 是一种浏览器优化, HTML 标准并未指定其如何进行缓存,因此缓存行为是各浏览器各自实现,所以不尽相同。
由于不是 HTTP 缓存,所以通过头文件缓存设置 no-cache 是无效的。当然也不能以 HTTP 缓存机制来理解 BF Cache。

作者:Sakura同志
链接:https://juejin.im/post/5caf3462e51d456e7e297b9e
来源:掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

形成这样的根本原因是微信对于其内置的浏览器进行的“优化”,在iOS下返回SPA-a的时候,微信不会重新请求任何HTML/JS/CSS静态资源,只会把JS重新执行一遍。

但是按照我的个人理解,JS重新执行一遍,应该也能够形成一样的执行效果才对。实际上的vue整个的生命周期也确实有重新执行,但就是已经失去了双向数据绑定的响应了。

但实际上表现和期望的不一致,可能是我的理解有偏差。

问题调试过程

  1. 尝试一:一开始的思路是着重于在返回SPA-a的时候,尝试去刷新SPA-a。由于sessionStorage会计算路由的历史记录count的计数,以此为判断当count等于1(为什么等于1,有另外原因,不在此细说)的时候,尝试使用location.reload()去刷新页面。
    1. 结果,失败,reaload也没有重新加载页面。
  2. 尝试二:由于SPA-a是之前相同业务的迁移,而之前业务并没有出现过这样的情况。通过对比,猜测是由于之前业务是使用动态引入路由页面的,所以对SPA-a的项目进行了相同改造。
    1. 结果,成功。

结论

  1. 微信会对之前访问过的页面进行 前进/后退缓存(disk cache),返回被缓存的页面不会执行静态资源的请求,只会重新执行JS。
  2. vue SPA在被disk cache之后,返回SPA,不会具备双向绑定的特性。
  3. 第二点可以用异步引入路由组件解决。

Git submodule使用指南

Posted on 2019-06-25

问题场景

相信任何开发,都会遇到一种情况。在做不同的项目,但是又都会使用到一些常用的方法/组件/代码块等等。
作为一个追求优雅的开发人员,肯定不能接受一段代码到处复制粘贴的操作。而且一旦这段代码日后需要更新,到处粘贴的话就需要全局搜索然后含泪修改了。
那么有没有一种办法,能够作为一些公共代码的“栖息地”,可以做到一处编写,到处使用呢?

答案是有的。

寻找工具

经过在知名404网站上一番搜寻,找到了Git内置的一个功能:submodule。

什么是submodule

有种情况我们经常会遇到:某个工作中的项目需要包含并使用另一个项目。 也许是第三方库,或者你独立开发的,用于多个父项目的库。 现在问题来了:你想要把它们当做两个独立的项目,同时又想在一个项目中使用另一个。

Git 通过子模块来解决这个问题。 子模块允许你将一个 Git 仓库作为另一个 Git 仓库的子目录。 它能让你将另一个仓库克隆到自己的项目中,同时还保持提交的独立。


如何使用

添加子模块

1
2
3
4
5
# 直接clone,会在当前目录生成一个someSubmodule目录存放仓库内容
git submodule add https://github.com/chaconinc/someSubmodule

# 指定文件目录
git submodule add https://github.com/chaconinc/someSubmodule src/submodulePath

新增成功之后,运行git status会在父仓库发现增加了2个变化

  1. new file: .gitmodules
  2. new file: someSubmodule(实际上并不是一个file)

展开说说:

  1. 什么是.submodules
    .submodules是记录当前项目的子模块配置的文件,里面保存了项目 URL 与已经拉取的本地目录之间的映射。

  2. 子模块目录
    在新增完子模块之后,执行git status之后,会看到类似下面的信息

    1
    2
    3
    4
    5
    6
    7
    8
    9
    $ git diff --cached someSubmodule
    diff --git a/someSubmodule b/someSubmodule
    # 重点是下面这行的 160000
    new file mode 160000
    index 0000000..c3f01dc
    --- /dev/null
    +++ b/DbConnector
    @@ -0,0 +1 @@
    +Subproject commit c3f01dc8862123d317dd46284b05b6892c7b29bc

虽然someSubmodule是父仓库里面的一个目录,但是Git并不会列出里面所有的变化,而是会当做一个特殊的提交。
PS:160000模式。 这是 Git 中的一种特殊模式,它本质上意味着你是将一次提交记作一项目录记录的,而非将它记录成一个子目录或者一个文件。

clone已经包含子模块的项目

正常clone包含子模块的函数之后,由于.submodule文件的存在someSubmodule已经自动生成。但是里面是空的。还需要执行2个命令。

1
2
3
4
5
6
7
# 用来初始化本地配置文件
git submodule init
# 从该项目中抓取所有数据并检出父项目中列出的合适的提交(指定的提交)。
git submodule update
------------------更好的方式---------------------
# clone 父仓库的时候加上 --recursive,会自动初始化并更新仓库中的每一个子模块
git clone --recursive https://github.com/chaconinc/MainProject

git submodule 工作流

当一个项目里面包含子模块的时候,不仅仅需要对父仓库进行版本管理,子模块目录下也是存在版本的。那在不同的父仓库下面如何进行子模块的版本管理也成为新的问题。

最简单的办法,就是主项目只专注使用子模块的master分支上的版本,而不使用子模块内部的任何分支版本。

操作如下:

1
2
3
cd submodulePath
git fetch
git merge origin/master

此时在主项目就能看到submodule目录已经更新了。
当然这也操作有点不方便,下面是更简便的方法:

1
2
# Git 将会进入子模块然后抓取并更新,默认更新master分支
git submodule update --remote

如果需要更新其他分支的话,需要另外配置。

1
2
# 将git submodule update --remote 的分支设置为stable分支
git config -f .gitmodules submodule.DbConnector.branch stable

注意事项

我个人认为,子模块在使用的过程才是最值得注意的地方,所以也没有跟上面的内容一起作为“增删改查”系列写下去。
“改” 我认为是最重要的一环。其中又可以分为:

  1. 对本地的子模块进行修改
  2. 更新他人修改的子模块内容

对本地的子模块进行修改

上面提到更新子模块的操作

1
git submodule update --remote

但是此时的子模块是出于一个特殊的状态,虽然上游的变化被更新到了本地,但是本地子模块会处于一个游离的HEAD状态。

在HEAD状态下,如果将本地修改的内容进行commit,是不会“附着”到任何分支上的。游离的内容,会在切换分支之后消失。

那怎么操作才是正确的呢?

  1. 先进入子模块,然后检出一个分支。

  2. 再执行commit等本地操作

  3. 执行git submodule update —remote —merge,将上游的变化合并到本地的这个分支上。如果你忘记—rebase或—merge,Git 会将子模块更新为服务器上的状态。并且会将项目重置为一个游离的 HEAD 状态。要弥补这个错误的话,重新执行1和3就可以了。

  4. 如果本地的文件跟上游文件出现冲突,则按照普通解决办法解决了再提交就好了。

  5. 发布改动(推送):在父仓库执行git push时添加--recure-submodule 参数,此参数表示递归子模块,可以设置为2个值“check”和“on-demand”。check会使没推送子模块的父仓库本身推送失败。而on-demand会尝试自动推送子模块后再推送父仓库,如果子模块由于其他原因失败,那么父仓库也会推送失败。

合并子模块的改动

根据Gitbook的描述,这是当同一分支在本地和上游出现了不同分叉,需要进行合并的时候,并且二者不是祖先和后代的关系(或者说不是一条分子上的提交)。

操作方法如下:

  1. 对上游的提交,进行检出分支
  2. 将1检出的分支,合并到本地
  3. 解决冲突
  4. 回到主项目
  5. 检查子模块的记录
  6. 解决子模块冲突
  7. 提交主仓库合并

一些我个人的理解

子模块的使用上面说得可能还是有点比较绕,我个人认为比较合适我们团队的子模块工作流应该比较简单。

  1. 主项目需要在自模块上开发新功能时,需要在主项目内的子模块开新分支,然后进行开发
  2. 子模块的代码需要独立提交,形成commit信息记录在主仓库
  3. 由于主项目最终也是需要进行打包的,所以子模块的版本只要是基于master,就认为是可信的
  4. 最后主项目的整个版本经过验证需要上线后,则将子模块的分支合并到子模块的master分支上,那么下一个进行子模块开发的人,就会包含到最新的代码

参考文档:

  1. Git - 子模块
12

Willong lin

14 posts
14 tags
© 2020 Willong lin
Powered by Hexo
|
Theme — NexT.Gemini v6.0.0