312018.1

Everything You Need To Know About Shadow DOM

262018.1

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)这样的操作。上面红色的部分则是需要自己进行修改,甚至,你可以把这个组件进行丰富,根据你的项目需要来决定什么时候要跳,哪些元素要跳。

11:04:12 已有0条回复
242018.1

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,这样就不会报错了。当然,这里的配合只是我的个人感悟,并非官方强制。

16:04:08 已有0条回复

之前的想法是,如果用docker,是否可以做到服务的分离,比如mysql,一个挂掉,另外一个还在跑,两个博客互不影响。然后最后发现,我的ECS根本跑不起来,没多久,就都挂了。于是尝试直接用ubuntu的apt安装了apache2、PHP、mysql,现在博客跑起来非常快,有的时候打开页面真的是秒开。这比以前用lnmpa还爽。

有的时候我在想,新技术越来越高端,但是真的是否适合呢?比如我现在全面专研前端,是不是要把博客改用nodejs重写一遍呢?我没有,博客还是wordpress,可能10年以后还是,没有必要改。新技术固然好,但是新技术如果摧毁老技术,除非真的是有极大的提升,否则没有必要对老技术的产品全部重来一遍。

09:31:42 已有0条回复
232018.1

以前我习惯写这样的注释:

// comments for if
if (...) {}
// comments for else
else {}

这样的注释被prttier format之后,else部分的注释会跑到else的括号里面去,非常不符合我们的预期。解决的方案是,把if...else当作一个整体,不可分割,因此不可以在else前面加注释,而是把整个if...else的注释写在if前面,对整个判断逻辑做说明。

10:31:48 已有0条回复
192018.1

以前喜欢折腾,一直都是用lnmpa做环境后来发现,数据库经常挂掉。上次换了阿里云的服务器之后,直接用ubuntu的apt安装了apache2 php和mysql,这一个月下来,感觉完全没有问题,根本不需要太多关注,而且网站的打开速度提高了不少,不知道是什么原因,一方面可能是这台server的IO性能好,还有一个原因我觉得就是直接用ubuntu源的mysql,没有经过复杂的配置。之前的架构是nginx去代理apache,虽然nginx性能是好很多,但是同一台服务器把两个服务跑起来,内存就已经占了不少了,何必了。

16:37:31 已有0条回复

早上看到有网友留言说评论提交之后,没有然后……我大概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那个地方。

15:59:54 已有0条回复
182018.1

到现在,我算是有那么几场说走就走的旅行,也不在乎再来一场。大四毕业的时候,一个人自习,突然想到什么,就买了火车票,第二天去了武汉。选择武汉,完全是因为听了声行漫步,有一期讲武汉的,而那时正好是樱花开时。身上只带了300块不到,那次经历还让我写了一篇短篇,那时我的博客还叫努努比。

时隔7、8年,这样的个性从没有消退。下午开会的时候突然走了什,翻开小红书,本来想看看厦门,被带到了泉州,紧接着被带到了平潭。于是,平潭成为这次的目的地。下班回来花了将近3个小时翻攻略,选择了适当的地理位置的名宿,买好高铁票。

有的时候,诗和远方并不能拯救孤独的灵魂,然而有目的地,总是好的。

22:08:43 已有0条回复
152018.1

在经历长时间的挣扎之后,我最终将自己的部分网站迁移到lightsail。这不是背叛,感谢linode曾经给我的满足感,但是世界上的事,都是用脚投票。当linode不再适合我时,无论他口碑多好,我都依然决定离开。

当初决心每月$10搬到linode时,在香港的VPS上折腾过很久,后来一次服务商被DDOS攻击,停运了一两个星期,才决心搬迁。那是两年前的事了。在上linode时,还在美国和东京机房之间徘徊过。后来选了美国西海岸的机房,那时虽然慢,但是还基本OK。而时间过了两年,这种慢已经无法忍受了。因为家里的网速慢,打开网站基本上靠等和忍,刷新10次才出来一次。于是开始找新的服务商。可是google了很久,linode都占据着第一的位置。在一篇还算靠谱的文章里,我知道了亚马逊出了lightsail,在我的印象里,亚马逊云就是AWS,不仅速度慢,而且计费坑爹,在试用了它免费的EC2之后就弃坑了。但是现在在linode不想用的情况下,最为世界上最大的云服务商之一的亚马逊又进入了我的视野。于是又尝试了一下lightsail。

lightsail是亚马逊推出的有别于EC2的共享虚拟服务器服务,简单的说就是阿里云的ECS。它的收费方式和我目前用的阿里云的ECS一样,按月计费,内存大小、流量都固定了上限。其实这种计费方式最适合个人,完全不用担心每月的账单会不一样。而且就现在的汇率来看,同样的配置,lightsail竟然比阿里云更便宜,测试了性能之后,发现lightsail的服务器打开网站速度也没差多少。现在的问题是,为什么还有那么多人选择阿里云?难道只想做国内市场?中国企业难道不应该具备基本的国际化市场思想吗?

搬迁网站超级快,全部靠linux命令行完成。mysql的备份和导入,scp的远程拷贝,整个搬迁过程总时间加起来不到30分钟,在本地hosts修改测试没问题之后,把dns切换到新的服务器。搬迁结束,现在可以顺畅打开网站了。

很想了解,为何最为第一名被推荐的linode现在变得那么辣鸡。看了下别人的文章,我想可能有两个原因:1.网络线路问题,据称他们的机房已经不支持电信直连。2.共享内存,linode的虚拟技术是内存共享,在它所有套餐里面,你都看不到内存的信息(可能内部有一个每个应用的最高使用限定值),而由于国内对linode的推崇,导致很多人在上面架设应用,人一多,特别是国人一多,资源就消耗的快,网站打开慢成常态。说到这里,本质上,还是服务商在技术上不可能完全掌控单个应用进程资源,所以这种共享内存的策略必定被淘汰。反观亚马逊,把EC2的经验用到lightsail上,我估计lightsail的机器都是EC2淘汰下来的,但是因为技术上的优势,也比其它服务商更稳定。

不过有的文章也有推荐美国的其它服务商,理由是,某些服务商只做美国本土生意,服务器质量都是上乘,但是因为只做本土生意,所以不为国人所知。我觉得也有一定道理。但是如果它只做本土生意,那么在宽带上可能就像阿里云一样,对国外的宽带做了限制,毕竟都要节省成本,所以我们访问那上面的网站估计也慢的不行。

转投lightsail之后,我相当于现在只拥有阿里云和亚马逊的VPS,(虽然还有几个其它的虚拟服务器,)今后希望不要再有大的变得,让我可以不再折腾服务器问题,而是专心写博客。

13:41:53 已有0条回复

linux命令行备份和还原mysql数据库