我又不懂网络，弄网络相关的就一脸懵逼。
浏览器能访问，我怎么想的到命令行无法访问，ping 都不通，查询 DNS 失败，就上次就因为这个错误卡了我半天儿。最后索性改了 hosts。
但开放的端口在局域网里没法访问，这个我知道，是防火墙。但是我也不会添加防火墙规则。一般都是程序提示，然后我放行，可是这次又不提示。为什么不提示呢，我很困惑。经高人提示，可能是我升级了 Node.js。我立刻否认，怎么可能，我这么懒……然后一看记录，真的升级过，秒打脸。后来卸载重装 Node.js 搞定。
全程一步一坑的。
Hook 写起来简单直观，我很喜欢呀！
useEffect 里面放有副作用的操作，那计时器放里面没毛病。一切正常，好的，我学会了！我还设置了清除操作呢~
什么？出错？？好着呢，计时器正常工作，各种功能一切正常，如此用了好几天了。
今天想加一个操作，然后也放在 useEffect 里，为了避免写错，写几句输出看一下……就看见一秒钟输出一次……难道说我的计时器一秒钟创建、清除一次。靠，这哪是一切正常啊，这是在承受范围内乱挥霍性能。
这正常么？我不造啊！问问去，果然不对劲儿。大佬们耐心教我，你得加上相关变量巴拉巴拉。
这一段好像……我觉得我以前看过所以没细看。不过这次的坑，是熟悉的味道，我十分确认，上一次用 react 的时候也掉进去过（不愧是我
useEffect 官方不建议多用，虽然我也用起来挺爽的。但是似乎不符合 react 的哲学。照 react 的哲学，上下级之间应该只通过prop来传递消息，dom 更新应该只通过 state 变更，不应在组件内部关心其他数据。
我理解的更新机制是一个浅复制 object，定时器判断是否相同，所以不属于根属性的变更（例如遍历出来的子对象）不会触发 dom 刷新。
我在 useEffect 里面设定了一个定时器，来按时更新一个叫做 time 的 state。
这样就触发了组件更新，而组件更新又反过来触发 useEffect ，死循环达成！
所以要加入关注变量列表，但这样写着简单点，却真算不上优雅。如果用 componentDidMount 和 componentWillUnmount 就不会出现上面的尴尬。
一个为了简便而使问题变得复杂的典型例子。
用第二个参数，就可以只执行一次
对对，就是学了这个！
慢吞吞。
我现在的重点就是不断地让代码合理化，依然围绕着最开始的几个组件在弄，让一切变得合理，符合我的预期，也符合 react 的设计理念（大概）。
我认为这是一个揣摩的过程。不断地区理解它的设计思路。
遇到了好多问题，主要集中在组件更新太频繁了。当然这个问题一般大概也不太会引起注意，我这不是有一个计时器全局驱动嘛，所以一旦频繁更新，会非常容易察觉到（输出的时候一秒一次）。
然后想明白了，组件是一个函数，但是这个函数主要负责显示内容和更新内容，我没必要把所有的计算流程都放进去。很多东西可以往外提，往上层提。这样整理之后即便频繁更新，造成的性能开销也不会很大，处于可以不去关心的范围内。
然后频繁更新的 state 和 props 尽可能用比较单纯的数据形式，让 react 自己去控制更新，这样即便在道理上是在每次变化时发生更新，但实际运算开销和传统方式应该差不多（我自己的理论推测）。
我觉得可以绑在全局变量上，在组件事件触发里需要的时候再去取。假如不是ui相关的不一定要和虚拟dom捆绑
一些组件需要计时器驱动更新
通过反复尝试，开始体味到了一些原则上的东西。于是现在要做的是根据自己理解的原则去整理前面写的几个组件。因为是很基础的思路发生了改变，所以基本有点重写的意思。
这也是我为什么一直没多写的原因，根基一变，全盘修改。
当然，写的慢是另外的问题。
遇到问题，研究问题，学习新知识，解决问题……一点都不可怕，甚至感到非常的开心。
可怕的是学习了一点新知识之后，发现前面很多东西可以用这个新知识进行优化，并且自己深度强迫症，不优化睡不好觉……
编译以后放在目标设备上一看，嘿，白板。问题很简单，肯定是什么语法不被支持。这时候有小可爱就说了，Babel 啊，倒是没错，但是 Babel 对个别语法可能不做转换，所以用它来兼容旧设备有时候走不通。这也是为什么我为 kindle 弄得那些页面都是全手写的原因。
唉，不过一会儿试试吧
对不对的咱不知道，但我自己的逻辑上基本相互契合的合理起来了。那就行吧，还能上来就整出一套大师级的代码么，能跑就行呗，何况我这蘑菇半天（这么多天），怎么也比能跑多进了几步，就行吧，可以往下一个阶段发展了。
JavaScript真的好玩