小型网站设计及建设,开发小程序的软件有哪些,考拉seo,公司网站建设哪家比较好大家好#xff0c;我是若川。持续组织了6个月源码共读活动#xff0c;感兴趣的可以点此加我微信 ruochuan12 参与#xff0c;每周大家一起学习200行左右的源码#xff0c;共同进步。同时极力推荐订阅我写的《学习源码整体架构系列》 包含20余篇源码文章。历史面试系列翻译自… 大家好我是若川。持续组织了6个月源码共读活动感兴趣的可以点此加我微信 ruochuan12 参与每周大家一起学习200行左右的源码共同进步。同时极力推荐订阅我写的《学习源码整体架构系列》 包含20余篇源码文章。历史面试系列翻译自https://github.com/mithi/react-philosophies[1] 2.5k star原文作者mithi[2]已获作者授权概要介绍最低要求面向幸福设计性能优化技巧测试原则 0. 介绍《React 开发思想纲领》是我开发 React 时的一些思考每当我 review 他人或自己的代码时自然而然会思考的东西仅仅作为参考和建议并非严格的要求会随着我的经验不断更新大多数技术点是基础的重构方法论SOLID 原则以及极限编程等思想的变体仅仅是在 React 中的实践而已 你可能会觉得我写的这些非常基础。但以下示例都来自一些复杂大型项目的线上代码。《React 开发思想纲领》的灵感来源于我实际开发中遇到的各种场景。 1. 最低要求1.1 计算机比你更「智能」使用 ESLint 来静态分析你的代码开启 rule-of-hooks 和 exhaustive-deps 这两个规则来捕获 React 错误。开启 JS 严格模式吧都 2202 年了。直面依赖解决在useMemouseCallback 和 useEffect 上 exhaustive-deps 规则提示的 warning 或 error 问题。可以将最新的值挂在 ref 上来保证这些 hook 在回调中拿到的都是最新的值同时避免不必要的重新渲染。使用 map 批量渲染组件时都加上 key。只在最顶层使用 hook不要在循环、条件或嵌套语句中使用 hook。理解不能对已经卸载的组件执行状态更新的控制台警告。给不同层级的组件都添加错误边界Error Boundary来防止白屏还可以用它来向错误监控平台比如 Sentry上报错误并设置报警。不要忽略了控制台中打印的错误和警告。记得要 tree-shaking!使用 Prettier 来保证代码的格式化一致性使用 Typescript 和 NextJS这样的框架来提升开发体验。强烈推荐 Code Climate或其他类似的开源库。这类工具会自动检测代码异味Code Smell代码中的任何可能导致深层次问题的症状它可以促使我去处理项目里留下的技术债。1.2 Code is just a necessary evil译者注程序员的目标是解决客户的问题代码只是副产品1.2.1 先思考再加依赖依赖加的越多提供给浏览器的代码就越多。扪心问问自己你是否真的使用了某个库的 feature  你真的需要它吗? 看看这些你可能不需要的依赖你是否真的需要 Redux有可能需要但其实 React 本身也是一个状态管理库。你是否真的需要 Apollo clientApollo client 有许多很强大的功能比如数据规范化。但使用的同时也会显著提高包体积。如果你的项目使用的并非是 Apollo client 特有的 feature可以考虑使用一些轻量的库来替代比如 react-query 或 SWR(或者根本不用)。Axios 呢Axios 是一个很棒的库它的一些特性不容易通过原生的 fetch API 来复刻。但是如果使用 Axios 只是因为它有更好的 API完全可以考虑在 fetch 上做一层封装比如 redaxios 或自己实现)。取决于你的 App 是否真正地使用了 Axios 的核心 feature。Decimal.js 呢或许 Big.js 或者其他轻量的库就足够了。Lodash/underscoreJS呢推荐你看看【你不需要系列之“你不需要 Lodash/Underscore”】[3]。MomentJS呢【你不需要系列之“你不需要 Momentjs”】[4]。你不需要为了主题浅色/深色模式而使用 Context考虑下用 css 变量 代替。你甚至不需要 JavascriptCSS 也足够强大。【你不需要系列之“你不需要 JavaScript”】[5]1.2.2 不要自作聪明提前设计我们的软件在未来会如何迭代可能会这样或者那样如果在当下就开始往这些方向进行代码设计这就叫 future-proof防过时面向未來编程。不要这样搞 应该在面临需求的时候再去实现相应功能而不是在你预见到可能需要的时候。代码应该越少越好1.3 发现了就优化它1.3.1 检测代码异味Code Smell并在必要时对其进行处理。当你意识到某个地方出现了问题那就马上处理掉。但如果当前不容易修复或者没有时间那请至少添加一条注释FIXME 或者 TODO附上对该问题的简要描述。来让项目里的每个人都知道这里有问题让他们意识到当他们遇到这样的情况时也该这样做。 来看看这些容易发现的代码异味❌ 定义了很多参数的函数或方法❌ 难以理解的返回 Boolean 值的逻辑❌ 单个文件中代码行数太多❌ 在语法上可能相同但格式化可能不同的重复代码❌ 可能难以理解的函数或方法❌ 定义了大量函数或方法的类/组件❌ 单个函数或方法中的代码行数太多❌ 具有大量返回语句的函数或方法❌ 不完全相同但代码结构类似的重复代码比如变量名可能不同切记代码异味并不一定意味着代码需要修改它只是告诉你你应该可以想出更好的方式来实现相同的功能。1.3.2 无情的重构。简单比复杂好。‍♀️ 小技巧: 简化复杂的条件语句最好能提前 return。 提前 return 的示例# ❌ 不太好if (loading) {return LoadingScreen / } else if (error) {return ErrorScreen / } else if (data) {return DataScreen / } else {throw new Error(This should be impossible) }# ✅ 推荐if (loading) {return LoadingScreen / }if (error) {return ErrorScreen / }if (data) {return DataScreen / }throw new Error(This should be impossible)‍♀️ 小技巧: 比起传统的循环语句链式的高阶函数更优雅如果没有明显的性能差异尽量使用链式的高阶函数(map, filter, find, findIndex, some等) 来代替传统的循环语句。1.4 你可以做的更好‍♀️ 小技巧: 可以在 setState 时传入回调函数所以没必要把 state 作为一个依赖项你不用把 setState 和 dispatch 放在 useEffect 和 useCallback 这些 hook 的依赖数组中。ESLint 也不会给你提示因为 React 已经确保了它们不会出错。# ❌ 不太好 const decrement  useCallback(()  setCount(count - 1), [setCount, count]) const decrement  useCallback(()  setCount(count - 1), [count])# ✅ 推荐 const decrement  useCallback(()  setCount(count  (count - 1)), [])‍♀️ 小技巧: 如果你的 useMemo 或 useCallback 没有任何依赖那你可能用错了# ❌ 不太好 const MyComponent  ()  {const functionToCall  useCallback(x: string  Hello ${x}!,[])const iAmAConstant  useMemo(()  { return {x: 5, y: 2} }, [])/* 接下来可能会用到 functionToCall 和 iAmAConstant */ }# ✅ 推荐 const I_AM_A_CONSTANT   { x: 5, y: 2 } const functionToCall  (x: string)  Hello ${x}! const MyComponent  ()  {/* 接下来可能会用到 functionToCall 和 I_AM_A_CONSTANT */ }‍♀️ 小技巧: 巧用 hook 封装自定义的 context会提升 API 可读性它不仅看起来更清晰而且你只需要 import 一次而不是两次。❌ 不太好// 你每次需要 import 两个变量 import { useContext } from react; import { SomethingContext } from some-context-package;function App() {const something  useContext(SomethingContext); // 看起来 ok但可以更好// ... }✅ 推荐// 在另一个文件中定义这个 hook function useSomething() {const context  useContext(SomethingContext);if (context  undefined) {throw new Error(useSomething must be used within a SomethingProvider);}return context; }// 你只需要 import 一次 import { useSomething } from some-context-package;function App() {const something  useSomething(); // 看起来会更清晰// ... }‍♀️ 小技巧: 在写组件之前先思考该怎么用它设计 API 很难README 驱动开发RDD是个很有用的办法可以帮助你设计出更好的 API。并不是说应该无脑使用 RDD但它背后的思想是很值得学习的。我自己发现在设计实现组件 API 之前使用 RDD 通常比不用时设计地更好。 2. 面向幸福设计太长不看版 通过删除冗余的状态来减少状态管理的复杂性。 “传递香蕉而不是拿着香蕉的大猩猩和整个丛林“意思是组件要什么传什么不要传大对象。 让你的组件小而简单 —— 单一职责原则。 复制比错误的抽象要“便宜”的多避免提早/不恰当的设计。避免 prop 层层传递又叫 prop 钻取prop drilling。Context 不是解决状态共享问题的银弹。将巨大的 useEffect 拆分成独立的小 useEffect。将逻辑提取出来都放到 hook 和工具函数中。useCallback, useMemo 和 useEffect 依赖数组中的依赖项最好都是基本类型。不要在 useCallback, useMemo 和 useEffect 中放入太多的依赖项。为了简单起见如果你的状态依赖其他状态和上次的值考虑使用 useReducer而不是使用很多个 useState。Context 不一定要放在整个 app 的全局。把 Context 放在组件树中尽可能低的位置。同样的道理你的变量注释和状态和普通代码也应该放在靠近他们被使用的地方。 2.1 删除冗余的状态来减少状态管理的复杂性冗余的状态指可以通过其他状态经过推导得到的状态不需要单独维护类似 Vue computed当你有冗余的状态时一些状态可能会丢失同步性在面对复杂交互的场景时你可能会忘记更新它们。删除这些冗余的状态除了避免同步错误外这样的代码也更容易维护和推理而且代码更少。 2.2 “传递香蕉而不是拿着香蕉的大猩猩和整个丛林“为了避免掉入这种坑最好将基本类型boolean, string, number 等作为 props 传递。(传递基本类型也能更好的让你使用 React.memo 进行优化)组件应该仅仅只了解和它运作相关的内容就足够了。应该尽可能地与其他组件产生协作而不需要知道它们是什么或做什么。这样做的好处是组件间的耦合会更松散依赖程度会更低。低耦合更利于组件修改替换和移除而不会影响其他组件。 2.3 让你的组件小而简单什么是「单一职责原则」一个组件应该有且只有一个职责。应该尽可能的简单且实用只有完成其职责的责任。具有各种职责的组件很难被复用。几乎不可能只复用它的部分能力很容易与其他代码耦合在一起。那些抽离了逻辑的组件改起来负担不大而且复用性更强。如何判断一个组件是否符合单一职责可以试着用一句话来描述这个组件。如果它只负责一个职责描述起来会很简单。如果描述中出现了“和“或“或”那么这个组件很大概率不是单一职责的。检查组件的 stateprops 和 hooks以及组件内部声明的变量和方法不应该太多。问问自己是否这些内容必须组合到一起这个歌组件才能工作如果有些不需要可以考虑把它们抽离到其他地方或者把这个大组件拆解成小组件。 3. 性能优化技巧如果你觉得应用速度慢就应该做一次基准测试benchmark来证明。 面对模凌两可的情况拒绝猜测。 多使用 Chrome 插件 - React 开发者工具的 profileruseMemo 主要用在大开销的计算上。如果你打算使用 React.memo, useMemo, 和 useCallback 来减少重新渲染它们不该有过多的依赖项且这些依赖项最好都是基本类型。确保你清楚代码里 React.memo, useCallback 或 useMemo 它们都是为了什么而使用的是否真的能防止重新渲染是否能证明在这些场景中真的可以显著提高性能? Memoization 有时会起到反作用所以需要关注优先修复慢渲染再修复重新渲染。把状态尽可能地放在它被使用的地方一方面让代码读起来更顺另一方面能让你的 app 更快(state colocation状态托管)Context 应该按逻辑分开不要在一个 provider 中管理多个 value。如果其中某个值变化了所有使用该 context 的组件即便没有用到这个值都会重新渲染。可以通过拆分 state 和 dispatch 来优化 context。了解下 lazy loading懒加载和 bundle/code splitting代码分割。长列表请使用 tannerlinsley/react-virtual 或其它类似的库。包体积越小app 越快。你可以使用 source-map-explorer 或者 next/bundle-analyzer(用于 NextJS) 来进行包体积分析。关于表单的库推荐使用 react-hook-forms它在性能和开发体验各方面都做的比较好。 4. 测试原则测试应该始终与软件的使用方式相似。确保不是在测试一些边界细节用户不会使用看不到甚至感知不到的内容。如果你的测试不能让你对自己的代码产生信任那测试就是无意义的。如果你正在重构某个代码且最后实现的功能都是完全一致的其实几乎不需要修改测试而且可以通过测试结果来判定你正确的重构了。对于前端来说不需要 100% 的测试覆盖率70% 就足够了。测试应该提升你的开发效率虽然维护测试会暂时地阻塞你目前的开发但当你不断地增加测试会在不同阶段得到不同的回报。我个人喜欢使用 JestReact testing libraryCypress和 Mock service worker。End翻译的不好请大家见谅。如有任何想法欢迎评论交流参考资料[1]https://github.com/mithi/react-philosophies: https://github.com/mithi/react-philosophies[2]mithi: https://github.com/mithi[3]【你不需要系列之“你不需要 Lodash/Underscore”】: https://github.com/you-dont-need/You-Dont-Need-Lodash-Underscore[4]【你不需要系列之“你不需要 Momentjs”】: https://github.com/you-dont-need/You-Dont-Need-Momentjs[5]【你不需要系列之“你不需要 JavaScript”】: https://github.com/you-dont-need/You-Dont-Need-JavaScript················· 若川简介 ·················你好我是若川毕业于江西高校。现在是一名前端开发“工程师”。写有《学习源码整体架构系列》20余篇在知乎、掘金收获超百万阅读。从2014年起每年都会写一篇年度总结已经坚持写了8年点击查看年度总结。同时最近组织了源码共读活动帮助3000前端人学会看源码。公众号愿景帮助5年内前端人走向前列。扫码加我微信 ruochuan02、拉你进源码共读群今日话题略。分享、收藏、点赞、在看我的文章就是对我最大的支持~