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 的方式,当页面上有多个图表或者图表元素过多时,会遇到性能方面的瓶颈,比如安卓端的大数据量面积图、单轴散点图等会有白屏现象,而且正常渲染过程中也会有比较明显的卡顿、掉帧的情况。 所以,