enzyme的三种渲染方式
react测试利器enzyme有三种渲染方式:shallow, mount, render。shallow渲染叫浅渲染,仅仅对当前jsx结构内的顶级组件进行渲染,而不对这些组件的内部子组件进行渲染,因此,它的性能上最快的,大部分情况下,如果不深入组件内部测试,那么可以使用shallow渲染。mount则会进行完整渲染,而且完全依赖DOM API,也就是说mount渲染的结果和浏览器渲染结果说一样的,结合jsdom这个工具,可以对上面提到的有内部子组件实现复杂交互功能的组件进行测试。render也会进行完整渲染,但不依赖DOM API,而是渲染成HTML结构,并利用cheerio实现html节点的选择,它相当于只调用了组件的render方法,得到jsx并转码为html,所以组件的生命周期方法内的逻辑都测试不到,所以render常常只用来测试一些数据(结构)一致性对比的场景。在这里还提到,shallow实际上也测试不到componentDidMount/componentDidUpdate这两个方法内的逻辑。
前端性能优化清单
https://github.com/xitu/gold-miner/blob/master/TODO/front-end-performance-checklist-2018-1.md
https://github.com/xitu/gold-miner/blob/master/TODO/front-end-performance-checklist-2018-2.md
https://github.com/xitu/gold-miner/blob/master/TODO/front-end-performance-checklist-2018-3.md
https://github.com/xitu/gold-miner/blob/master/TODO/front-end-performance-checklist-2018-4.md
前端测试介绍
https://jaxenter.com/testing-frontend-code-introduction-137219.html
https://jaxenter.com/testing-frontend-code-unit-testing-137464.html
https://jaxenter.com/testing-frontend-code-e2e-testing-137642.html
https://jaxenter.com/testing-frontend-code-integration-137885.html
https://jaxenter.com/testing-frontend-code-visual-testing-137981.html
Everything You Need To Know About Shadow DOM
react-router切换页面后跳转到页面顶部
在使用react-router做路由的时候,会发现如果直接使用,当你采用一些特殊的overflow元素时,会发现切换页面后scrollbar在原位不动,这导致一些不好的体验,因为用户切换界面常常是要查看全新的内容。之所以产生这个问题,很大的原因是virtual dom带来的负面影响。virtual dom仅利用数据对要生成的dom结构做diff计算,只更新那些改变了的元素。而react-router带来的结果是,仅route内部组件的部分节点发生了变化。所以,对于有scrollbar的那个元素而言,没有变动,scrollbar的位置也不会改变。
解决的办法是创建一个container组件,在这个组件中去执行dom操作,让scrollbar跳转到顶部去:
import { withRouter } from "react-router-dom";
class ScrollToTop extends Component {
componentDidUpdate(prevProps) {
if (this.props.location.pathname !== prevProps.location.pathname) {
document.getElementById("page").scrollTo(0, 0);
}
}
render() {
return this.props.children;
}
}
const PageContainer = withRouter(ScrollToTop);
// ... 下面是渲染部分 ...
<Router>
<PageContainer>
{/* 你的正常的渲染内容 */}
</PageContainer>
</Router>
解决的方法非常简单,就是在Router下面再放一个根性质的组件,Router会给下面的组件传递location, match等props,所以,可以在这个组件里面进行监听,通过判断来决定是否要执行scrollTo(0, 0)这样的操作。上面红色的部分则是需要自己进行修改,甚至,你可以把这个组件进行丰富,根据你的项目需要来决定什么时候要跳,哪些元素要跳。
react里面的value和defaultValue
在react表单里面存在两种组件形式,一种叫controlled component, 一种叫uncontrolled component。controlled的意思是说,你只能通过code去改变组件的状态,比如checkbox,如果是controlled,那么你只能通过code去改变它的选中状态,而不能靠用户点击来修改。而uncontrolled的组件反过来,只能通过用户操作来改变状态,而不能通过code来改变。很可惜,一个react组件,不能在这两个形态之间转换,所以这对你写的code会有影响。
怎么区分呢?很简单,看你的代码是使用defaultValue/defaultChecked还是直接使用value/checked。如果是使用value/checked,那么是controlled,反之则是unconrolled。
另外还有两个属性,disabled和readOnly,这两个属性其实要配合这两种形态来使用。controlled component只和readOnly配合,uncontrolled component只和disabled。如果一个input设置了value属性,但是没有给onChange或readOnly,控制台会有错误提示。这是因为,一个controlled组件,它的创建一定要用于控制,而非为了初始化一个值。这种情况下如果你想在外部去控制它,而不是它的onchange事件中,那么应该添加readOnly,这样就不会报错了。当然,这里的配合只是我的个人感悟,并非官方强制。
之前的想法是,如果用docker,是否可以做到服务的分离,比如mysql,一个挂掉,另外一个还在跑,两个博客互不影响。然后最后发现,我的ECS根本跑不起来,没多久,就都挂了。于是尝试直接用ubuntu的apt安装了apache2、PHP、mysql,现在博客跑起来非常快,有的时候打开页面真的是秒开。这比以前用lnmpa还爽。
有的时候我在想,新技术越来越高端,但是真的是否适合呢?比如我现在全面专研前端,是不是要把博客改用nodejs重写一遍呢?我没有,博客还是wordpress,可能10年以后还是,没有必要改。新技术固然好,但是新技术如果摧毁老技术,除非真的是有极大的提升,否则没有必要对老技术的产品全部重来一遍。
以前我习惯写这样的注释:
// comments for if
if (...) {}
// comments for else
else {}
这样的注释被prttier format之后,else部分的注释会跑到else的括号里面去,非常不符合我们的预期。解决的方案是,把if…else当作一个整体,不可分割,因此不可以在else前面加注释,而是把整个if…else的注释写在if前面,对整个判断逻辑做说明。
以前喜欢折腾,一直都是用lnmpa做环境后来发现,数据库经常挂掉。上次换了阿里云的服务器之后,直接用ubuntu的apt安装了apache2 php和mysql,这一个月下来,感觉完全没有问题,根本不需要太多关注,而且网站的打开速度提高了不少,不知道是什么原因,一方面可能是这台server的IO性能好,还有一个原因我觉得就是直接用ubuntu源的mysql,没有经过复杂的配置。之前的架构是nginx去代理apache,虽然nginx性能是好很多,但是同一台服务器把两个服务跑起来,内存就已经占了不少了,何必了。
早上看到有网友留言说评论提交之后,没有然后……我大概get到了意思,就是ajax提交之后被block住了。我第一反应可能是缓存导致的,但后来一想,并没有在comment的脚本里加缓存啊。于是中午排查了一下,发现了两个可能,一个是session lock,另一个是smtp邮件服务有问题。
我把smtp发送改为了ssl模式,端口是465. 还到阿里云安全组里面去添加了规则。回来测试了一下,发邮件OK了。
session lock这个话题比较专业,这里有一篇文章可以大概了解为什么一个session会把请求block住。简单的说就是你代码里面一个简单的$_SESSION[‘xxx’] = ‘xxx’,实际上php要去写入文件,如果同时多个请求都去执行这段代码,那么后面的请求需要等前面的请求把这事儿干完了才能继续,不然只能等着。解决的办法就是在每一个赋值语句后面加上
session_write_close();
这个语句可以在你的php程序执行完之前提前把session lock解锁。如果不执行,那么PHP要等到你当前这个进程执行完毕才会unlock。而在我这次案例里面,因为发邮件的问题导致我的PHP进程被block住,所以如果在发邮件之前有一个session写入,那么其它的要写入session的程序就会被block住,比如我在后台提交了一个请求,要写入某个session,前台某个提交也要写入这个session,那么在后台那个请求执行完毕之前,前台的提交就会block在写入session那个地方。

