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提交信息。现代浏览器具体是什么，哪个版呢？