一、样式
（一）组件化天下的CSS
整个前端已经是组件化的天下，但CSS的设计就不是为组件化而生的，所以在目前组件化的框架中都在需要一种合适的CSS解决方案。
在组件化中选择合适的CSS解决方案应该符合以下条件：
- 可以编写局部CSS：CSS具备自己的具备作用域，不会随意污染其他组件内的原生；
- 可以编写动态的CSS：可以获取当前组件的一些状态，根据状态的变化生成不同的CSS样式；
- 支持所有的CSS特性：伪类、动画、媒体查询等；
- 编写起来简洁方便、最好符合一贯的CSS风格特点；
（二）React中的CSS
事实上，CSS一直是React的痛点，也是被很多开发者吐槽、诟病的一个点。
在这一点上，Vue做的要确实要好于React：
- Vue通过在.vue文件中编写
<style><style>标签来编写自己的样式；
- 通过是否添加
scoped属性来决定编写的样式是全局有效还是局部有效；
- 通过
lang属性来设置你喜欢的less、sass等预处理器；
- 通过内联样式风格的方式来根据最新状态设置和改变css；
- ...
Vue在CSS上虽然不能称之为完美，但是已经足够简洁、自然、方便了，至少统一的样式风格不会出现多个开发人员、多个项目采用不一样的样式风格。相比而言，React官方并没有给出在React中统一的样式风格：由此，从普通的CSS，到CSS Modules，再到CSS in js，有几十种不同的解决方案，上百个不同的库，大家一致在寻找最好的或者说最适合自己的CSS方案，但是到目前为止也没有统一的方案；
（三）内联样式
内联样式是官方推荐的一种CSS样式的写法：style 接受一个采用小驼峰命名属性的 JavaScript 对象，而不是CSS 字符串，并且可以引用
state 中的状态来设置相关的样式。优点：
- 内联样式, 样式之间不会有冲突；
- 可以动态获取当前
state中的状态
缺点：
- 写法上都需要使用驼峰标识
- 某些样式没有提示
- 大量的样式, 代码混乱
- 某些样式无法编写（比如伪类/伪元素）
（四）普通的CSS
普通的CSS我们通常会编写到一个单独的文件，之后再进行引入。这样的编写方式和普通的网页开发中编写方式是一致的：
- 如果我们按照普通的网页标准去编写，那么也不会有太大的问题；
- 但是组件化开发中我们总是希望组件是一个独立的模块，即便是样式也只是在自己内部生效，不会相互影响；
- 但是普通的CSS都属于全局的CSS，样式之间会相互影响；
这种编写方式最大的问题是样式之间会相互层叠掉。（className相同会被后者覆盖）
（五）CSS Modules
CSS Modules并不是React特有的解决方案，而是所有使用了类似于webpack配置的环境下都可以使用的。但是，如果在其他项目中使用个，那么我们需要自己来进行配置，比如配置webpack.config.js中的
modules: true 等。React的脚手架已经内置了CSS Modules的配置：.css/.less/.scss 等样式文件都修改成 .module.css / .module.less / .module.scss 等，之后就可以引用并且进行使用了；
以下是案例代码
最终build之后的HTML代码如下，我们可以看到 CSS Modules 确实解决了局部作用域的问题，也是很多人喜欢在React中使用的一种方案。
但是这种方案也有自己的缺陷：
- 引用的类名，不能使用连接符（.home-title），在JavaScript中是不识别的，可以替换成驼峰写法；
- 所有的className都必须使用
{style.className}的形式来编写；
- 不方便动态来修改某些样式，依然需要使用内联样式的方式；
（六）CSS in JS
1.介绍
实际上，官方文档也有提到过CSS in JS这种方案。“CSS-in-JS” 是指一种模式，其中 CSS 由JavaScript生成而不是在外部文件中定义。
注意此功能并不是 React 的一部分，而是由第三方库提供。React 对样式如何定义并没有明确态度
在传统的前端开发中，我们通常会将结构（HTML）、样式（CSS）、逻辑（JavaScript）进行分离。
但是在前面我们就提到过，React的思想中认为逻辑本身和UI是无法分离的，所以才会有了JSX的语法。因为样式也是属于UI的一部分，而且 CSS-in-JS 的模式就是一种将样式（CSS）也写入到JavaScript中的方式，并且可以方便的使用JavaScript的状态，所以React有被人称之为All in JS。
在我们看来很多优秀的CSS-in-JS的库依然非常强大、方便：CSS-in-JS 通过 JavaScript 来为CSS赋予一些能力，包括类似于CSS预处理器一样的样式嵌套、函数定义、逻辑复用、动态修改状态等等，但是获取动态状态依然是一个不好处理的点。所以，目前可以说 CSS-in-JS 是 React 编写CSS最为受欢迎的一种解决方案；
目前一些比较流行的CSS-in-JS的库：
- styled-components
- emotion
- glamorous
我们以 styled-components 为例，首先进行依赖安装：
yarn add styled-components2. 补充：ES6标签模板字符串
ES6中增加了模板字符串的语法
${} ，但是它有另外的一种用法标签模板字符串（Tagged Template Literals）对函数进行调用。3. Styled Component 基础
根据第二节，styled的原理就是使用标签模板字符串，类似正则表达式对语句进行切割。具体使用如下：
4. props、attrs属性与动态样式
首先
props 可以穿透，即我们可以在 html标签中加入相关属性 或者 在 styled.el.attrs 添加 attrs 属性。5. styled高级特性
1️⃣ 支持样式的继承
2️⃣ styled设置主题
6. React中添加class
React在JSX给予开发者足够多的灵活性，使得我们可以像编写JavaScript代码一样，通过一些逻辑来决定是否添加某些 class，以下是原生的React的className的编写案例：
相比于Vue而言，Vue添加className则比较简单
为了提高我们React中写 className 的效率，我们可以安装第三方库：
yarn add classnames，以下是示例代码：二、AntDesign
（一）介绍
AntDesign ，简称Antd，是基于 Ant Design 设计体系的React UI 组件库，主要用于研发企业级中后台产品。中后台的产品属于工具性产品，很多优秀的设计团队通过自身的探索和积累，形成了自己的设计体系。
AntDesign 和 AntDesign Pro 的区别
AntDesign 是个UI组件库，而 AntDesign Pro 是一个脚手架，类比Vue CLI、create-react-app。
中后台产品
中后台产品主要是面向企业内部用户提供的产品模块（B端）。这类产品相较于用户端（C端），由于用户人群受限于企业内部，因此交互体验的容错性会更大，因此中后台的产品经理通常更关注功能和业务逻辑，而轻视交互体验。
具体来说，中后台系统是内部管理、业务内部流转处理、以及内部资源配置等系统，属于企业内容的系统，不对外开放。这类产品一般都是面向任务的操作，属于工具性产品。
例如，阿里巴巴对前台、中台和后台职责的定位如下：
- 前台：主要面向客户以及终端销售者，实现营销推广以及交易转换。
- 中台：主要面向运营人员，完成运营支撑。
- 后台：主要面向后台管理人员，实现流程审核、内部管理以及后勤支撑，比如采购、人力、财务和OA等系统。
特点：
- 🌈 提炼自企业级中后台产品的交互语言和视觉风格。
- 📦 开箱即用的高质量React 组件。
- 🛡 使用TypeScript 开发，提供完整的类型定义文件。
- ⚙ 全链路开发和设计工具体系。
- 🌍 数十个国际化语言支持。
- 🎨 深入每个细节的主题定制能力。
全链路开发和设计，也被称为全链路设计或端到端设计（End-to-End Design），是指从用户需求到最终产品上线的整个设计过程。这个过程包括以下环节：业务战略—用户场景—设计目标—交互体验—用户流程—预期效率全方面进行分析和考虑；
兼容性：
（二）初步使用
使用 npm 或者 yarn 安装：
npm install antd –save 或 yarn add antd ，因为我们直接使用create-react-app 脚手架生成项目，所以我们使用yarn安装。然后我们在index.js中添加官网的案例代码：
antd 默认支持基于 ES modules 的 tree shaking，直接引入
import { Button } from 'antd'; 就会有按需加载的效果。（三）4.x 配置主题——Craco
1. 介绍
创建项目安装了Antd之后，暂还无法对主题等相关的高级特性进行配置，这需要修改 create-react-app 的默认配置。
修改 create-react-app 配置一方面可以通过
yarn run eject 来暴露出来对应的配置信息进行修改，但是对于webpack并不熟悉的人来说，直接修改CRA 的配置是否会给你的项目带来负担，甚至会增加项目的隐患和不稳定性，所以，在项目开发中是不建议直接去修改CRA 的配置信息。现在社区提出两个比较常见的方案：
- react-app-rewired + customize-cra；（antd早期推荐的方案）
- craco；（antd 4.x 推荐的方案）
2. 使用
- 第一步：安装craco：
yarn add @craco/craco
- 第二步：修改package.json文件
原来启动时，我们是通过react-scripts来管理的。现在启动时，我们通过craco来管理；
- 第三步：在根目录下创建 craco.config.js 文件用于修改默认配置
3. 配置主题
根据 配置主题 的要求，自定义主题需要用到类似 less-loader 提供的 less 变量覆盖功能，因此我们可以引入 craco-less 来帮助加载less样式和修改变量；
- 安装：
yarn add craco-less
- 修改craco.config.js中的plugins：使用
modifyVars可以在运行时修改less变量
- 最后在index.js中引用antd.less文件（默认主题配置文件）
- 修改后重启
yarn start，如果看到一个绿色的按钮就说明配置成功了。
（四）5.x 配置主题
[email protected] 版本，不同于 4.x 版本的 less 和 CSS 变量，开始使用 CSS-in-JS 的理念。
1️⃣ 构成元素
对主题的修改分为三类元素：
- 基础变量（Seed Token）
Seed Token 意味着所有设计意图的起源。比如我们可以通过改变
colorPrimary 来改变主题色，antd 内部的算法会自动的根据 Seed Token 计算出对应的一系列颜色并应用：- 梯度变量（Map Token）
Map Token 是基于 Seed 派生的梯度变量。定制 Map Token 推荐通过
theme.algorithm 来实现，这样可以保证 Map Token 之间的梯度关系。也可以通过 theme.token 覆盖，用于单独修改一些 map token 的值。- 别名变量（Alias Token）
Alias Token 用于批量控制某些共性组件的样式，基本上是 Map Token 别名，或者特殊处理过的 Map Token。
可以理解为从 基础变量（Seed Token）确定主题颜色，根据内部算法将 Seed Token 生成色盘，即一系列的梯度变量（Map Token），而 别名变量（Alias Token）是针对具体某类组件在 Map Token 的上的样式。
2️⃣ 预设算法
通过修改算法可以快速生成风格迥异的主题，5.0 版本中默认提供三套预设算法，分别是:
- 默认算法
theme.defaultAlgorithm
- 暗色算法
theme.darkAlgorithm
- 紧凑算法
theme.compactAlgorithm
你可以通过
theme 中的 algorithm 属性来切换算法，并且支持配置多种算法，将会依次生效。（五）案例：Comment Component
三、Axios
（一）前端网络请求方案
1️⃣ 基于XMLHttpRequest(XHR)的 Ajax
弃用理由：配置和调用方式等非常混乱，编码起来看起来就非常蛋疼，真实开发中很少直接使用，使用jQuery-Ajax替代。
2️⃣ jQuery-Ajax
相对于传统的Ajax非常好用。但是，其弃用理由如下：
- jQuery整个项目太大，单纯使用ajax却要引入整个JQuery非常的不合理（采取个性化打包的方案又不能享受CDN服务）
- 基于原生的XHR开发，XHR本身的架构不清晰，已经有了fetch的替代方案；
- 尽管JQuery对我们前端的开发工作曾有着深远的影响，但是的确正在推出历史舞台；
3️⃣ Fetch API
Fetch是AJAX的替换方案，基于Promise设计，很好的进行了关注分离，有很大一批人喜欢使用fetch进行项目开发；
但是Fetch的缺点也很明显：
- 首先需要明确的是Fetch是一个 low-level（底层）的API，没有封装好各种各样的功能 和实现；
- 比如发送网络请求需要自己来配置Header的Content-Type，不会默认携带cookie等；
- 比如错误处理相对麻烦（只有网络错误才会 reject，HTTP状态码404或者500不会被标记为reject）；
- 比如不支持取消一个请求，不能查看一个请求的进度等等；
- MDN Fetch学习地址：
4️⃣ axios(ajax i/o system)
axios是目前前端使用非常广泛的网络请求库，包括Vue作者也是推荐在vue中使用axios；
主要特点包括：在浏览器中发送XMLHttpRequests 请求、在node.js 中发送http请求、支持Promise API、拦截请求和响应、转换请求和响应数据等等；
（二）Axios介绍
支持多种请求方式：
- axios(config)
- axios.request(config)
- axios.get(url[, config])
- axios.delete(url[, config])
- axios.head(url[, config])
- axios.post(url[, data[, config]])
- axios.put(url[, data[, config]])
- axios.patch(url[, data[, config]])
而且请求还有多种方案：
- 直接通过axios函数发送请求
- 发送get请求
- 发送post请求
- 多个请求的合并
- 使用async、await发送请求
💡 axios函数、get、post请求本质上都是request请求，以下是🔎源码解析
（三）Axios使用
1️⃣ 最基础的发送设置
💡 需要注意：
get 请求搭配的是 params，post 请求搭配的是 data2️⃣ 同步函数实现异步方法
3️⃣
axios.all 将请求进行合并🔎
all() 方法实现其实很简单，就是通过 Promise.all()补充关于
Promise.all()（四）配置信息
配置信息分为三部分：请求配置选项、响应结构信息、全局默认配置(重点)。
这些是创建请求时可以用的配置选项。只有
url 是必需的。如果没有指定 method，请求将默认使用 GET 方法。1️⃣ 请求配置选项
2️⃣ 响应结构信息
💡需要注意服务器返回的数据是放在
data 中3️⃣ 默认配置
假如现在有新的需求，如果我们我们要向两个服务器（地址不一样）发送请求，我们需要创建多个实例：
补充优先级：
配置将会按优先级进行合并。它的顺序是：在lib/defaults.js中找到的库默认值，然后是实例的
defaults 属性，最后是请求的 config 参数。后面的优先级要高于前面的。下面有一个例子。（五）拦截器 interceptors
请求拦截器：在发送请求时，请求被拦截。以下是使用场景：
- 发送网络请求时，在页面中添加一个loading组件作为动画；
- 某些网络请求要求用户必须登录，可以在请求中判断是否携带了token，没有携带token直接跳转到login页面；
- 对某些请求参数进行序列化；
响应拦截器：在响应结果中，结果被拦截。以下是使用场景：
- 响应拦截中可以对结果进行二次处理（比如服务器真正返回的数据其实是在response的data中）；
- 对于错误信息进行判断，根据不同的状态进行不同的处理；
（六）实战使用——二次封装
默认情况下我们是可以直接使用axios来进行开发的。但是我们考虑一个问题，假如有100多处中都直接依赖axios，突然间有一天axios出现了重大bug，并且该库已经不再维护，这个时候阁下该如何应对呢？
大多数情况下我们会寻找一个新的网络请求库或者自己进行二次封装。但是有100多处都依赖了axios，方便我们进行修改吗？所以我们所有依赖axios库的地方都需要进行修改。
以下是一些案例代码：
使用我们封装的库：
- 作者:😈Zabanya
- 链接:https://blog.zabanya.space//article/29e2d47e-3668-44a4-9fd0-a59d9d01208d
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处