React 路由

路由器

React-Router 支持我们使用 HashRouter 和 BrowserRouter 两种路由规则，react-router-dom 提供了 BrowserRouter 和 HashRouter 两个组件来实现应用的 ui 和 url 同步

BrowserRouter 创建的 url 格式 http://xxx.com/path

HashRouter 创建的 url 格式 http://xxx.com/#/path

React 组件通信 03

非嵌套组件通信

Hooks

开发过程中会遇到这样一个场景 FirstChild 和 SecondChild 是我们的两个组件，FirstChild 组件 dispatch action，在 SecondChild 组件展示变化的数据，那么就需要在两个字组件之上一层来设计 context

1. 首先建立 context，存储一个初始状态和一个变更 state 的状态管理器

React 组件通信 02

跨级组件通信

跨级组件通信就是父组件与子组件的子组件或者更深层次的通信。我们可以让父组件传给子组件，再让子组件传递给他的子组件，一次逐级传递。但是这种传递方式当层级关系超过两层的时候会过于臃肿，不好维护。Contex 通过组件树提供了一个传递数据的方法，从而避免在每个层级之间手动传递 props 属性。

祖先代码示例：

React 组件通信 01

组件之间是存在嵌套关系的，如果我们将一个程序的所有逻辑都放在一个组件中。那么这个组件将会变得臃肿不堪并且难以维护，所以组件化的思想就是对组件进行拆分，再将这些组件嵌套在一起，最终形成应用程序。

如图：

• app 组件是 Header Main Footer 组件的父组件
• Main 组件是 Banner ProductList 组件的父组件

React 应用 SOLID 原则 04

定义：依赖倒置原则指出“要依赖于抽象，不要依赖于具体”。换句话说一个组件不应该依赖于另一个组件，而是他们应该依赖于一些共同的抽象。这里“组件”是指应用程序的任何部分，可以是 React 组件，函数，模块或第三方库。

React 应用 SOLID 原则 03

里氏替换原则（LSP）

里氏替换原则可以理解为对象之间的一种关系，子类型对象可以替换为超类型对象。这个原则严重依赖类继承来定义超类型和子类型关系，但它在 React 中可能不太适用，因为我们几乎不会处理类，更不用说类继承了。虽然远离类继承会不可避免地将这一原则转变为完全不同的东西，但使用继承编写 React 代码会使代码变得糟糕（React 团队不推荐使用继承）。因此，对于这一原则不在过多解释。

接口隔离原则（ISP）

定义：客户端不应该依赖它不需要的接口

React 应用 SOLID 原则 02

开放封闭原则（OCP）

定义：一个软件实体（类，模块，函数）应该对扩展开放，对修改关闭。主张在不更改源代码的情况下扩展组件的方式来构造组件

以下代码构建了一个 Header 组件，根据页面不同，Header 组件的 UI 也有些不同

React 应用 SOLID 原则 01

在面向对象编程中，SOLID 原则是设计模式的基础，每个字母分别对应如下：

• 单一职责原则（SRP）
• 开放封闭原则（OCP）
• 里氏替换原则（LSP）
• 接口隔离原则（ISP）
• 依赖倒置原则（DIP）

下面看一下每个原则在 React 中的应用

单一职责原则（SRP）

定义：每个应用应该只有一个职责，也就是只做一件事，可以简单的理解为每个功能/模块/组件都应该只做一件事

为了确保每个组件只做一件事

• 将功能较多的大型组件拆分为较小的组件
• 将与功能无关的代码提取到单独的函数中
• 将有联系的功能提取到自定义 hooks 中

无障碍化 导航栏与可展开按钮

测试工具：

• NVDA screen reader （Free screen reader for Windows）NV Access
• ChromeVox （Free chrome extension）Screen Reader - Chrome Web Store (google.com)

代码实现：

React Hooks 05

useContext()和 useReducer()配合使用可以减少组件层级

useContext()

useContext()会创建一个上下文对象，对外暴露消费者和生产者，在上下文之内的所有子组件都可以访问这个上下文环境之内的数据

简单的说 context 就是对他所包含的组件树提供全局共享数据的技术

缺点：

1. 增加调试复杂度，很难跟踪某个 context 的变化是如何产生的