基本规范 每个文件只包含的一个 React 组件： 联系紧密的组件可以使用「命名空间」的形式； 每个文件中可包含多个纯函数组件。 始终使用 JSX 语法，不要使用 React.createElement 创建 ReactElement，以提高编写速度、可读性、可维护性（没有 JSX 转换的特殊场景例外，如在 console 中测试组件）。 文件规范 组件文件使用一致的.js或 .jsx后缀。所有组件文件的后缀名从.js或.jsx中任选其一。不应在项目中出现部分组件为.js文件，部分为.jsx的情况。 每个存放组件的目录使用一个index.js/index.jsx以命名导出的形式暴露所有组件。同目录内的组件相互引用使用import Foo from './Foo';进行。引用其它目录的组件使用import {Foo} from '../component';进行。 命名规范 文件名：使用大驼峰命名法（PascalCase），如 MyComponent.jsx； 组件命名：组件名称和文件名一致，如 MyComponent.jsx 里的组件名应该是 MyComponent；一个目录的根组件使用 index.jsx 命名，以目录名称作为组件名称； 引用命名：React 组件使用大驼峰命名法（PascalCase）； 高阶组件使用camelCase命名。高阶组件事实上并非一个组件，而是一个“生成组件类型”的函数，因此遵守JavaScript函数命名的规范，使用camelCase命名。 使用onXxx形式作为props中用于回调的属性名称。使用统一的命名规则用以区分props中回调和非回调部分的属性，在JSX上可以清晰地看到一个组件向上和向下的逻辑交互。 使用withXxx或xxxable形式的词作为高阶组件的名称。高阶组件是为组件添加行为和功能的函数，因此使用如上形式的词有助于对其功能进行理解。 带命名空间的组件 如果一个组件有许多关联子组件，可以以该组件作为命名空间编写、调用子组件。 class Form extends React.Component { // ... } class Row extends React.Component {} class Label extends React.Component {} class Input extends React.Component {} Form.Row = Row; Form.Label = Label; Form....

0. 作者以及原文介绍 作者是 Dr. Axel Rauschmayer，号称”德国阮一峰“，本文原文来自于他的博客：https://2ality.com/2020-02/understanding-types-typescript.html，不熟悉他的可以关注一下他的博客。 1. 每个角度都从这三个问题来解释 以下三个问题对于理解类型是如何工作的非常重要，需要从这两个角度中的每一个角度来回答。 myVariable 的类型 MyType 意味着什么？ let myVariable: MyType = /*...*/; Sourcetype 可以分配给 TargetType 吗? let source: SourceType = /*...*/; let target: TargetType = source; TypeUnion 是如何从 Type1、 Type2 和 Type3 衍生而来的？ type TypeUnion = Type1 | Type2 | Type3; 2. 角度 1： 类型是一组值 从这个角度来看，类型是一组值： 如果 myVariable 具有 MyType 类型，这意味着可以分配给 myVariable 的所有值都必须是集合 MyType 的元素。 如果 Sourcetype 可以分配给 TargetType，那么 Sourcetype 是 TargetType 的子集。 因此，TargetType 也允许 SourceType 所允许的所有值。...

一个读者的困惑，我做了简单的解答，希望能对他有所帮助。 ## ##1. 如何把一个知识由浅入深的学习？ 见问题 2 ##2. 那些写技术文章的作者，为什么对某一知识或某一框架理解得那么深入，是如何学习的呢？ 我觉得有以下几点： 使用的多，踩得坑多，经验丰富。 花时间深入研究过原理。 思考过这个东西的价值以及为什么会出现(这个点很容易被忽略，我的那篇从历史的长河中聊虚拟 DOM 的意义就是这个点)。 思考过这个东西能给自己的业务带来什么帮助，然后紧密的结合到自己的项目中。 如果你觉得这几个点感觉你都懂，那我问你几个问题，比如你在你们公司想引入 React 来做项目。 问题一：你为什么要用 React？ 问题二：用 React 能带来什么好处？ 问题三：如果用 Vue 或者 JQuery 能行吗？ 问题四：React 适合哪些场景？哪些场景又不适用？ 问题五：你觉得 React 存在的意义是什么？ 问题六：React 有什么缺点？ 问题七：你觉得引入 React 会有什么成本，收益和成本如何进行平衡？ 我想表达的是在学习一个东西，或者说想深入一个知识，不仅仅知道它是什么，怎么用，还要去了解它为什么会产生，能带来什么价值，解决了什么问题。这样在你判断是否引入这门新技术才有充足的理由，否则就是追风，看到这个东西比较火，可能你根本就不需要，然后引入了反而给自己增加负担。 在你想知道它解决了什么问题的时候，可能就会思考为什么它能解决这个问题，然后再去寻找这个答案的时候就会深入他的原理，加上自己大量的实践，慢慢的就成为这个东西的专家了。 ##3. 什么时候去接触和怎么去学一些规范文档？ 我想你说的规范文档应该是官方文档这种吧，然后下面讨论的都是基于官方文档。 官方文档我一直是把它当做完善我知识体系的东西来看待的，而不是入门教程。毕竟官方文档是给所有人写的，不管你是没使用过的，还是使用过很长时间的，所以就导致大部分的内容都是比较官方的，所以就导致不一定适合你。所以才有了各种各样的教程，因为每个人的所拥有的知识不一样。 另外官方文档也不会告诉你哪个知识点重要，哪个知识点常用，它只会告诉你有这个东西，这些东西都是需要在实战中去得知。 特别是对于 CSS 标准，或者 Javascript 标准这种，不到万不得已是不会去看的，东西又多，又不适合新手阅读，但是在你看到网上有不同答案的时候，就非常适合去看标准，平时就看看书、看看博客、看看视频教程就行。 4. 如何处理网上的技术文章以及实体书？ 我觉得首先要明白文章和书的区别是什么，然后才能正确的去使用他们。 我们一般对书的认知是对知识成体系的介绍，书是比较的全，是对整个知识比较全面的介绍，另外由于写书比较的耗时，所以往往书里面的内容都是晚于知识点出来很久的，比较适合那种很久不会变的知识。 知道了书的特性，那么我们何时需要去读书呢？ 我觉得应该是在你想打造或者说完善你自己的知识体系的时候就一定要去读书，特别是像那种《xxx权威指南》这种，就特别的适合用来完善知识体系的。 但是一本书不可能把方方面面讲完，都是会有侧重点的，就拿学习 JavaScript 来说，想学好《JavaScript高级程序设计》又称红宝书、《JavaScript权威指南》又称犀牛书是不应该绕过的，那么这两本书又有什么区别呢，这两本书都很厚，理论上讲得都很全。 这两本书都会把 JavaScript 最重要的东西肯定都是会介绍的，但是红宝书侧重于程序设计，相对来说比较注重实战一点，所以对于原型、继承这种在程序设计方面较多的知识点会用大量的篇幅，然后举很多的例子，这样更利于我们的程序设计。 而对于犀牛书的话他的侧重点在于权威，那么他的侧重点就在于全，要比所有的 JavaScript 的书都介绍的更全，相对来说比较偏理论。 因为每本书都会有自己的特点，就是侧重点不同，所以在看实体书的时候就要看自己需求，如果想提高自己的程序设计能力，就看红宝书，如果想查漏补缺，看看自己是否对 JavaScript 全面了解，就看犀牛书。 其他的书也一样，对于技术书我一般的习惯都是带着目的去看，而不是像一些消费型的书随便翻。 再说说技术文章，技术文章他的特点就是可以做到很新，但是质量参差不齐，而且很容易传播错误的知识。...

本文是译文，原文地址是：https://medium.com/@sdolidze/the-iceberg-of-react-hooks-af0b588f43fb React Hooks 与类组件不同，它提供了用于优化和组合应用程序的简单方式，并且使用了最少的样板文件。 如果没有深入的知识，由于微妙的 bug 和抽象层漏洞，可能会出现性能问题，代码复杂性也会增加。 我已经创建了12个案例研究来演示常见的问题以及解决它们的方法。 我还编写了 React Hooks Radar 和 React Hooks Checklist，来推荐和快速参考。 案例研究： 实现 Interval 目标是实现计数器，从 0 开始，每 500 毫秒增加一次。 应提供三个控制按钮: 启动、停止和清除。 Level 0：Hello World export default function Level00() { console.log('renderLevel00'); const [count, setCount] = useState(0); return ( <div> count => {count} <button onClick={() => setCount(count + 1)}>+</button> <button onClick={() => setCount(count - 1)}>-</button> </div> ); } 这是一个简单的、正确实现的计数器，用户单击时计数器的增加或减少。 Level 1：setInterval export default function Level01() { console....

又一年过去了，2018 年写年终总结的场景还历历在目，写这篇文章之前还专门去看了下 2018 年的年度总结，主要是看自己在 2018 学的东西自己还能记得啥。 印象最深刻的应该是还是函数式编程相关的东西，因为确实在我深入的去接触它过后，我的很多编程思维都被它所影响。虽然在项目中不会去用很多函数式的方式去写，但是函数式的那些特点深深的指导着我如何去设计一个更容易维护的函数，其中一些思维可以见我去年的写 函数式编程，真香。 做个预测：三年之内，函数式编程要火一波，原因是 serverless 的兴起。 回顾了过去，我对今年的整体总结是：输入很多、输出不够。 输入 自我感觉自己是一个焦虑的人，焦虑也许来源与社交(周围优秀的人太多，见了太多比自己年轻或者同龄人)、也许来源于自己见识更多(处于达克效应里面「知道自己不知道」的境界)。 图片来源于网络 如果按照这张图来的话，我现在处于自信崩溃区，不知道自己是否处于绝望之谷，但是希望明年能进入开悟之坡。 从这张图里可以看到，自信程度高也不一定约好，很可能是处于愚昧山峰。 自我感觉自己还算坚强，没有被焦虑或者自信崩溃打败，相信自己通过努力，提升自己的专业知识和能力，总会逃离绝望之谷，所以我今年比以前都更努力的去学习，得到结果是我感觉自己今年在见识上提升了非常的多，见识越多，意味着格局会慢慢变大，格局越大，就越能成功(这只是我自己的人生逻辑)。 虽然在精神上的收获了很多，但是从今年各方面的产出来看，不管是职业还是影响力都没有实质性的进展，但是我没有着急，平时安慰我自己的话就是：还没到爆发的时候，现在一直积累就行。 读书 读书是我今年最满意的一项输入，读了 20 多本书，虽然这个成绩不算好，但是对于我来说是一个非常大的进步，因为我从小就特别讨厌读文字，小说也不例外。现在一年能读 20 多本，差不多半个月读一本，进步非常的大了。 最开始想读书也是自己接触的很多大佬，或者在网上看到一些大佬的文章等，了解到读书非常的重要，所以就开始买书来读，刚开始读得很慢，而且很枯燥，一本书可能要花一个月才能读完，大概读了两个月后，自己养成了读书的习惯了，每天花 30 ~ 60 分钟的时间读书，周末就花多一点，一周就能读一本书。 那个时候成就感就来了，对读书产生了兴趣，然后读书 对于我来说就不算什么难事儿了，反正有大段的空闲时间就会用来读书。 在书的媒介方面我还是比较传统，喜欢纸质书翻书的感觉，所以我读的大部分书都是纸质书，基本每个月都会买 3、4 本书，主要是每个月基本上当当都会搞活动，打 5 折或者满 100 - 50，另外还有满 200 - 30 的券，然后由于我会每个月自费给公众号里的读者送书，正好就一起会买六七本书，差不多 200 块。 下面是我今年读完的书，没读完的没有列出来，明年再继续读，大部分都是纸质书。我目前读书还没有进行主题阅读，基本上都是泛读，涉及的不仅仅是技术书，也有心理学、品牌、历史、理财、个人成长各个方面。 电子书 《实用性阅读指南》三星 《麦肯锡精英高效阅读法》三星 《半小时漫画中国史》1-4 册 三星 《小狗钱钱》五星 《如何有效阅读一本书》三星 纸质书 《现代前端技术解析》四星 《你不知道的 JavaScript(上)》五星 《高效前端：Web 高效编程与优化实践》四星 《重构(第二版)》五星 《React 状态管理与同构实战》四星 《见识》四星 《被讨厌的勇气》五星 《刻意练习》四星 《高效能人士的七个习惯》五星 《超级符号原理》三星 《学会写作》三星 《少有人走的路 4：在焦虑的年代获得精神的成长》四星 《原则》五星 《语言学的邀请》五星 《文明之光(第一册)》五星 打五星的都是我自己读完之后感觉收获很多的，每个人可能感受不同，三星就是我觉得可读可不读的书。...