React 在之前的文档中提到了 Suspense for data fetching[1] 的理念，虽然在新的文档中下线了，但还是有相关的请求库做了实现，比如 useSwr[2] 和 useQuery[3]。React 团队一直想对请求这件抽象且频繁的事情做更好的支持，因此有个新提案带来了新的 Hook —— use。
Prop drilling 是指当上层组件中持有 state，而一个深度嵌套的组件需要使用这个 state 时，一种做法是用 props 透过中间组件一层层往下传，尽管中间组件并不需要他们。 只需要做一下重构就可以避免 prop drilling：
作为一名开发者，我们都希望开发出来的应用程序能够稳定、完美的工作，并且能够满足所有可以想象得到的边缘场景。但是，作为一个人类，我们都会犯一些错误，根本写不出没有 Bug 的代码。无论我们多么小心，无论我们编写多少自动化测试，依然会不可避免地出现错误。但最重要的是，当错误影响到用户体验时，要能够防御这些错误，尽可能地减少影响范围，并以优雅的方式处理它，直到它能够被真正修复。 因此，本文主要讨论 React 中的错误处理：当发生错误时，我们可以做什么；不同的错误捕获方法有哪些限制，以及如何突破这些限制。
如果你还没有接触过复合组件，那么阅读完本文就会对它有初步认识。 复合组件是 React 的一个高级模式，通常是由两个或两个以上的组件共同来实现某项功能。其中一个组件作为父组件，其余组件作为它的子组件，利用这种显式父子关系来共享隐式状态。 复合组件支持组件中的状态和逻辑的共享，可以帮助开发人员构建更直观和灵活性的 API，避免了在子组件间使用 props 进行通信。
在一个典型的 React 应用中，数据是通过 props 属性自上而下（由父及子）进行传递的，但此种用法对于某些类型的属性而言是极其繁琐的（例如：地区偏好，UI 主题），这些属性是应用程序中许多组件都需要的。Context 提供了一种在组件之间共享此类值的方式，而不必显式地通过组件树的逐层传递 props。 当 Context Provider 接收的 value 发生变化的时候，React 会向下深度优先遍历组件树，找到消费了该 Context 的组件并标志为需要更新，在组件更新的 render 阶段，这些消费了该 Context 的组件就会重新渲染，读取到最新的 Context 值。 我们通常传递给 Context Provider 的 value 是一个对象，对象里包含多个字段，然而这种常见的场景却可能导致多次不必要的重复渲染。以下述代码为例：
在日常进行业务需求的开发时，经常会遇到需要绘制图表的场景，其中我们使用频率最高的图表库是 ECharts[1]。ECharts 作为市面上最成熟的图表库之一，主要面向 Web 端使用，官方对小程序端也提供了解决方案，而在 RN 的开发场景中却没有比较好的实现方法，面对这种情况以前我们的解决方案有： 1.放弃 ECharts，使用针对RN原生开发的图表库，如 react-native-charts-wrapper、victory-native 等 2.通过 Webview 来使用 web 端的 ECahrts，如 react-native-echarts-pro[2]、native-echarts 等 方案1，RN 现有图表库的样式与交互与 ECahrts 相比有较大差距，图表的丰富性也不足，尤其是有多端需求的场景下，需要为 RN 单独进行UI交互设计，设计与实现成本高。 方案2，通过 Webview 的方式，当页面上有多个图表或者图表元素过多时，会遇到性能方面的瓶颈，比如安卓端的大数据量面积图、单轴散点图等会有白屏现象，而且正常渲染过程中也会有比较明显的卡顿、掉帧的情况。 所以，
