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那个地方。
在经历长时间的挣扎之后，我最终将自己的部分网站迁移到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，（虽然还有几个其它的虚拟服务器，）今后希望不要再有大的变得，让我可以不再折腾服务器问题，而是专心写博客。
-
你这不是用的杭州的阿里云吗。。。lightsail不好用吗？求告知。。。。#752 5656 2019-03-27 14:12
-
Lightsail的稳定性比阿里云好，价格便宜，但是速度会慢很多，我博客放在阿里云，其他没备案的域名站放亚马逊#753 回复给#752 否子戈 2019-03-27 14:34
-
搬瓦工49.9的GIA-E简直不要太舒服，美西机房电信联通170ms，移动210ms的延迟，带宽也很充足。三网的链接效果好很多很多，建议值得一试。#904 Francis 2020-02-29 13:59
-
bwg不是主要给ss用么，还敢放网站在上面？#908 回复给#904 否子戈 2020-03-01 00:06
-
还有建站啊，搭梯子好的机子建站也不会太差啊，为啥不敢放网站在上面啊，大家都是独立IP，别人的IP被封了和你也没啥关系不是。你就建个站，国家不会封你IP的，而且搬瓦工上的站长也是非常多。还有lightsail上搭梯子的也是非常的多，之前aws有github学生包给150刀码子时候，lightsail几乎让薅秃了，全是搭梯子的，aws因为家大业大只是受了点影响。#911 回复给#908 Francis 2020-03-01 08:37
-
Lightsail现在体验如何了#1002 123 2021-01-17 19:44
-
不再用了#1004 回复给#1002 否子戈 2021-01-22 17:31
-
你好，我客户在南美，我看了一下，阿里的服务器没有在南美那里有，所以想用lightsail，或者还有其他推荐吗，求告知#1111 回复给#753 mark 2021-11-18 18:45
-
这个不清楚，客户在哪里最好买哪里的服务器#1113 回复给#1111 否子戈 2021-11-18 22:09
-
有没有国外速度快性价比高的vps推荐#1223 莫兰特 2022-09-13 06:38
-
目前在用哪个呢？有推荐吗#1284 回复给#1004 Chaos 2023-04-30 05:39
-
目前就阿里云腾讯云了#1285 回复给#1284 否子戈 2023-05-06 20:13
