一起养成写作习惯！这是我参与「掘金日新计划 · 4 月更文挑战」的第1天，[点击查看活动详情](https://juejin.cn/post/7080800226365145118 "https://juejin.cn/post/7080800226365145118")。 [故事的后续](https://juejin.cn/post/7160268956836560933) # 首先事情是这样的我一朋友，用 react 开发前端时间不长，一些简单的功能和页面没啥大问题。前不久`React` 18 发布了，他就用 `create-react-app` 创建了一个新项目，合计练练手，但谁成想遇到了种种问题，让我帮看看，于是就有了接下来要聊的一些看似简单，但是对新手却很绊脚的小问题。 # `react`都 18 了，但为啥还是 `ReactDom.render`？ `create-react-app`新创建的项目，还是用的`ReactDom.render`，如下： ```ts import React from 'react' import ReactDOM from 'react-dom' //《----------react 17使用的ReactDOM import App from './App' import './index.css' ReactDOM.render( , document.getElementById('root') ) ``` > 语义大体上：`ReactDOM` 用 `render` 函数，把 `JSX Elements` 组件，渲染到 `id` 为'`root`'的 `dom` 节点上。那么用`react 18`的新写法改造一下 > `react 18`改了 ```tsx //index.tsx import React from 'react' import { createRoot } from 'react-dom/client' //《----------react 18使用的ReactDOM/client中的createRoot import App from './App' import './index.css' function render() { const root = createRoot(document.getElementById('root')!) root.render( ) } ``` > 语义大体上：`react-dom/client` 用 `createRoot` 函数，把 `id` 为'`root`'的 `dom` 节点做成了一个渲染器，然后用`Render`函数把`JSX Elements`渲染出来。 # 用策略模式啊，别写大段的switch或if了我朋友跟我说： ![image.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/27ca5ce9ebf9491b81c4b7a8694e3b7f~tplv-k3u1fbpfcp-watermark.image?) 我看了看项目，发现了有好多大段的`switch`或者`if`，如： ![image.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/a42a2bcfa27448dd93281ffe89af8453~tplv-k3u1fbpfcp-watermark.image?) 这样显然不优雅，于是我用策略模式重构一下： ```js const infoMap = { pending:"error", fullyPayed:"success", ready:"success" } const orderStatusIndicator = ( orderStatus ) => { return infoMap[orderStatus]||'default' }; ``` 嗯，策略模式就是好用，这看着多舒服。 # 函数组件useState的更新没有回调函数，我怎么同步获得最新state？由于我朋友用习惯了class组件，经常会设置状态时传入一个回调函数，从而用同步的写法，获得刷新后的最新状态，如： ```js this.setState({ test:"新数据", ()=>{ consoloe.log(this.state.test) } }) ``` 但是在函数组件中，这种开发习惯就不行了，因为useState的set函数是不具备回调参数的，如果想在设置后获得最新的状态，那就得借助useEffect配合一下： ```js const [test,setTest] = useState("0"); useEffect(()=>{ setTest("1") console.log(test) // 当前的数据依然是旧的数据：0 },[]) useEffect(()=>{ console.log(test) // 当前的数据才是新的数据：1 },[test]) ``` ## 批处理？ ok，你会说因为这是react的批处理机制，只要我们通过react管不到的函数中写，就能够通过获得了，如： ```js const [test,setTest] = useState("0"); useEffect(()=>{ setTimeout(()=>{ setTest("1") console.log(test) // 虽然确实跳出了批处理，直接修改了state，但这里你还是拿不到最新的test值，依然还是会打印旧的值。 }) },[]) ``` 首先就算跳出批处理，也是无法同步的获得最新状态值，而且你要知道这可是老黄历了，现在的**React 18**可强大到没有法外之地了： ![image.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/a1c73a83a50d467385a7b08b9a3aead0~tplv-k3u1fbpfcp-watermark.image?) [官方相关文章](https://github.com/reactwg/react-18/discussions/21) **React 18**也提供了`flushSync`来跳出批处理，不要再`setTimeout`了。所以，就算跳出批处理也无法同步获得最新状态，那该怎么实现我朋友的愿望呢？ ## 写一个强化版的useState ```js import { useRef, useState, useEffect } from "react"; const useStateWithCall = (initValue)=>{ const ref = useRef(0) const callFRef = useRef() const setFuncRef = useRef() let [state,setState] = useState(initValue) if(!ref.current){ ref.current = 1; setFuncRef.current = (newData,callF)=>{ callFRef.current = callF; setState(newData) return Promise.resolve(newData) } } useEffect(()=>{ callFRef.current?.(state) },[state]) return [state,setFuncRef.current] } export default useStateWithCall; ``` 然后在代码中使用，用法跟`useState`大体一致： - **初始化hook：** ```js const [test,setTest] = useStateWithCall(-1); ``` - 设置最新状态： - 回调的方式 ```js // 设置新数据 setTest(1,(newState)=>{ console.log("新值"+newState) }) ``` - `.then`的方式 ```js setTest(type).then((newState)=>{ console.log("新值"+newState) }) ``` 这样就基本实现了类似`class`组件`setState`那样的回调获得最新`state`了。 # react 都 18 了，React-router 得 v6 啊，但变化好大，咋用啊？ > `React-router v6`可谓是变化着实不小，之前`v5`组织路由是这样的： ## React-router v5 ```tsx //app.tsx import React from 'react' import { BrowserRouter as Router, Route, Switch } from "react-router-dom"; export default () => { return ( ) } ) ``` > `PageCenter`就是我们的页面组件，一般都会在这里实现`嵌套路由`，如： ```tsx //PageCenter.tsx import React from 'react' import NestRoute from ‘./nestRoute’ import { Route, Switch } from "react-router-dom"; export default () => { return ( <> <> ) } ) ``` > em ～～～，跟 app.tsx 中实现的顶层路由很像，一脉相承。 ### 评价一波 v5 路由的组织方式吧 - `tsx` 文件大臃肿：每配置一个路由，就写一个 `Route` 组件，我个人是不喜欢的，我不希望我的 `tsx` 的代码太多，这是我的喜好，为了阅读起来容易，清晰。 - 项目的文件夹结构复杂嵌套：**顶层路由和嵌套子路由配置分离**，直接影响了工程项目中对项目的文件夹结构的编排。因为不能够很直接理清页面组件间的组织关系，不理清会很混乱，维护难度加大，所以理清关系就落在了`项目的文件夹结构`设计了，这就会导致`项目的文件夹结构`随着`v5 路由的组织方式`的复杂而复杂。 ## React-router v6 可能是因为 v5 的种种原因，才导致 v6 的变化那么大，最突出便是： - **v6 痛快的推出了配置式路由**：一个简单的配置对象，充分描述出了路由的样子和组织关系，痛快～～～。 - **简洁的路由嵌套方式**：仅仅在配置了嵌套路由组件中，使用新推出的标签就搞定了，优雅～～～。不过～～～，也有一些破坏性的改变，让我措手不及，比如： - **路由拦截无了！！！**：拦截啊可是，怎么没有了，这。。。 - **`withRouter`无了！！！**：函数组件我能用`hook`搞搞，类组件咋办，这。。。 em ～～～没事 repect，毕竟进步嘛，怎么会没代价呢，没有咱就自己搞被，不坐车就不会走了么？我为此写了一个库[r6helper](https://www.npmjs.com/package/r6helper)，尽可能的弥补了升级 v6 带来的影响 - 拦截，安排上了。 ![ezgif.com-gif-maker.gif](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/319fe66446a8424da83570555ea162a9~tplv-k3u1fbpfcp-zoom-1.image) - `withRouter`，安排上了。 # 路由好了，那么路由懒加载得有吧，怎么搞？方式还是依然是通过 `React.lazy`配合`import`的动态引入，代码如下。 ```tsx const Login = React.lazy(() => import('./login')) ``` 然后还要在通过`React.Suspense`包裹一下这个懒加载组件，否则的话会报错，这个问题我的那个朋友可是卡住了很久。。。，原因就是忘记了要在懒加载组件外包裹一层`React.Suspense`。 ```tsx ...}>{} ``` 但是，朋友又跟我讲，每加一个页面，就写个`lazy`引入组件和`Suspense`包裹，那么页面一多，代码就会变成这样： ```tsx const Login = React.lazy(() => import('./pages/login')) const PageCenter = React.lazy(() => import('./pages/pageCenter')) const Page1 = React.lazy(() => import('./pages/page1')) const Page2 = React.lazy(() => import('./pages/page2')) const Page3 = React.lazy(() => import('./pages/page3')) const Page4 = React.lazy(() => import('./pages/page4')) const Page5 = React.lazy(() => import('./pages/page5')) ... export default () => { return useRoutes([ { path: '/', element: ...}>{}， children: [ { path: "codePLay", element: }, ] }, { path: '/pageCenter', element: ...}>{}， children: [ { path: '/page1', element: }, { path: '/page2', element: ...}>{} }, { path: '/page3', element: ...}>{} }, { path: '/page4', element: ...}>{} }, { path: '/page5', element: ...}>{} }, ] }, { path: '/404', element:

not found

}, ]) } ``` 嵌套路由 ```tsx //PageCenter.tsx import React from 'react' export default () => { return (

) } ) ``` 这样看起来就非常的冗余，很多重复的代码，希望我能帮他优化一下，em ～～～没问题，开整。 ## 优化代码主要从两个方面入手： - 组件`lazy`引入上 - 然后`Suspense`包裹上 ### 统一入口首先页面组件都放在了`pages`路径下，然后再定向导入，我们加个`index`在`pages`文件夹下，进行统一管理。 ```js // 文件：pages/index.ts export Login = React.lazy(() => import('./pages/login')) export Page1 = React.lazy(() => import('./pages/page1')) export Page2 = React.lazy(() => import('./pages/page2')) export Page3 = React.lazy(() => import('./pages/page3')) export Page4 = React.lazy(() => import('./pages/page4')) export Page5 = React.lazy(() => import('./pages/page5')) ``` 然后我们重构一下之前的引入代码： ```tsx const { Login, Page1, Page2, Page3, Page4, Page5 } from './pages' ``` ### 封装包装组件，支持多类型写一个能够包装多类型的组件，都可以包装： - **组件**，包括：**函数组件**和 **类组件**。 - **lazy 组件**。 - **jsx element**。那么代码如下： ```js // 加载异步组件的loading type ChildT = React.LazyExoticComponent<() => JSX.Element> | React.FC export const wrapper = (Child: ChildT, cutonFallBack?: CutonFallBackT) => { // 判断jsx if (Child.type && !Child._init && !Child._payload) { return Child } else { // 判断是否为clas和function组件 if (typeof Child === 'function') { return } else { // 判断是否为lazy组件 return ( ...}> {} ) } } } ``` *注：React.Suspense**完全可以不用多次包裹**，**直接顶层包裹一次即可**，我这么写，仅仅是突出表达如何实现一个可以包装多种类型节点的Hoc* ### 当然还有更优雅的方式，就是**react-is** ``` import * as reactIs from 'react-is'; ... type ChildT = React.LazyExoticComponent<() => JSX.Element> | React.FC export const wrapper = (Child: ChildT, cutonFallBack?: CutonFallBackT) => { // 判断jsx if (reactIs.isElement(Child)) { return Child } else { // 判断是否为clas和function组件 if (reactIs.isValidElementType(Child)) { return } else { // 判断是否为lazy组件 return ( ...}> {} ) } } } ``` 那么这样整体重构后的代码，就大体变成了 ```tsx const { Login,PageCenter, Page1, Page2, Page3, Page4, Page5 } from './pages' ... export default () => { return useRoutes([ { path: '/', element:wrapper(Login)， }, { path: '/pageCenter', children: [ { path: '/page1', element: wrapper(Page1) }, { path: '/page2', element: wrapper(Page2) }, { path: '/page3', element: wrapper(Page3) }, { path: '/page4', element: wrapper(Page4) }, { path: '/page5', element: wrapper(Page5) }, ] }, { path: '/404', element: wrapper(

not found

) }, ]) } ``` em ～～～朴实无华，但是代码看起来舒服不少，朋友感叹学到不少干货，我感觉这就是基本操作，233333。 # 但是这样就够了么？随着项目的发展，会不断的创建新的页面，进而就会出现越来越复杂的路由结构，如下： ![image.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/18692fc3eaa1429da2f7d350c0d5475f~tplv-k3u1fbpfcp-watermark.image?) 这配置数据的嵌套的层级太深了，简直“嵌套地狱”，要继续想办法优化 ## 继续分解演化我们把路由的配置数据按照作用分解，即把“**组织关系**”和“**路由个体**”拆开。 **拆开的过程简单说：就是通过“组织关系”数据和“路由个体”数据，组合生成树状嵌套的路由结构数据（*也就是useRoutes要求的数据结构*）。** > 首先“一”分“二”，同时还有二者之间有联系，那么就得用“**键值**”关联。 ```js const r_loginRoute = Symbol(), r_pageCenter = Symbol(), r_page1 = Symbol(), r_page2 = Symbol(), r_page3 = Symbol(), r_page4 = Symbol(), r_page5 = Symbol(), r_page3_1 = Symbol(), r_page5_1 = Symbol(), r_page5_1_1 = Symbol(), r_page5_1_2 = Symbol(), r_page5_1_2_1 = Symbol() ``` 借助`Symbol`，让代码简洁，当然也可以这样： ```js const r_loginRoute = "r_loginRoute", r_pageCenter = "r_pageCenter", r_page1 = "r_page1", r_page2 = "r_page2", r_page3 = "r_page3", r_page4 = "r_page4", r_page5 = "r_page5", r_page3_1 = "r_page3_1", r_page5_1 = "r_page5_1", r_page5_1_1 = "r_page5_1_1", r_page5_1_2 = "r_page5_1_2", r_page5_1_2_1 = "r_page5_1_2_1" ``` 虽然也行，但相比`Symbol`，其字符值并没有什么实际意义，仅仅能够“独一无二”，可以用来作区分即可，所以`Symbol`就完全能胜任了。 > “二”中之一，便是“**路由个体**”数据，数据结构是个字典对象 ```js let routesMap = { [r_loginRoute]: { path: '/', element: Login }, [r_pageCenter]: { path: '/pageCenter', element: PageCenter }, [r_page1]: { path: '/page1', element: Page1 }, [r_page2]: { path: '/page2', element: Page2 }, [r_page3]: { path: '/page3', element: Page3 }, [r_page4]: { path: '/page4', element: Page4 }, [r_page5]: { path: '/page5', element: Page5 }, [r_page3_1]: { path: '/page3_1', element: Page3_1 }, [r_page5_1]: { path: '/page5_1', element: Page5_1 }, [r_page5_1_1]: { path: '/page5_1_1', element: Page5_1_1 }, [r_page5_1_2]: { path: '/page5_1_2', element: Page5_1_2 }, [r_page5_1_2_1]: { path: '/page5_1_2_1', element: Page5_1_2_1 } } ``` 每个路由个体都是**路由结构数据**去除**children**的部分，完整沿用了`react router v6`中`useRoutes`的配置数据的`api`。 > 最后二中之一，便是“**组织关系**”数据，其就是一个扁平的数组，仅仅描述的是关联关系，即结构 ```js let relation = [ { id: r_loginRoute, parentId: '' }, { id: r_pageCenter, parentId: '' }, { id: r_page1, parentId: r_pageCenter }, { id: r_page2, parentId: r_pageCenter }, { id: r_page3, parentId: r_pageCenter }, { id: r_page4, parentId: r_pageCenter }, { id: r_page5, parentId: r_pageCenter }, { id: r_page3_1, parentId: r_page3 }, { id: r_page5_1, parentId: r_page5 }, { id: r_page5_1_1, parentId: r_page5_1 }, { id: r_page5_1_2, parentId: r_page5_1 }, { id: r_page5_1_2_1, parentId: r_page5_1_2 } ] ``` **仅仅两个属性：** - `id`：自己的id。 - `parentId`：父节点的id。 > 最后实现让两者合而为一的“魔法” ```js const createRoutesData = ({ relation, routesMap }) => { // 首先遍历一下“组织关系”数据，作用： // 1 深拷贝一下“组织关系”数据，不污染和篡改原数据。 // 2 记录一下索引，优化效率。 let relationCopy = [] let ids = {} relation.forEach((item, index) => { const { id } = item ids[id] = index relationCopy.push({ ...item }) }) // 工具函数，简化逻辑，让代码清晰。 // 初始化数据 const initData = (arr, key, def) => { if (!(key in arr)) { arr[key] = def } return arr[key] } // 加工RouteItem const processRouteItem = data => { let temp = { ...data } temp.element = wrapper(temp.element) return temp } // 目标结果数据 let results = [] // 然后遍历一下数据，融合 relationCopy.forEach(item => { const { id, parentId } = item Object.assign(item, processRouteItem(routesMap[id])) if (!parentId) { if (!(id in routesMap)) { throw `routesMap未配置该id:${id}的数据个体` } results.push(item) } else { let pIndex = ids[parentId] let routesData = relationCopy[pIndex] let routeChildren = initData(routesData, 'children', []) routeChildren.push(item) } }) return results } console.log( createRoutesData({ relation, routesMap }) ) ``` *以上我写的“lowlow的算法”，亲测没问题，思路也都写在了备注里，有问题的话，可以在评论区讨论。* 那么经过以上进一步的重构，代码如下： ```js const { Login,PageCenter, Page1, Page2, Page3, Page4, Page5, page3_1, page5_1_1, page5_1_2, page5_1_2_1 } from './pages' const r_loginRoute = Symbol(), r_pageCenter = Symbol(), r_page1 = Symbol(), r_page2 = Symbol(), r_page3 = Symbol(), r_page4 = Symbol(), r_page5 = Symbol(), r_page3_1 = Symbol(), r_page5_1 = Symbol(), r_page5_1_1 = Symbol(), r_page5_1_2 = Symbol(), r_page5_1_2_1 = Symbol() let relation = [ { id: r_loginRoute, parentId: '' }, { id: r_pageCenter, parentId: '' }, { id: r_page1, parentId: r_pageCenter }, { id: r_page2, parentId: r_pageCenter }, { id: r_page3, parentId: r_pageCenter }, { id: r_page4, parentId: r_pageCenter }, { id: r_page5, parentId: r_pageCenter }, { id: r_page3_1, parentId: r_page3 }, { id: r_page5_1, parentId: r_page5 }, { id: r_page5_1_1, parentId: r_page5_1 }, { id: r_page5_1_2, parentId: r_page5_1 }, { id: r_page5_1_2_1, parentId: r_page5_1_2 } ] let routesMap = { [r_loginRoute]: { path: '/', element: Login }, [r_pageCenter]: { path: '/pageCenter', element: PageCenter }, [r_page1]: { path: '/page1', element: Page1 }, [r_page2]: { path: '/page2', element: Page2 }, [r_page3]: { path: '/page3', element: Page3 }, [r_page4]: { path: '/page4', element: Page4 }, [r_page5]: { path: '/page5', element: Page5 }, [r_page3_1]: { path: '/page3_1', element: Page3_1 }, [r_page5_1]: { path: '/page5_1', element: Page5_1 }, [r_page5_1_1]: { path: '/page5_1_1', element: Page5_1_1 }, [r_page5_1_2]: { path: '/page5_1_2', element: Page5_1_2 }, [r_page5_1_2_1]: { path: '/page5_1_2_1', element: Page5_1_2_1 } } export default () => { return useRoutes(createRoutesData({ relation, routesMap })) } ``` ## 扁平化配置带来的好处最直观的好处就是，**调整路由组件的组织关系变得简单**。 ### **对于v5，怎么改组织关系？** **方式**：上文提到，由于v5没有配置数据，那么体现组织关系的重任落到了`项目的文件夹结构`设计上，那么如果调整路由页面间的关系，那就得修改`项目的文件夹结构`。 **弊端**：修改`项目的文件夹结构`，会有很大的可能引发错误，因为路径改变依赖关系就会改变，这样的重构风险极大，成本很高。 ### **对于v6，怎么改组织关系？** **方式**：由于v6有了配置数据，那么直接调整配置数据即可，即调整树状数据中各节点数据的从属关系。 **弊端**：嵌套地狱啊，一堆路由嵌套过于复杂，至少对于我，看着比较乱，修改起来比较麻烦，从臃肿的树状数据中找到子节点，然后剪切，再找到目标父节点，然后剪切进去，不太方便。 ### 基于v6，实现扁平化配置，完美的解决以上弊端仅仅修改组织关系的id即可，比如： ```js let relation = [ { id: "A", parentId: "" }, { id: "B", parentId: "A" }, { id: "C", parentId: "A" } ] ``` 把C节点调整为B的子节点，那么仅仅修改`parentId`即可，如： ```js let relation = [ { id: "A", parentId: "" }, { id: "B", parentId: "A" }, { id: "C", parentId: "B" } ] ``` 搞定～～～ ## 扁平化和树状结构是搭档我并没有否定树状结构，相反我非常喜欢，我使用扁平化，不单单出于维护方便，更多的是为了推动事物发展，让“树”不单单是数据，而是一棵能够被看到的“树”，并能够进一步通过可视化拖拽来调整组织关系。如：

这样一条清晰演化过程，便浮现了出来： **工程项目结构⇢配置树状数据⇢扁平化配置⇢可视化配置** # 结尾至此，整个代码虽然变多，但是扩展的能力大大加强，未来无论是： - **配合后台做权限控制**。 - **实现低代码的可视化创建**。都大大降低了开发难度和维护成本。如果有问题，可以随时咨询我，我没事就喜欢水群，结交了一帮喜欢交流技术的伙伴，并整个了个群，欢迎加入一起交流，一起学。