网站开发毕设题目,做电影网站会不会侵权,wordpress改成ajax,官网争锋大家好#xff0c;我是若川。面试、学习源码系列、年度总结、JS基础系列译者注#xff1a;本译文是在「在线对话 React.js 核心开发者」一个半小时直播的基础上进行的原文翻译#xff0c;包括了直播中的所有问答内容#xff0c;尽可能保留了 Dan 回答的中心语义#xff0c… 大家好我是若川。面试、学习源码系列、年度总结、JS基础系列译者注本译文是在「在线对话 React.js 核心开发者」一个半小时直播的基础上进行的原文翻译包括了直播中的所有问答内容尽可能保留了 Dan 回答的中心语义部分表达为了语句通顺、方便理解适当使用了成语或短语替代。文章超过 1.5w 字文中包含了大量的专业概念与启发性思想通读大约需要 30 分钟。建议先收藏下来慢慢阅读。最后祝大家都能够有所收获主持人Hi Dan来跟观看直播的小伙伴们打个招呼吧Dan嗨大家好主持人现场大多数人都已经认识你了可不可以再介绍你一下你自己Dan谢邀我是 Dan是 React 的核心维护者之一过去 5 年一直在 React Team 工作。这差不多就是我的自我介绍了。 12 岁开始编程 主持人我从你的博客中看到你从 12 岁就开始编程了非常的厉害你是怎样对编程产生兴趣的呢Dan应该说是机缘巧合吧我其实并不是自己主动去学习编程的。当时在学校做作业的时候我很喜欢做一些展示。我不知道大家现在还用不用 PPT 当时我用的是 PowerPoint 2003PPT 中内置了一种编程语言。如果你点击右键打开菜单可以完成一些宏录制的操作。这些操作会产生很多小的程序我起初不知道它们是什么但是我非常的感兴趣之后我就买了一些书从此开始了编程的学习。 React 状态管理工具 主持人这是你第一次和中国的工程师见面我们这边准备了很多问题你准备好回答热心网友们的提问了吗Dan我准备好了。主持人你对 React 状态管理工具怎么看的Dan我想不同的人可能会选用不同的库如果要我来做推荐的话我可能不会去推荐任何一个特定的库。真正重要的问题不是选择什么状态管理库而是理解「状态」的类型理解「状态」是什么。因为「状态」是一个比较笼统的、比较大的概念我认为我们不应该去浮于表面地去讨论哪个库更好而是去看你要处理的状态是什么种类使用这些库的目的是什么选用不同方案带来的差异是什么。比如说有一些 UI 状态针对的是显示的 UI 组件。针对文本输入框来说文本内容有哪些文本是否被选中是否处于 focus / hover 状态或者是记录当前页面被选中的 Tab 之类的这些都是 UI 的状态。另一种状态更像是 cache缓存从服务器返回的数据它可能更像是某种草稿。所以我们需要结合实际的需求去选择状态管理工具。对于 UI 状态来说我个人不推荐使用任何库使用 React 自带的状态就够了。可以使用 React State 或者是 React Context通过组件树将状态传递下去。对于数据缓存的场景来说我并不推荐使用 “状态管理” (此处 Dan 用手比了个引号 ✌️✌️)相关的解决方案。我更建议你使用一些专门用来处理数据缓存的库比如 React QueryApollo 和 React Relay。主持人现在很多人都想用 React Hooks 和 Context 去代替 Redux你刚才的回答也提到了类似的点你可不可以分享一些 React Hooks 背后的设计理念?Dan现在 React Hooks 只能被用于函数组件我们也没有计划让它们兼容 class 组件因为这是两种不同的范式把它们混淆在一起并不合理。我认为这更像是一个关于 Hooks 设计理念的问题我不确定应该怎么回答。总的来说Hooks 某种程度上反映了我们是如何看待 React Component 的。从概念上讲Component 就是一个函数它接收一些 props 属性然后返回 UI。Hooks 是对这个函数的一个增强组件树上有了状态的一席之地你可以用 Hooks 去记录状态或是去记录行为等等。这就是一个大致的思路。顺着这个思路走下去React 可能不像一个库你可以把他想象成是 UI 的编程语言。在编程语言中我们有函数、变量这些概念。如果把 React 看作是一门 “伪” 编程语言的话Component 就对应编程语言中的函数而 Hooks 就对应变量。这是我自己的想法不知其他同学能不能 get 到。 快速上手 React 主持人很多开发者认为 React 的入门非常的难所以有没有推荐新手快速上手的方法Dan我认为这取决于大家为什么觉得入门很难大家遇到的问题可能不尽相同。其中一点是React 需要你有 JavaScript 编程基础。如果你是第一次接触编程的话确实会比较困难因为它不是使用 HTML 和模板进行网站搭建的。对于有些库和框架你从模板开始在模板上添加一些条件判断或循环通过不断的小修小补你就逐渐学会了如何进行编程。但在 React 这里你是从编程语言开始一上来就要写代码。如果你不会编程React 的学习曲线就比较陡峭。有些人刚接触 React 觉得很难上手等过一段时间学会了 JavaScript 再回来看 React 就不那么困难了这就是 JavaScript 带来的门槛。另一方面我觉得有个好的开发环境很重要。比如 Next.js 或是 create-react-app 这类工具会帮你把项目开发所需的配置都准备好。有时候人们觉得入门难只是因为搞不懂如何才能创建一个单页应用SPA。这些并不是 React 的问题但人们往往会将它们归咎到 React 身上。如果你把 Next.js 作为项目起点的话我觉得会是一个不错的开始。 React 避坑 主持人下一个问题。对于已经开始用 React 的人来说可不可以给一些建议帮助大家避免一些坑Dan有一点很重要如果你使用 React Hooks那么通常都要使用配套的 lint 规则。我们对 Hooks 有两个推荐的规则可以使用插件的方式集成到你的项目里。此外我觉得理解 React 中的两个概念很重要。其一是 不变性immutability 你需要知道如何做到更新 (update) 状态而不改变mutate它。这一点你可以用 扩展操作符...或是其他语法实现。这里推荐一个很棒的库叫 immer它可以让你在编程中使用 Vue / Svelte 风格的变更操作但同时又能够保持不变性。如果你对这点很苦恼的话不妨试一试。另一点是你要理解 React 的渲染流程应当是纯粹的Rendering is supposed to be pure当组件进行渲染的时候它就是在计算下一个 UI 应该长什么样子你不应该在渲染流程中掺杂其他的操作。我认为理解 UI 是计算结果 UI is a calculation这个范式是非常重要的。 函数式编程 主持人目前 React 越来越靠近函数式编程functional programming了但有人说 JavaScript 并不是一个注重函数式编程的语言你如何看待这个矛盾Dan可能 React 确实比其他 UI 库更偏向函数式一些但我不认为它是一个面向函数式编程的框架。人们在这方面其实有个共识那就是所有喜欢函数式编程的人都不觉得 React 是函数式的因为它不够“纯粹”或是一些其他的原因。对于 React我更喜欢「functional-lite / functional-light programming」这个概念。React 从函数式编程中借鉴的一个很重要的思想就是将复杂的事物分解成几个可以组合的函数像是尽可能地去使用不变性immutability)。但 React 的代码看上去并不像传统的函数式编程代码因为 React 倾向于使用更加直接的编码风格。举个例子如果你需要一个循环你可以直接在代码中写循环而不需要写更高阶的函数然后再用复杂的方式将他们组合起来。写 React 的方法就和写 JavaScript 一样所以代码看上去也不像是 Ramda 或者 Lodash FP 那样的「函数式」。所以 React 应该算是处于一种中间地带吧。它既集成了函数式编程的想法与概念又能让你在大多数的时候使用 JavaScript 主流的编程方式去进行编码我觉得这应该不算是矛盾吧。 前端发展太快 主持人目前的前端是一个正在飞速发展的领域你是如何不断提高自己跟随技术进步的脚步的呢Dan很有趣的问题其实我觉得前端的发展并没有那么快。我这些年没有看到太多的新的东西有可能是我自己看的不够仔细吧。不过我看到的大多数成果都是已有功能的迭代与完善。有些东西每一年或者两年发布个新的版本但是大多数情况下不管是新的发行版还是新的库用的思想还是原来的思想。所以如果你对已经存在的东西足够熟悉、理解足够深的话你可能就不会对新出现的东西感到新奇了因为它们某种程度上讲是同质化的东西。所以我觉得准备迎接新事物的最好方法就是去熟悉已有的东西当你足够熟悉之后你看到就只有相似性了。主持人React 的未来发展趋势是怎样的Dan这是个大问题啊像是未来十年的路线图之类的我们现在正在做的很多功能其实都与这个问题相关。 主要问题 主持人那么目前最主要的 Issue 有哪些呢Dan这一点很有意思我们其实在面对很多不同的问题也有不同的 team 在用不同的方式去解决它们。我可以给你举几个例子比如说数据获取data-fetching。如何设计一个具有良好扩展性的数据获取方案使得组件的数量不会引起请求 Waterfall从而保证 UI 的一致性。你可以将逻辑写在离被调用位置更近的地方这样数据和代码就能实现并行加载。data-fetching 是一个相当复杂的问题你还要考虑到如何让用户用着方便现在的 data-fetching 其实还是挺恼人的。这是当下要解决的一个大问题另一个大的主题是各种的优化关于代码分割code-splitting服务器端渲染Server Side Rendering如何将多余的东西从 JavaScript 的打包中剔除出去如何让 Hydration 的花销更小等等。这可能听上去像是一个完全不同的领域但是类似的点还有很多通过这些优化我们可以让 React 从本质上优于第三方库和其他解决方案。另一个大的主题是关于动画animation的但我们还没有开始这个方向的相关工作。但对于上述的所有方向我们都会尝试与以往不同的方案去解决。很多 UI 框架或者库都倾向于去独立应对单点的问题针对单个问题给出不同的解决方案通过提供某些便利的 API 实现更优的开发体验等等。但我们在我们看来有些问题是彼此关联的。我们会尝试使用更理论、更系统的方式串联起相关联的问题然后解决它们。所以如果要我讲 React 未来的样子的话我希望它能够成为一个工具一个帮助我写组件的工具里面集成了 data-fetching代码分割动画渲染等等所有功能而且这些功能都无缝地组合在一起。因为 React 的中心思想就是像乐高一样将各部分功能组合起来我们希望在未来能够支持这些功能。 Concurrent Mode 主持人有些朋友们问到了 concurrent mode 的相关问题。React 的 concurrent mode 自 16 版本就已经提出了但到了 React 18 才终于发布了出来。React Team 在设计这个功能的时候遇到了哪些问题和挑战你们对于这个功能在将来又有哪些计划呢Dan好的我首先要说明一下React 18 还没有正式发布我们目前只为库的维护者们发布了一个 alpha 版本。如果你访问 reactjs.org/blog你会看到一篇名为《The Plan for React 18》的文章。如果朋友们想去了解 React 18 的新功能或者发布的时间计划可以去看一下。我们还建立了一个工作小组并邀请了 50 名左右的社区开发者来协助我们完成一些 React 18 发布的相关工作比如确保整个 React 生态中的库都能兼容新的版本。相关信息都在 GitHub Discussion 里面非组员虽然不能评论但是可以阅读。你可以从中找到很多关于发版的信息其中就包括你问的 concurrent mode 的信息。正如你所说我们在很多年前就声明了要做真正的 concurrent mode不过这期间有一个很大的策略上的变化那就是它不再作为一个单独的模式mode 来呈现。所以我们最终添加到 React 中的可能并不是一个 concurrent mode而是一种并发渲染的机制。本质上来说并发意味着 React 有能力在同一时间更新多项状态。比如你在更新状态的时候有些获取数据的状态更新会花费比较长的时间渲染一个复杂页面的时间成本就会很高。如果使用了并发渲染这些场景下 React 就不会阻塞住浏览器。这意味着页面在进行长时间的状态更新的同时你还可以去输入文字后台的状态更新不会阻塞你的交互。基本上你可以把并发渲染想象成是在后台跑 setState()。这确实是我们一直想在 React 中实现的功能但重要的是它不再是一个单独的模式了。当你需要使用并发能力的时候我们提供了一个叫 Transition 的功能你可以用 Transition 包裹 setState() 的操作这样在调用 API 的时候 React 就会进行并发渲染。所以这个在将来会是一个可以随时调用的特性而不是作为一个 Web 应用的全局的模式他只针对于你包裹的操作生效。就挑战而言我们确实遇到了不少挑战。因为我们是从理论出发的我们得出了很多理论性的想法比如我们认为「并发是好的」「长时间阻塞浏览器是不合理的」「渲染应该是可以被打断的」等等。然后我们基于这些想法着手去做在 2015 年完成了一个原型之后又重写了 React 来让它能够真正实现这些想法这就是 React 16 版本。之后我们确实花费了几年的时间来思考如何能够将这些功能应用到实际生产中。全新的 Facebook 官网 facebook.com 就使用了 React 的并发特性。诸如 「渲染应该是可中断的」「setState() 应该是并发的」以及「渲染应该在后台完成」这些小小的想法实际上带来了很多的后果这也是我们花了一段时间才意识到的。这些特性带来了更好的服务器端渲染server-rendering)更好的代码分割 (code-splitting) 和更好的数据获取data-fetching)在将来我们还会用相同的思路去实现更好的动画效果。这个想法在很多地方都得到了体现因为它本质上为 React 提供了让渲染能够「异步」的能力这个世界上有很多东西天生就是异步的比如我上面提到的那些功能。梳理这些功能搞清楚怎么让他们一起运作起来确实花了我们不少时间。但我们现在基本上都已经搞定了这些特性都会集成到 React 18 里面。所以我再一次建议感兴趣的朋友去 React 官网的博客查看 React 18 的发布计划点击相关的讨论区查看相关的细节。 体验 React 18 Alpha 主持人所以听众们现在就可以使用 React 18 Alpha 版来体验相关功能了对吗Dan是的但有两点需要注意。其一是要去博客看一下新版本的使用说明。比如项目升级了版本之后可能需要将 ReactDom.render() 方法替换成 ReactDom.createRoot() 方法诸如此类会有一些新的 API 进来如果你不做替换的话程序可能会报 warning但这就是你开始使用新特性的方式。另一点是 strict mode 的用户们需要注意的新版的 strict mode 会更加严格这就意味着原有的东西在新版本下可能会 break 掉。所以如果你的程序在新版 React 中完全跑不起来了可以尝试移除 strict mode可能就是这个原因导致的。还有一点需要记住的是alpha 版 React 主要是为库的开发者们提供的版本有很多库比如 Redux 等本身还没有更新支持。所以如果你的项目依赖了大量的第三方库那你的项目在更新 React 18 后很可能会崩溃但这就这个发行版的目的让库的作者有充足的时间去做升级。所以如果你发现你的项目在新版 React 中完全运行不了也不要灰心尤其是那些因为引入第三方库导致程序崩溃的用户们等到 React 稳定版发布的时候大多数流行的库应该都已经修复了问题并且做到了兼容。 React Lane 主持人能简单介绍下 React Lane 是怎么设计的吗Dan这是一个相当技术性的问题。我们其实不希望别人知道有 React Lane 这个东西因为它不是一个公开的 API而是一个涉及到 React 内部实现的东西。但我可以简要说明一下它是什么。正如我上面说的我们为 React 添加了并发的功能这意味着任意时刻都有可能有多个状态在同步更新。并发对于我们的 Transition 特性尤为重要。比如说你在输入框进行输入回车后页面更新这是一个常规的页面更新操作。但如果你想要在输入的同时实现自动补全或者想要从网络上获取候选项列表需要连接后端从前的做法是你使用 useEffect 自己去管理这些异步渲染的流程。但现在我们会在 React 内置这套流程你可以用同步的代码写法来处理异步的数据操作。我一直认为 UI 是一个瞬间的状态state in time)或者说瞬间的时刻moment in time所以要表达这一点你应该为列表的结果创建一个 Transition这样浏览器请求可能会花费一些时间但是等数据回来的时候 React 会负责正确地去展示结果。Lanes 是一个 React 内部的机制用来标记 React 当前正在处理哪项状态的更新。你可以想象当你每次调用 setState() 的时候React 会把他加到一个 bitmask 中类似于很多的开关switch或者是复选框checkbox。有点像是任务列表如果你用过任务列表你就知道任务有高优先级和低优先级。或者是 Github 上的 LabelLabel 可以用来标记是高优先级也可以用来标记 bugfeaturediscussion。同样对于 setState() 来说React 也提供了一组标签来标记它是不是 Transition是否是一个紧急更新等等这个标签就是 Lane。当 React 进行渲染的时候它会根据 Lane 来选择哪些状态更新需要被执行。如果有一个紧急的状态更新需要一次紧急的页面重新渲染这时候就只会执行在 Urgent Lane 下的状态更新。之后如果所有紧急的更新操作都完成了我再去检查 Transition Lane 中的状态更新如果这个时候从网络上返回了数据那就把它渲染出来比如去加载自动补全的候选项列表。所以说 Lane 是 React 的一个内部机制使用 bitmask 来将状态更新与优先级关联起来之后 React 再根据它去更新状态。 React Server Component 主持人Server Component 的 RFC 草案去年年底发布了请问 Server Component 的主要目的是什么。Dan是的我们去年 12 月发布了一个 Server Component 的技术预览但它还处于比较早期的阶段。这应该算是一个还处在研究阶段的特性与 React 18 相比更偏实验性也不会包含在 React 18 的特性之中可能会在其之后才发布。但广义上来说它与 SSR 并不一样这也是人们常常混淆的点。最大的区别是Server Component 只运行在服务器上它不会被下载下来。你可以把它们想象成某种 API以往的客户端应用可能会请求 JSON API 来获取数据 Server Component 与之类似但是 API 换成了在服务器端运行的组件。这样做的优势是你不需要去下载任何代码可以达成性能上的优化。另一个优势是因为这些组件运行在服务器端它们可以直接与数据库、微服务、或者其他任何在这台服务器上的资源进行通信。你不需要把这些资源暴露给客户端就把它们留在服务器上就好。主持人有些用户已经尝试过使用 Server Component 了所以当我们需要在项目中使用服务器组件的时候我们需要维护三个组件而不是一个这带来了额外的复杂性不是吗Dan好的对于这个问题我个人其实不太认同这种说法。我不想把这个问题定义为我们需要维护三个组件而非一个。我觉得更准确的说法是在传统的 React 中我们只有一种类型的组件而在 Server Component 中我们把它们分成了 Server ComponentClient Component 和 Shared Component。这个问题就好比你原本只有一部手机现在你既有手机、又有手表、又有电视但这并不意味着你要同时去用这三个东西你只是有了更多的选择。所以对于这个问题而言不是说你的组件在将来都会以三种形态存在而是你现在只能用 Client Component 的组件。如果只用 Client Component 能够满足需求的话固然很好但是当这个 Server Component 这个特性落地的时候你会有更多的选择来做相同的事。到那个时候如果你想要使用 React 写博客想要读取文件系统这些操作不需要很多复杂的框架也能做到。如果你只是想要使用 PHP 或者 Rails 类似的传统 web 编程风格去做一些数据库的读取操作Server Component 也能帮你做到。在大多数场景下我们预期用户们会通过框架来使用 Server Component 功能比如使用 Next.js。所以幸运的话你并不需要想太多也不需要创建什么 API你只需要在文件名中加上 .server.js这个文件就可以在服务器端运行你就可以使用所有 Server Component 的功能了。主持人所以我们可以直接通过一些框架来使用这个功能Dan是的我觉得大部分情况应该都是如此。因为框架就像是整个项目的基础设施一样会为你连接并组织好项目的各个部分。虽然你也可以去手动配置但是肯定不如使用框架来的方便。特别是框架还可以实现无配置的启用这些功能如果你要自己动手你就得自己把项目的各个部分串联起来。目前我们还没有针对如何使用 Server Component 给出使用的建议但是鉴于 Next.js 已经支持了 Server Component如果你想要部署自己的 Server Component你可以去看看他们是怎么实现的然后复制他们的做法。又或者你可以直接使用 Next.js 或者其他类似的框架。 React 与 Vue 主持人人们常把 React 与 Vue 作比较。你个人是如何比较这二者的呢希望能从设计、性能和使用目的来谈一谈。Dan首先我个人没有使用过 Vue所以我可能做不了特别详细的比较。从技术上来讲两者可能采取了不同的实现方式吧。Vue 建立在 mutability 的基础上可以直接去修改 state。这样做带来了一些好处它写起来更简单你可以用 mutative style 去写代码这种写码方式也受到了许多开发者的喜爱。但它也有一些缺陷比如站在更高的层次来看有些功能可能是出了名的难以实现或者根本不可能实现。比如我们正在做的 Transition 功能又或者是我们想要做的新的动画特性。二者之间的差异太大就像被一道深深的技术鸿沟隔开了Vue 在不断探索我们可以用 mutability 做什么而 React 在不断探索 immutability 能够做到的事。但我们对自己的方向非常有信心因为我们的背后有近 50 年的函数式编程的研究成果所以我们明白虽然在落实到实践中可能会遇到一些困难但是从理论分析的角度我们的方法还是合理的。Vue 和 React 只是在探索两个不同的方向这件事很好你只需选择自己喜欢的那个就好。谈到设计的话我觉得二者最大的区别是 Vue 更倾向于去做一些妥协与折衷也更关注能不能去解决实际的问题。比如它会提供一些人们呼声很高的功能包括更加便利的动画更加便利的条件渲染、组件模板等等。但 React 可能不太一样我们希望确保 React 提供的每个解决方案都是完全可靠的、可信赖的。所以对于某些仅为了方便而存在的功能我们抱着宁缺毋滥的态度宁愿不去实现它们。比如 React 想要重做动画功能我们最终交付给用户的功能一定比现有方案快上好几倍。我们不会去标准化一些现有的方案因为我们对如何实现动画这个功能有自己的构想这个构想会与 React 库深入结合它会不同于我们现在看到的所有框架。所以说在 Vue 中你可以更快地得到自己想要的功能但是在 React 这里你可能找不到自己想要的功能只能依赖第三方库来实现直到我们搞清楚解决问题的方法知道如何把这个功能做对、做好我们才会把它集成到 React 中来。这就有点像 Android 和 iOS 在设计理念上的区别。iOS 相对 Android 就经常会少一些功能比如最初几版 iOS 连复制粘贴的功能都没有直到出现了通知中心才有了复制粘贴功能。iOS 的特性可能确实会滞后一些但是当它确定要做某件事的时候它会把他实现的非常好我想这也是我们的工作理念。我认为两种思路各有优劣吧。 Flow 与 TypeScript 主持人Vue 3 已经不再使用 Flow 了而 React 还在使用对这一点你怎么看Dan我不觉得这一点很重要啊。这更多还是取决于库本身是如何编写的我们目前还是需要去做一些静态的类型检查。不过这与用户们使用的 React 类型没有关系只影响 React 库自身的开发。我们使用 Flow 只是因为我们一开始就用了它它也能满足我们后续的需求。我们也可以使用 Typescript但我觉得这不是很关键。这完全不会影响到 React 的用户因为我们内部的类型和我们暴露出去的类型也有差异。所以这件事不是很重要我们并不 care。我们当然可以切到 Typescript但迁移成本较高不值得我们这样做。 React 的竞争力 主持人最近有些新出现的前端框架比如 Svelte 和 Solid-js他们都不再使用 Virtual-DOM 了并且声称在性能表现和 bundle 体积上都超越了 React你怎么看待这一点Dan还是一样我没有深度地体验过这些框架所以我不太好下论断。但还是那句话看上去总有新的东西在出现但其实并不是这样的。真正能够走通的设计思路其实并不多React 在走 immutable 这条路Vue 和 Svelte 在走 mutable 这条路然后 Svelte 和 Vue 之间在具体实现上可能会有些差异Solid-js 应该也是这条路上的一个分支。说到 Virtual-DOM我其实不是很喜欢这个术语。我们尽量不去使用这个词因为每个人对它都有不同的理解。但我觉得它不是一个与性能有关的东西。我想再重申一遍我不愿去使用 Virtual-DOM 这个词因为它是一个非常容易混淆的概念。当我们提到 “Virtual-DOM” 这个词的时候我们说的其实是一种 UI 在内存中的表现形式。这应该是你期望得到的东西因为它为开发者提供了更多的选择。比如 Server Component 是运行在服务器端的但是它需要定义一个数据格式来传递服务器输出的结果然后在客户端接收。如果你使用 Server Component 做了一个页面过渡的效果你肯定希望将它与现有的 UI 合并起来。但这一点又跟 PHP 或者 Rails 那种传统的客户端渲染不一样传统方法渲染的时候老的页面会消失然后新的页面逐渐加载它并不保留任何的状态。如果你有一个搜索框你输入一些东西点击搜索跳转到新页面此时搜索框会被清空。但使用 Server Component 不会发生类似的事情我们把组件树发回给客户端我们可以在客户端中将它和现有的 UI 做 diff 然后渲染有差异的部分所以搜索框的状态可以被保留下来。该被替换的组件替换了这一点之所以能够实现是因为 UI 在内存中有一种中间态的表现形式它就是人们说到的 Virtual-DOM。这是用来说明 Virtual-DOM 作用的一个例子。另一个例子是如果我们现在要将一个完整的动画系统集成到 React 中我应该怎么做。比如我们现在要做一个手势拖动触发的动画我们肯定不希望每一帧都去做渲染我们希望只计算几个版本的 UI。假定最左边是 0% 的版本最右边是 100% 的版本我们计算好几个类似的关键帧在拖动的时候就可以利用插值计算出当前 UI 样子。但问题又来了你怎么去生成那些关键帧呢你需要一个 UI 在内存中的表现形式这样你才能在两者之间做插值。这个例子也说明了 Virtual-DOM 的意义有些特性离开它就没法实现。所以 Virtual-DOM 与性能无关它的存在只是为了让一些特性变得可行我们认为这种 UI 在内存中的表现形式还是很重要的。尽管在一些综合性测试里面我们可能会比其他方案慢 10% 左右但你应该明白这并不是一个问题。至少在我们的测试中当我们分析 Facebook 一些复杂页面渲染的时候。我们亲眼看到的是React 只花费了 10% 的时间另外 90% 的时间开销是应用代码导致的。框架能够优化的可能也就只有 2% 的速度。所以当你去看那些测试的时候测试代码可能有 1000 行但是只有一个 component。你可能就只关注到了那 2% 的差异但它并不能反映应用的实际表现。所以真正影响性能的是整个 app 如何工作以及我们如何能让用户代码运行的更好。这就是 Concurrent RenderingServer Component 以及所有新特性存在的意义。我们要去支持更大规模的用户代码而不是试着去赢下这些基准测试比赛有些基准测试只有一些不到 10 行的小组件 它们不值得我们付出时间和努力。主持人最近有很多新的库出来了人们想知道 React 如何做到跟上潮流保持竞争力。Dan是的我想我已经从某种角度上回答了这个问题。我们正在努力从全局出发用更加通用的方式去处理那些从单点很难以解决的问题比如说 data-fetching代码分割未来还有动画以及其他的功能React 在将来能让它们的实现变得更简单。我猜这就是 React 竞争力的来源吧。不过我个人觉得 React 并不需要某些特性来让它“保持”竞争力。比方说当我要用 React 做一些原型的时候我要去画一些 UIReact 用起来会很自然很顺手。即便 React 在将来五年没有新的 feature我也会觉得使用嵌套的函数来表述 UI 是一件很自然的事情。我觉得这种开发方式很合理我也很喜欢 React 现在的样子所以我并不觉得 React 要变得更加 “有竞争力” (Dan 用两只手比划了引号)人们才会使用它。但我还是要重申一下我们现在正在做的很多功能可以让当前复杂的开发工作简单化我对它们的存在感到兴奋。 SSR、CSR、NSR、ESR 主持人Vue 和 React 都在解决网页渲染的问题但是当前渲染网页有很多种方法像是 SSR(Server Side Rendering) CSR(Client Side Rendering) NSR(Native Side Rendering) ESR(Edge Side Rendering)你是怎样描绘未来五年前端的发展的呢Dan这个问题是说你有很多种不同的方式来运行你的代码你可以让它在客户端运行、在服务端运行或者在其他地方运行问题在于你如何去组织它们。但我觉得这里的大部分工作应该都会由框架来完成所以再说一遍吧我还是推荐你去使用框架。像 Next.js 就是一个不错的选择它能让你对这部分如何实现有一个大体的印象。Next.js 可以通过对 React 现有概念的包装来简化这部分的操作比如你要使用 Server Component 的话Next.js 有他自己的 APIgetServerSideProps() 或者是类似的方法你不需要使用 React 原生的方式的去组织项目Next.js 会通过它自己的 API 将你的项目编排好让 Server Component 等类似的功能生效。所以我觉得未来... 哦我突然想到如果你对 Server Component 感兴趣的话不妨去看一下 Shopify 家最近新出的框架Hydrogen。他们最近放出了一个 Demo 演示如果你搜索 「Shopify Hydrogen Demo」 或者类似的关键词就能看到里面演示了他们是如何使用 Server Component 的这也是对未来场景的展望吧。如果你只有一个渲染树比方说你在写页面或是写个博客网站你只需要去在服务器端的文件系统中读取一些 Markdown 文件然后将它们渲染到组件的对应位置最后把渲染好的组件传递给客户端你只需要考虑组件就 OK 了。至于在哪里执行代码逻辑这完全是由你自己决定的。有些可能是在构建的时候执行的有些页面如果你愿意的话也可以在服务器端运行只有那些与实际交互相关的代码会被下发到客户端然后在客户端运行。理想情况下这整个流程还是一个单一的渲染树你不必去实时关注这部分的差异。你只需要给一些小提示比如修改一下文件的扩展名代码就会自动地在最合理的位置去执行。所以你不用想那么多想自己既要做服务端渲染还要做客户端渲染有可能还要其他端的渲染。框架会帮你把这部分搞定的你只需要使用同一个范式来写代码它在所有位置都可以生效。 React 与框架 主持人如何评价「React 更像是一个系统而非一个框架」这种说法Dan我不会说 React 自身是一个框架我认为这个说法并不公平。首先我认为 React 只是一个库因为它并没有去约束你工作的方式没有去约束你项目的结构它只是给你提供了工具让你能够去构建组件。但我确实觉得 React 正在成为一种架构Architecture但这和框架又有所区别。因为想要新建一个 React 的框架其实有很多种方式但是现在 React 对某些技术的实现也有了自己的「观点」比如应该如何进行 data-fetching如何去做路由如何去做服务器端渲染这些功能应该怎么组合起来。React 只是一种构建 UI 的方式而不同的框架可以基于这点为用户提供更加上层的能力。 吸引前端开发者特质 主持人你认为好的科技公司最吸引前端开发者的特质有哪些能不能简单列举两三个Dan嗯我想一想。我觉得最重要的一点是「要能够从身边的人身上学到东西」。对我来说有一个能够无时不刻学习新事物的环境是最重要的。当然这不是说你要去不断学习新的库不要因为对前端这一领域全貌的不了解就说「前端一直在变化」这种话。我认为事实并不是这样的。正如我说的大多数新事物都只继承了旧的思想虽然层出不求却只有相同的本质。如果你往更深的地方去探究你就会发现它们都是同一个东西。但我觉得理想的环境就是公司 / Team 鼓励你去学习新的知识团队中有 10 年或者 15 年工作经验的前辈你可以从他们那里获得收获。组内的高度自治也很不错你不会被安排去做特定的工作你可以从任务清单中完成自己想做的工作这一点也会让工作更有趣。被动的激励自然很重要但如果你能够发挥主观能动性作出自己的选择那也是非常有价值的。我不知道这是否回答了你的问题。 如何学习 React 代码 主持人很多朋友对你的个人经历感兴趣你刚加入 Facebook 的时候是如何学习 React 的结构、概念并慢慢开始贡献代码的呢DanReact 有一个相当复杂的 codebase里面有很多复杂的上下文导致很难上手。一般来说当有新组员加入的时候我们会花很多时间陪他们一起看一遍代码。刚开始他们可能会做一些小的 bug 修复或者相对独立的小功能点来慢慢地熟悉代码。整个流程最关键是要熟悉架构一旦你对整个项目的架构有了充分的了解接下来的所有工作就都顺理成章了。有一个对我帮助很大的点那就是去查看人们的 Issue并去解决他们。在不同的时间点上我都会过一遍现在处于 「Open」状态的所有 Issue看看自己是不是能够解决这些问题思考一下自己是不是能够理解他们在说什么如果不懂的话就去学习上下文。我想我个人可能已经看了数千个 Issue 了如果你想要快速上手项目的话我认为这是一个非常不错的学习方式。你可以点击查看处于「Open」状态的 Issue应该差不多有 500 个你可以从头看也可以跳转到最后一页从最老的那个开始看。通过看 Issue 你逐渐就能理解当前有哪些问题慢慢地去理解代码理解项目的更新历史等等所以这就是通过 Issue 学习的方法。帮助提出 Issue 的人在我看来是做贡献的最好方式实话说我们并不需要人们去贡献那么多的代码通常 Review 代码也需要花费我们很长时间而且人们其实很难把功能写对。所以当我们收到社区提交的代码的时候我们其实并没有从中收获很多。但替我们回答人们的 Issue 确实对我们很有帮助有时候用户提交了一个 Bug 报告但实际上是他们自己写的代码有问题。如果社区中有人帮助他们发现了问题找到了 bug我们就不用再在这些 Issue 上花费时间了这也是我最欢迎的贡献方式。 维护 React 主持人React 有一个非常庞大的 codebase 请问 React 开发组和社区是如何维护如此复杂的代码仓库的Dan代码仓库确实带来了一些挑战但是有挑战的原因不是因为代码仓库大而是因为一些其他的原因。首先你要知道怎么去进行开发怎样把代码跑起来。举个例子我们依赖了非常多的自动化测试大概有数千个测试要跑吧我觉得数量可能在 5000 个以上。目前我们写的测试代码可能比源代码还要多我们非常依赖这一点。我们从中学到的一点是一定要去针对 React 的 public API 写测试脚本。我们之前的做法是对独立的模块进行单元测试但这对 React 这种项目来说是一个非常糟糕的想法因为一旦你要重写 React那些针对老代码的测试用例就没用了。在我们重写 React 的过程中我们不断地意识到「哦又有一堆测试代码不能用了因为之前的代码不存在了」。所以我们把所有的测试用例修改成了仅对 public API 进行测试来模拟用户的实际行为。测试用例只能用 ReactDom.render() 或者类似的方法并不能访问内部的 API。在只针对 public API 进行测试的情况下就算我们替换了原有的文件测试样例也照样能够跑通还能顺便测试我们的重写是否是正确的。这算是我们从实践中总结出的经验吧。另一个有趣的点也可能是比较有争议的一个点就是我们有很多文件都存在两个版本。如果你看源码的话你会发现我们有 .old.js 或者 .new.js 这种文件。这些文件基本上是复制粘贴出来的它们的内容也基本相同。我们用它们来测试一些可能会带来风险更新对于 Facebook 网站我们可以同时部署多个版本。我们有时候会将这些实验性的更新写到 .new 文件里面然后在 Facebook 的实验环境里面进行回归测试如果测试各项指标没有劣化的话再将这些更新复制到 .old 文件中去所以说我们的网站在任何时刻都有两个版本。在实验测试的过程中其他人也可以去做其他部分的代码提交。这听上去可能比较奇怪但实际用起来效果还是不错的。主持人所以这就是你们在开发中保持 React 代码质量的秘诀吗Dan是的我觉得是 Facebook 的测试环境真的非常好我们不仅有针对 React 仓库本身的测试还有很多针对 Facebook 进行的测试。有时候我们在 React 的开发过程中把功能搞坏了我们可以在测试环节发现问题。在生产环节中甚至是生产环节之后我们都可以部署实验测试然后去观察哪些指标出现了下降。比如我们去年十月进行了一次重构那之后我们不得不将手头的工作暂停了两个月因为我们看到某些指标下降了 1%我记得好像是网站的评论数之类的少了 1%。我们就要查清楚到底是由性能问题导致的还是因为 bug 或者其他什么原因。你要知道其他的框架往往做不到这一点它们往往需要先发布一个版本然后可能一年之后才会有人发现里面的 bug然后上报。但我们不会这样做我们要确保 React 的高质量所以我们花费了数月的时间来查这个问题。用二分法不断地分割 commit 提交不断地去做实验测试甚至要精确到每个 commit。最终我们找到了 bug我们部署的测试环境中确实有一个 bug。当我们将其修复之后各项指标就再次回归正常了这个结果也给了我们信心。你要知道在 Facebook 这种体量的公司中即便只有 1% 的指标劣化也会影响数百万人。所以如果有大的问题的话会比较容易发现。 阅读 React 源码 主持人作为一个使用 React 的前端开发者我们需要去阅读 React 库的源码吗如果需要的话有没有好的阅读代码的方式Dan我觉得没有必要这可能会是一项相当困难的工作因为我们没有在任何其他地方提及 React 自身的架构是怎样设计的。如果你上来就开始读代码你可能会感到非常困惑不明白为什么这样设计。这可能也是我们将来需要改进的一点将来到了某个时间点我们可能会去解释这里面的实现原理。但我觉得如果你只是想玩玩的话这个过程应该也算不上痛苦。比如我自己就很喜欢做一件事用 debugger 的步进功能step-in) 来一行行跑代码看看代码会跑到哪个函数运行代码会用到哪些不同的文件。另一件你可以做的事是使用 Chrome Performance Tools你可以打开 Chrome 的 Performance Tab点击录制然后在你的应用中进行一些操作之后点击停止你会看到一张火焰图或者火焰表。这个分析结果非常有用它就像是某种堆栈你可以看到函数的调用顺序看到代码中正在发生的事。它常用来测试性能你可以看到你代码中的哪一部分运行的比较慢但你也可以用它来做一个当前函数总览因为上面展示了函数的名称。你可以看到状态变化会引发哪些不同的事情。你可能会发现「哦这个函数在所有的地方都被调用了它是做什么的」。之后你可以点进去看看里面到底执行了什么。沿着这种性能测试来一步步探索代码我觉得也是一个不错的学习方式可以了解到 React 在哪部分花了时间哪些函数是其核心之类的。 保持对 React 热情 主持人你是如何保持对 React 的热情的Dan我就是很喜欢不知道为啥仔细想想的话可能是因为 React 非常符合我对 UI 代码的看法吧。在进入 Facebook 之前我就开始使用 React 了那时候我还在一家小的创业公司。我们当时在开发一个非常复杂的应用试着将它从 Backbone 迁移到 React。我们迁移不是因为当时 React 是大趋势而是因为当时用 Backbone 开发一个复杂的 UI 真的非常的困难相比起来用 React 来实现真的是太简单了。其中心思想就是写一个状态的函数来表述当前屏幕上应该展示哪些东西。这也是我常常问自己的问题我的组件应该长什么样子哪些内容应该展示在屏幕上。这种思想和我的编程思路天然就是契合的。但确实有些东西不太好归纳到这个范式里边比如 data-fetching 就是一个典型。你真正想要考虑的是屏幕上有哪些内容但一涉及 data-fethcing你就要去思考如何与服务端通信、怎么等待服务端返回结果、等待的时候可能还要设置某个状态这样用户再次发起请求的时候才能忽略掉上次请求的结果。我原本只想考虑哪些东西应该展示在页面上但这些东西却将问题复杂化了。这也是我们想要为用户提供 data-fetching 能力比如 Suspense 功能的原因它可以帮助你减少思考问题的复杂性。我只要考虑想要看到什么从哪里获取即便是外部 URL 也不用去考虑时间。我只想要表达目前屏幕上存在哪些东西之后交由 React 决定如何去展示它们。我觉得让我非常激动的一点是现在 React 已经能够很好地实现 UI 的组合与嵌套了但是还有 data-fetching动画代码分割data-asynchronous 这些目前难以实现的东西我希望这些功能能变得更加简单易用。我希望在五年以后我们能够用更加简单的方式构建复杂的应用而这份简单来源于 React 帮助用户处理了这些复杂性。这就是我的想法。 如何像你一样优秀 主持人如果我想要变得和你一样优秀有没有什么好的前端学习资料可以推荐的Dan我不确定自己算不算优秀我其实在很多方面都没有跟上时代的脚步。比如如果你让我去做一个好看的应用可能很难去完成。因为我对 CSS 的知识还停留在 2010 年我对于 CSS Grid 和 Flexbox 也并不是非常了解我不知道这是不是你希望听到的。但是如果你需要我推荐学习资源的话我觉得一个很有帮助的点是你可以去挑选一些 UI 的样例然后从零去实现它们。这个过程中不要去使用 React也不要去使用其他任何库。比如试着去实现一个带自动补全的输入框或者是对话框中的一个 tab 之类的体验一下完成这些操作的复杂度。另一点我很喜欢的是做一些小游戏这也很有帮助比如做一个井字棋或者是贪吃蛇。做游戏会推动你去思考思考程序如何去设计思考如何去解决问题而这一点是你平时写表单、写界面所训练不到的。总结来说我推荐你做一些体量小但是有深度的东西然后从中获得收获吧。 如何度过闲暇时光 主持人请问工作之余你是如何度过你的闲暇时光的Dan我工作之余并没有做太多有意义的事。我过去非常爱玩堡垒之夜我玩的其实并不是很好但还是玩了很久。我建筑建的很烂如果有人打我我就建一堵墙但通常我都会被吓一跳然后手忙脚乱地溜走。但我其实也有一阵子没玩了。现在的话一般就听听歌散散步做一些业余项目之类的。 justjavascript.com 主持人你写了一个 「Just Javascript」 的系列文章我个人也非常喜欢这个系列已经等不及要看下一期了想问一下新文章的进展。Dan好的有些朋友们可能还不知道这其实也是我个人的业余项目叫做 justjavascript.com。它像是一个 JavaScript 的课程它现在还是免费的但是再过几周可能就不免费了。这个课还是很特别的它不像其他课程一样用传统的方式讲 JavaScript 的知识它更多是去教你怎么理解代码课程里面有很多可视化的东西比如动画呀、图表呀之类的。它也会教你去从零实现一些东西。我想要通过它告诉人们如何去正确地阅读代码如何正确地理解代码的运作方式。当然我们也在制作一些新的内容。现在我们正在将整个课程打包然后上传到网站上完成后这将是一个付费课程你购买后可以看到里面的内容所有的课程、绘图与测试问题都会呈现在网站上。我们还不确实是否会有人买这个课程如果这样做能够赚钱的话我们可能会更新更多的内容。这个项目之前一直是免费的已经有一年半的时间了我们想要看看它是不是一个可行的商业化产品之后再决定如何去运营它。这个项目几周后就会正式上线想要支持的朋友可以关注一下。 对中国开发者说点什么 主持人有没有什么想要对中国开发者们说的话Dan我不知道该说点儿啥。我不确定在中国有多少人在用 React我只知道 Vue 在中国非常的流行。但我觉得有更多的选择是件好事我非常感谢那些 React 文档的翻译者们以及很多 React 库的中国开发者们。我不知道 React 能不能在中国流行起来这个远在异国的我们可能影响不了。但是如果你对 React 非常感兴趣你们有机会改变周围的环境让它流行起来。如果 React 流行起来以后找工作可能会更容易吧笑。我们很高兴看到人们翻译博客文章传播知识举办会议真心地感谢为此付出的每一个人。主持人你今后有没有想要在中国的 React 社区中更活跃一点我们其实很想跟你多多交流。Dan当然了我其实也很想但是不知道怎么做。正好有你们邀请了我我感觉这次活动很酷之后我们可以更经常地交流。主持人好的 我这边问完了所有观众的提问非常感谢 Dan 陪我们进行了这次漫长的在线对话。Dan感谢你们邀请我。主持人感谢我们下次再见Dan再见附录英中State Management状态管理Single Page Application单页面应用Immutability不变性Spread Operator扩展操作符Funtional Programming函数式编程Funtional-lite programming轻函数式编程Data-fetching数据获取server-rendering服务器端渲染Flame gragh火焰图Tic-tac-toe井字棋Snake game贪吃蛇Fortnite堡垒之夜- END -最近组建了一个江西人的前端交流群如果你是江西人可以加我微信 ruochuan12 私信 江西 拉你进群。推荐阅读我在阿里招前端该怎么帮你可进面试群毕业年限不长的前端焦虑和突破方法前端抢饭碗系列之Vue项目如何做单元测试老姚浅谈怎么学JavaScript················· 若川简介 ·················你好我是若川毕业于江西高校。现在是一名前端开发“工程师”。写有《学习源码整体架构系列》多篇在知乎、掘金收获超百万阅读。从2014年起每年都会写一篇年度总结已经写了7篇点击查看年度总结。同时活跃在知乎若川掘金若川。致力于分享前端开发经验愿景帮助5年内前端人走向前列。点击上方卡片关注我、加个星标今日话题略。欢迎分享、收藏、点赞、在看我的公众号文章~
