2018/06/08 ～ 2018/06/10: 高阶组件， 一点selector

[Lxylona]

这两天感觉自己学习效率降低到谷底，应该是因为看了几天的文档和源码，输入太多没有输出导致脑细胞多巴胺下降，智商降低等等等等。所以我决定先写写我的selector～～～～

1. 高阶组件

周六浏览了一遍React官方文档里面的《高级指引》，主要看了一下《高阶组件》那一部分。感觉高阶组件就是一个工厂函数把传进去的组件包装一层再返回。

因为学习任务里面说到要重点理解高阶组件，所以我又找了两篇文章看了：

React高阶组件（译）

深入理解 React 高阶组件

我还没有实践过高阶组件，不过看了文章觉得高阶组件好像是一个很自然的形式，就像我平时多处用到某个逻辑我也会把它们抽出来单独成一个函数一样。所以我想先写写我的 selector 组件，过两天再回来看一下高阶组件，顺便看有没有什么demo可以敲一敲。

2. selector

selector组件我今天开始在写了，刚写了一点，好久没写正经代码的感觉，好感动啊！前几天在啃源码和看文档，感觉自己打得很少，我看源码就很容易走神= =！今天一整天几乎都在打代码，感觉神清气爽的～～

不过它现在还只是一个未成形的胚胎，所以我就没有放上来。

我把 selector 分成两个部分，一个是 Search 组件(用来搜索的)，一个是 OptionsBoard (取名无能，是展示列表的)。

ps：昨天刚好看到了一篇文章：再谈前端虚拟列表的实现
是讲关于「可视区域渲染」的，我觉得挺有趣的，作者是用一个div撑开容器让其出现滚动条，然后用transform来移动「可视区域」并改变「可视区域」数据来模拟无限列表的。不过我发现在滚动的时候列表会有很明显的闪烁，滚动得慢的时候特别明显，可能是transform的数值计算不精确吧，不过我没有去仔细研究，等我把我自己的写好了再去看看。

3. 写React的感觉和写Vue的感觉

之前我一直写Vue的，之前最开始学Vue是因为听说Vue比较容易上手，但是我这几天学React反而觉得React比较容易适应，因为写React的时候很像在写原生的js，特别灵活 。Vue给我的感觉就真的是一个方方正正的框架，我就在这个框架里面填充自己的东西，我还真不太能适应这种感觉？

还有我刚看了React的Diff算法，这个算法的一个缺点是如果列表结尾的节点移到列表开头，那剩下的所有节点都要移动。之前看Vue的Diff算法的时候，我记得Vue的Diff的算法是有对比头尾节点的一个步骤的，我当时不理解为什么要这么做，所以就没有继续看下去，现在看来也许是为了解决这个问题吗？不过我也忘了Vue的Diff算法具体是怎么实现的了，在此留坑等我把selector写完了就去看哈哈哈！

4. 一个小小的疑惑

写selector的时候有一个小地方让我有点疑惑，就是我想在 Search 中关键字改变的时候，把 OptionsBoard 的scrollTop 设为0，我用了父组件中用了 ref 发现引用的是 OptionsBoard 而不是包裹的DOM元素，看了一下文档，说是要用 forwordRef，但是我突然想到，为什么不能直接用document.getElementById？但是如果直接用document.getElementById，那ref的意义在哪里呢？是我还没有理解这一块吗？

[arcthur]

看了 demo 演示，有些问题

1. 点击输入框才有选择，移动不用 click 事件，PC 才用
2. 移动与 PC 都支持指 PC 使用弹出下拉框那种形式，移动保持你做的样式，这中间需要有判断

增加需求

1. 记录当前选择的位置，下次就在这个位置上，记录用本地缓存
2. 大数据量渲染加载改成异步请求，请求可以自己模拟

[arcthur]

用 document.getElementById 就是 jquery 思想了，在组件中直接带进了副作用（只有少数情况下不得不用）
想拿值就传值，不要传 ref，不然代码中就有 magic 了

[spllot]

1.本地存储的KEY命名需要特殊化，尽量保证不会被其他的覆盖。同时如何保证多实例的时候，这些KEY不会互相冲突覆盖？

2.请求数据的设计，整体方案有两种情况，一种是前端一次性全取出来，然后前端分页展现。另一种是前端按页取出来进行展现。而针对后者又有两种情况：一种是后端能够告知整体数据量大小，这时可以通过前端简单的计算判断出是否hasMore，另一种是后端无法告知整体数据量大小，这时需要后端同时返回告知前端是否hasMore。可以考虑设计一种数据结构和方案，把这些情况都覆盖到。

3.缓存选择位置然后下次跳到这个位置---一般列表的数据结构类似id,label,demo中用的是value,title，这里的id和value一般都是全局唯一的，记录这个会比较靠谱，实在不放心，可以同时记录{value,title}。记录index有可能会因为数据的变化导致顺序发生变化。当前渲染的列表虽然在前端做缓存也可以，但实际上是否可行或者必要？

4.JSON.parse(JSON.stringify(last)) 这样写是否优雅？如果是因为数据格式或者类型的处理，是否有其他更好的写法？

5.如果大量的this.state.xxx 和 this.props.xxx 要输写，有什么更好的写法？

[Lxylona]

@spllot
我觉得存储整个列表确实没有必要，如果数据量很大的话好像也不大可行，但是单独记录{value,title}的话不知道下次首次渲染的时候应该怎么加载数据，然后跳到那个地方。是根据value或者title来判断这个对象位于哪一页然后取那一页的数据吗？这里没想通。

[spllot]

@Lxylona 实际的业务场景中一般是记录之前的选项就可以了，比如上次我选的是{value: 1, title:'title'},下次来的时候能够默认回填到input框中，如果搜索列表中刚好有这一项，这一项可以标记出来，表示当前选中的就是这一项。

[arcthur]

尝试抽象 pc mobile 共性的部分，不要在代码实现中做大量判断，可以输出两个 component