前端搬砖，并不是一件很eazy的活

前端的活吧，要说难或者说简单，都不足以描述，我觉得用墨迹，麻烦，反反复复会更贴切。

究竟什么原因让前端搬砖有一种在战略上，不觉多难，真上手干了，就发觉大有玩泥巴之感呢？

我个人的观点，就是：

前端因为有了面子（UI），并且非常在意面子。

里子（逻辑）没多少，并且基本都围绕面子转。

导致因为面子，挂碍太大，里子又不强，变化受阻，从而导致越开发越费劲。

所以直觉告诉我，前端搬砖要想变得顺利：

那就别过分在意面子，多注重里子

弱化面子的挂碍，强化里子的主导能力，

让里子成为核心，尽可能的主导面子，不受其累。

"里子"主导"面子"，如何实现？

先简单的说下前端搬砖大体内容是啥：

画页面

请求接口-驱动呈现

交互-请求接口-驱动呈现

然后再弄清楚以下两个问题

"面子"的场子究竟可以大到成什么程度

可以大到，什么事都在面子的场子里办了，而组成这个大场子的便是许许多多的组件。

无论是请求

还是组织请求后的数据，驱动显示

亦或是再请求，再组织，再驱动显示

甚至是组件与组件间通信等等

你能想到的前端大部分事，都会在那一亩三分地的组件里给你办了，可见面子已经大到了可怕的程度。

前端的里子是啥，能是啥？

里子简单说就是逻辑，抽象点就是可以组织，运转的能力，

通过上面对前端搬砖直白的描述，那么里子基本确定了内容：

请求接口+组织数据+驱动呈现

既然搞清楚了里子是啥，那就把里子从面子的场子里，拯救出来，做大做强。

实现策略

第一步：先分层
第二步：确定组成
第三步：划定职责

分层

里子：service
面子：UI

确定组成

UI：单纯的组件堆砌
service ：集成状态管理库store +接口请求request

划定职责

UI ：就画页面做交互，其他的一概不管，具体业务全交给service层做，对UI提供action接口，UI层仅仅做触发并响应更新即可
service ：实现接口请求，组织构建状态数据树，驱动显示UI层，并为UI层提供触发接口action

这样，UI层和service层就分开了，

service层内部的stores各仓库可以互相监听，彼此独立，自主更新，互相不耦合。

技术选型

策略已经制定好了，那么围绕这个策略制定一下打法吧，开始挑选搭配技术架子吧。

React：nextjs 和cra，服务端渲染和客户端渲染两手抓
状态管理库：Redux，老牌经典，贼稳贼够用
组件库：随意一点
- 客户端相关的，服务端渲染啥的用mui，好看，好定制，足够基础，方便整合
- 管理后台，无脑入antd，好用到无话可说
- 移动端用antd-mobile
- 小程序端用taro+taroUI

突破前端玩泥巴阶段，重点在状态管理

上面分析的策略，以及制定的强化"里子"的打法，最核心的一环就是状态管理库，串联起整个项目的业务，打通各环节流转的全得靠ta。

所以，重点强化状态管理，才是关键。

Redux什么都好，就是不好用

我是纯纯的直觉型选手，不喜欢看文档，搬砖全靠感觉，但凡不合直觉，别扭的地方，我第一想的是：设计的不合理，我要改到念头通达。

那么redux就是那种用起来，啥啥都不通达，或者说，离通达有一段距离，整体用下来，我的评价就是真不好用。

而且涉及到的库和文档巨多（就三个）

redux
redux-toolkit
react-redux

我猜就算用过Redux搬砖的，能搞清楚上面三者的关系的不多，学习成本多少有点大。

然后就是ts的类型支持，这就更迷了，装载一波ts项目，你得花不少精力在ts类型支持上，使用成本真心不低。

为啥选Redux呢

稳：首先我要支持nextjs和cra，无论是服务端渲染场景还是纯客户端场景，我都要，那么稳定很重要，Redux这么经典，稳定我是信的。
强：我要实现的功能，Redux都有支持，比如我实现策略里需要仓库和仓库之间的监听，Redux就支持

以上两点就是我的主要考量，当然，我的打法固定了，选redux还是选别的状态管理库，都是不离其宗，都是为贯彻我的思路而服务的，所以，take it eazy，选一个靠谱一点redux，觉得哪里不好，就改进一波就行了。

改进Redux，直到念头通达

不通达的点

使用问题无外乎就三种：

获取相关：获取state，reducer和thunk
创建相关：包括创建store，slice，thunk等，以及复杂的TS类型支持
触发相关：触发action，包括同步的reducer和异步的thunk

遇到不通达的地方真不少，挑几个关键的问题，说说

获取state，reducer和thunks，并触发reducer和thunks

先贴出Redux的写法，鉴赏一下，简直槽点满满

ts 复制代码

import { useState } from "react"

import { useAppSelector, useAppDispatch } from "../../app/hooks"
import {
  decrement,
  increment,
  incrementByAmount,
  incrementAsync,
  incrementIfOdd,
  selectCount,
} from "./counterSlice"
import styles from "./Counter.module.css"

export function Counter() {
  const count = useAppSelector(selectCount)
  const dispatch = useAppDispatch()
  const [incrementAmount, setIncrementAmount] = useState("2")

  const incrementValue = Number(incrementAmount) || 0

  return (
    <div>
      <div className={styles.row}>
        <button
          className={styles.button}
          aria-label="Decrement value"
          onClick={() => dispatch(decrement())}
        >
          -
        </button>
        <span className={styles.value}>{count}</span>
        <button
          className={styles.button}
          aria-label="Increment value"
          onClick={() => dispatch(increment())}
        >
          +
        </button>
      </div>
      <div className={styles.row}>
        <input
          className={styles.textbox}
          aria-label="Set increment amount"
          value={incrementAmount}
          onChange={(e) => setIncrementAmount(e.target.value)}
        />
        <button
          className={styles.button}
          onClick={() => dispatch(incrementByAmount(incrementValue))}
        >
          Add Amount
        </button>
        <button
          className={styles.asyncButton}
          onClick={() => dispatch(incrementAsync(incrementValue))}
        >
          Add Async
        </button>
        <button
          className={styles.button}
          onClick={() => dispatch(incrementIfOdd(incrementValue))}
        >
          Add If Odd
        </button>
      </div>
    </div>
  )
}

槽点1：我获取action，包括获取异步的thunk和同步的reducer，居然是通过import的方式
ts 复制代码
```
import {
    decrement,
    increment,
    incrementByAmount,
    incrementAsync,
    incrementIfOdd,
    selectCount,
  } from "./counterSlice"
```
跟state的获取方式不一致，state是通过hook useAppSelector获取，action通过import。为啥不能统一，都通过hook的方式将其获取出来，甚至state，reducer和thunk都用同一个hook一次获取出来。岂不更痛快。
槽点2：触发thunk action的方式太丑了
ts 复制代码
```
const dispatch = useAppDispatch()
dispatch(decrement())
```
dispatch(decrement())这句话我简直无法接受，decrement执行完获得的结果传入dispatch，那么请问decrement存在执行完，不传给dispatch的场景么？我写来写去，怎么发现没有呢。。。，那么为啥不能把dispatch(decrement())想办法变成decrement()呢？这样不就更简洁了，我也不用每个action都dispatch了，优雅，所以我心中的样子是：

并且，仓库和仓库之间的thunk调用，也无需引入，仅仅通过触发的方式即可

完全不用import引入过来，再dispatch，降低了模块和模块之间的依赖，非常的清爽，不耦合。

创建一个thunk，有必要这么仪式感么？

看下redux的创建thunk的写法

ts 复制代码

export const incrementAsync = createAsyncThunk(
  "counter/fetchCount",
  async (amount: number) => {
    const response = await fetchCount(amount)
    // The value we return becomes the `fulfilled` action payload
    return response.data
  },
)

"counter/fetchCount"这个type好别致啊，不难猜counter是这个store（确切的说是slice）的命名空间，后面的这个就是这个thunk的代号了吧。

弱弱的思考一下，这怕不是需要手写吧？一个我勉强能忍，要是我多写几个thunk，岂不是我得写好几遍，起好几次名字？还有这个type跟这个thunk的命名"incrementAsync"，有必要起两个名字么，起一个不也行么？

我就是要创建thunk，你搞得也太形式感了，而我心中的样子是这样的：