Attack on Life ⚔️

Table-rowKey

index.js:1 Warning: [antd: Table] Each record in dataSource of table should have a unique key prop, or set rowKey of Table to an unique primary key, see https://u.ant.design/table-row-key

我们在使用Table组件时，在浏览器控制台经常会看到这样的warning，原因是行key指定缺失。

假如rowKey不指定，则默认为rowIndex。所以假如记录确实没有任何唯一的字段，不指定。

1
2
3
4
5
6
7
8
9
10
11
12
13

getRecordKey = (record: T, index: number) => {
   const { rowKey } = this.props;
   const recordKey =
     typeof rowKey === 'function' ? rowKey(record, index) : (record as any)[rowKey!];
   warning(
     recordKey !== undefined,
     'Table',
     'Each record in dataSource of table should have a unique `key` prop, ' +
       'or set `rowKey` of Table to an unique primary key, ' +
       'see https://u.ant.design/table-row-key',
   );
   return recordKey === undefined ? index : recordKey;
 };

CR现在的代码范围是 by单独分支，by天，代码实践中是否存在代码重看呢？

单独按照某个分支比如sprint，我们按照提交日期筛选昨天的代码去看，这些提交实际上也是包含了MR，MR本身就是提交，而MR这种提交会包含非当天的提交记录，什么意思？就是比如你5号做的MR，可能存在4号的提交代码。

会重复看到同一段代码吗？

1. 日期会出现不是目标所看日期的，如上，5号的MR，包含的Diff是4号的提交
2. 因为CR我们看的是Diff，假如之前的代码已经进入该分支，再看之后的不论哪一天，重复的代码自然不算在Diff里，所以不存在重复看同一段代码

结论

在做项目开发，及CodeReview时，我一直推荐Team降低对于lodash的依赖，多用原生写法，发现有人用，我就会关注下，并且反复去问为什么要用lodash。这里我就解释下为何这么讨厌它。

1. lodash提供了很多的工具函数，有你知道的和你不知道的，过渡使用也就造成了过渡依赖，你可能最终的结果是了解lodash，而不了解原生JS,防止因为大量使用lodash，而废弃了对于原生JS的学习
2. 依赖lodash，现实来说构建包的体积也会随之增大，当然在带宽，网速很快的今天，似乎这个体积，我们不用过度care
3. 在原生和Lodash提供的方法都可以完成某个功能之时，用lodash可能意味着性能更差。
4. lodash的方法很多考虑的情况非常全，所以某种程度容错性也就强，但要知道不报错有时比报错更危险。比如find,get，不报错，但一定对吗？
5. lodash的某些方法比如get方法，实际上使得类型信息丢失，同时，路径访问参，丧失了静态分析能力，比如重构，这里就会不易发现。
6. lodash的某些方法，如果不熟悉可能会出错，比如isEmpty，要知道_.isEmpty(true)结果是true

对待lodash的使用态度

1. 完成特定功能，优先使用JS原生写法，当然考虑到目标浏览器兼容性
2. lodash的导入，采用ES模块按需导入，一定程度降低构建打包体积
3. 推荐一个仓库-You-Dont-Need-Lodash-Underscore，透过这个仓库，我想也可以了解大牛们是如何看待lodash的，同时可以了解到如何用原生实现等价功能
4. 不是说不让用，但反感和排斥，不假思索，就是用lodash解决一个功能的，因为我认为这些人，在这样做的时候，不去思考原生是否能够做到，不去考虑性能，用一句感性的话就是毫无负罪感。
5. 对于那些lodash的无脑粉，也许有一天，开发环境中没有了lodash依赖，你们又怎么办呢。

一直以来对于依赖停留在简单的使用中，对于依赖模型却不了解，于是决定将这个盲点消除

以下Scenario来了解。

直接依赖与间接依赖同一个包

注意：版本有所不同

query-string是前端常用的类库，用于为URL中的查询参的正反向解析。正常来说，我们使用的话，直接安装用最新版6.x即可。但之前曾遇到一次白屏事故，最后定位到是因为v6版的兼容问题。于是这篇文章就聚焦于清晰v5,v6的区别，及对WEB的影响。

官网对于5 vs 6差异的说法

This module targets Node.js 6 or later and the latest version of Chrome, Firefox, and Safari. If you want support for older browsers, or, if your project is using create-react-app v1, use version 5: npm install query-string@5.

翻看Git提交记录，注意到这个第一次的v6提交信息。现代浏览器具体是什么，哪个版呢？

问题

用一个例子来描述吧，当用户输入关键词A，触发了检索，一秒钟后，用户输入了关键词 B，触发了检索，这时A检索结果回来了，呈现出来了列表展示，用户诧异，为何输入的B，返回了A结果，再过一会儿B结果回来。用户在可视化的情况下，看到了错误的结果，紧接着看到了正确的结果。

问题思考

接口慢是个问题，但是除了接口慢，也可以看到整个的实时检索存在设计缺陷。

1. 当触发了第二次请求时，第一次请求如果还在请求中应该中断，这样对于开销来说小一些
2. 用户之所以会误认为A结果集是用户输入B的结果，还有一个问题是，是否当执行B检索时，就不应该呈现结果集，通过loading等形式呈现给用户还正在检索

最近解决样式遇到了这样的问题，具体如图。

如图即问题现象

复现

固定表头，设定百分比宽

最近WEB中对于时间格式化有了个性化需求，解决的同时，这里记录下。

需求一：走0时区

为了时间显示统一化，要求按照0时区时间展示，因为之前我们都是封装统一的轮子-使用momentJS做的日期格式化，所以只需要在WEB启动时做下时区设定即可。

1
2
3

moment.tz.setDefault('Africa/Abidjan');

注意：Africa/Abidjan即是0时区

redux saga使得一个action发起后，我们进行大量的操作[异步，同步]，这些操作依次处理，但本身发起这个action确是个异步。

那么问题来了，存在一个场景，如果我们发起一个action，等待action结束执行某个动作， 这个需求怎么解决呢，目前我们的方案是2个，1. 使用回调，假如需要执行多个动作呢，可能会存在多个回调。并且遇到回调，我们要小心，避免陷入回调地狱。2.effects中，数据最终流转到redux状态树，我们在组件中判断状态的变化情况，来了解是否action执行结束。但思考下，难道saga中effects的执行一定最终是将某些值存入redux状态树吗，假如我们支持返回值，那么就可以打破这个了吧。
如上两个方案都可以解决问题，但都有其弊端，因此，问题聚焦，就是action是否可以promise化？

redux-thunk

提到了action promise化，就先提一下thunk，thunk的本质就是中间件形式，先执行了某个异步方法，再执行真正的个action。但是thunk的缺点是做不了丰富的异步动作编排，所以saga作为竞争对手解决了这个问题。

thunk不是我们当前问题的菜。、

redux-saga-promise

今天前端在引入@adobe/redux-saga-promise包时，启动报这个错。于是开始了解决，这里记录下

regenerator-runtime是什么

Source transformer enabling ECMAScript 6 generator functions in JavaScript-of-today

也就是说编译后的JS提供generator及async函数的支持。