跨組件狀態(tài)管理

簡單場景

對于不復(fù)雜的情況，比如父組件傳遞狀態(tài)給子組件，可以使用 props 進(jìn)行傳遞。如果需要傳遞的狀態(tài)過多，我們還可以使用組合組件的方法將子組件內(nèi)的部分組件提升到父組件中去，這樣就不需要再一層層的傳遞狀態(tài)了

服務(wù)端狀態(tài)

對于服務(wù)端狀態(tài)的維護(hù)，也就是發(fā)送網(wǎng)絡(luò)請求才能獲取到的數(shù)據(jù)，如果這些數(shù)據(jù)需要在多個組件中共享，以前可能很多人會選擇用 context 或 redux 來管理服務(wù)端的狀態(tài)，但這樣會導(dǎo)致他們所維護(hù)的狀態(tài)樹過重，不利于項(xiàng)目的維護(hù)。

不過隨著 react-query 和 swr 這些庫的火爆，越來越多的人愿意使用它們來管理服務(wù)端的狀態(tài)，除了管理狀態(tài)以外，他們還可以對我們的項(xiàng)目做一些優(yōu)化，比如 react-query 可以避免重復(fù)發(fā)送相同的請求、以及方便實(shí)現(xiàn)樂觀更新等操作

客戶端狀態(tài)

對于復(fù)雜的客戶端狀態(tài)來說，我們一般有幾種方法來管理，一是通過網(wǎng)頁的 url，這種方式可以有效的管理較少的狀態(tài)。二是通過傳統(tǒng)的 redux，但是大部分的項(xiàng)目其實(shí)并沒有那么多的全局狀態(tài)要管理，如果都使用 redux 進(jìn)行管理的話，反而會讓整個項(xiàng)目顯得笨重很多，所以，隨著 react hooks 的火爆，contex 結(jié)合 hooks 慢慢成為了項(xiàng)目中狀態(tài)管理的主流

項(xiàng)目初始化

• 使用 React 官方提供的腳手架 create-react-app 來初始化 React + TS 項(xiàng)目
• 使用統(tǒng)一的代碼格式化工具 prettier（www.prettier.cn/docs/instal…），這樣你的團(tuán)隊成員無論使用什么 IDE 和插件，格式化項(xiàng)目的時候效果都是一樣的，不容易產(chǎn)生分歧
• 配置 commitlint 幫助我們檢查每次 git commit 的信息是否符合規(guī)范，如果不符合就讓本次提交失敗，這回讓團(tuán)隊協(xié)作的效率更高，項(xiàng)目的可維護(hù)性也會更強(qiáng)

Mock 方案

• 直接在代碼中寫死 Mock 數(shù)據(jù)，或者請求本地的 JSON 文件
• 請求攔截向后端發(fā)送的請求，比如使用 Mock.js 來模擬數(shù)據(jù)
• 使用接口管理工具來 mock 數(shù)據(jù)，比如 apipost、yapi 等等，但前提項(xiàng)目是文檔先行而不是代碼先行
• 自己用 node 開啟一個本地服務(wù)器，也可以借助一些好用的庫，比如 json-server

錯誤邊界

錯誤邊界是一種 React 組件，這種組件可以捕獲發(fā)生在其子組件樹任何位置的 JavaScript 錯誤，并打印這些錯誤，同時展示降級 UI，而并不會渲染那些發(fā)生崩潰的子組件樹。

錯誤邊界可以捕獲發(fā)生在整個子組件樹的渲染期間、生命周期方法以及構(gòu)造函數(shù)中的錯誤。

useState 的惰性初始化

當(dāng)參數(shù)是函數(shù)的時候，useState 幫我們保存的狀態(tài)并不是該函數(shù)，而是其返回值，為了獲取到該返回值，react 會在組件第一次渲染的時候執(zhí)行該函數(shù)，后續(xù)組件的重復(fù)渲染中，該函數(shù)就不會再被執(zhí)行了，所以這種初始化 state 的方法也叫作惰性初始化，其適用于初始 state 需要通過復(fù)雜計算才能獲得的情況。所以如果想用 useState 保存函數(shù)，不能直接傳入函數(shù)，而是需要多嵌套一層函數(shù)

樂觀更新

客戶端假設(shè)請求必然成功，因此不等待接口的返回，先行對視圖進(jìn)行更新，隨后再根據(jù)請求返回的結(jié)果調(diào)整數(shù)據(jù)，如果請求是成功的，則不改變提前更新好的 UI；如果請求失敗了，則需要將數(shù)據(jù)和 UI 視圖回滾至請求前的狀態(tài)并用此時數(shù)據(jù)庫中的準(zhǔn)確數(shù)據(jù)代替

性能追蹤

Profiler 測量一個 React 應(yīng)用多久渲染一次以及渲染一次的“代價”。 它的目的是識別出應(yīng)用中渲染較慢的部分，或是可以使用類似 memoization 優(yōu)化的部分，并從相關(guān)優(yōu)化中獲益

性能追蹤是我們在開發(fā)項(xiàng)目時經(jīng)常會被忽略的一個問題，React 恰好為我們提供了用于性能追蹤的一個 API—Profiler，它的用法很簡單，只需要嵌套在組件外部就可以知道該組件渲染所花費(fèi)的時間，很方便幫助我們?nèi)ザㄎ荒男┙M件需要被優(yōu)化

自動化測試

很多時候我們都需要對原先的項(xiàng)目添加新的功能，相信很多人都會遇到添加了新功能后，原先的功能卻出現(xiàn) bug 的情況，以至于我們每次加一個功能都還需要手動檢查原先的功能有沒有被影響

自動化測試就可以很方便的解決剛剛的問題，每當(dāng)代碼更改都會使用我們預(yù)先寫好的代碼測試原先的函數(shù)、hook、組件、頁面是否能夠正常工作，返回我們想要的結(jié)果，這樣我們開發(fā)完新功能之后就不用在手動的去測試了，不過由于這一塊知識點(diǎn)難度較大，所以我也只是做了一個簡單的了解~

Q & A

1. 如何實(shí)現(xiàn)頁面刷新后持久化存儲用戶信息？

在正常的項(xiàng)目中，我們可以先在本地保存用戶的 token 和用戶信息，每當(dāng)用戶初始化頁面時，我們就判斷用戶的瀏覽器本地是否存有 token，如果沒有則直接跳轉(zhuǎn)到登錄頁面；如果有則先展示本地存儲的用戶信息，然后根據(jù) token 查詢數(shù)據(jù)庫中最新的用戶信息并更新到本地

2. 如何在不同路由組件中實(shí)現(xiàn)網(wǎng)頁標(biāo)題的切換？

網(wǎng)上已經(jīng)針對該問題給出了很多的解決方案，比如可以使用 react-helmet 這個庫，不過我們也可以自己實(shí)現(xiàn)：使用原生的 doucument.title 來控制標(biāo)題的變換。為了增強(qiáng)該功能的復(fù)用性，我們可以將其封裝成一個自定義 hook 在不同的組件中使用

export default function useDocumentTitle(title: string, keepOnUnmount: boolean = true) {
  // 保存當(dāng)前路由對應(yīng)的標(biāo)題
  const oldTitle = useRef(document.title).current
  useEffect(() => {
    // 當(dāng)該組件掛載到頁面中時，將開發(fā)者指定的文本替換成網(wǎng)頁標(biāo)題
    document.title = title
    // 根據(jù)傳入該函數(shù)的參數(shù)來決定組件卸載時是否回滾到先前的網(wǎng)頁標(biāo)題
    return () => {
      if (!keepOnUnmount) document.title = oldTitle
    }
  }, [oldTitle, keepOnUnmount, title])
}

3. 如何避免無限渲染問題？

我們盡量控制傳遞給 useEffect 的依賴項(xiàng)數(shù)組中的變量可以是組件中管理的狀態(tài) state，也可以是 useRef 保存的值或者基本數(shù)據(jù)類型，但一定不能是對象類型的變量，因?yàn)椴煌膶ο蠹词箍雌饋硎且粯拥牡举|(zhì)上它們的地址卻是不同的，而 react 內(nèi)部在比較新舊兩個變量時用的是 === 號，在這種情況下，每次組件重復(fù)渲染時 useEffect 所比對出的新舊依賴都不相同，從而導(dǎo)致組件無限渲染。所以如果要傳遞普通對象，則該對象一定需要用 useMemo 包裹處理以避免組件無限循環(huán)渲染

4.TS 允許擴(kuò)展組件的 props

如何在自己封裝的組件以 antd 組件為基礎(chǔ)的情況下，讓 TS 允許擴(kuò)展組件的 props？

ComponentProps 是 React 內(nèi)置的類型，用于獲取組件的 props 類型，其需要傳遞一個組件（函數(shù)式或類）的類型

import { ComponentProps } from "react";
import { Select } from "antd";
type SelectProps = ComponentProps<typeof Select>;
// 其實(shí)上述的方法和下面的是等價的  // type SelectProps = Parameters<typeof Select>[0]
// Parameters 可以獲取函數(shù)的參數(shù)并放置到一個元組中，而 antd 的組件恰好是一個函數(shù)，所以 [0] 就表示取出 props 的類型
// 創(chuàng)建自己組件的 props 類型，用好 TS 的內(nèi)置類型 Omit 來防止一些我們添加的屬性影響到原先 antd 組件的屬性
interface IdSelectProps
  extends Omit<
  SelectProps,
  "value" | "setState" | "defaultOptionName" | "options"
  > {
  value?: Raw | null | undefined;
  setState?(value?: number): void;
  defaultOptionName?: string;
  options?: { name: string; id: number }[];
}
// 在 antd 組件的基礎(chǔ)上再封裝一個組件，使得該組件不僅可以傳遞原先 antd 組件中的參數(shù)，還可以傳遞一些我們定義的屬性
export default function IdSelect(props: IdSelectProps) {
  const { value, setState, defaultOptionName, options, ...restProps } = props;
  return (
    <Select
      value={value || 0}
      onChange={(value) => setState?.(toNumber(value) || undefined)}
      // 這個 {} 并不表示對象的意思，不要理解錯了，而是 jsx 語法要求在變量外邊需要套個 {}
      {...restProps}     >
      {defaultOptionName ? (
        <Select.Option value={0}>{defaultOptionName}</Select.Option>
      ) : null}
      {options?.map((item) =>
        item ? (
          <Select.Option key={item.id} value={item.id}>
            {item.name}
          </Select.Option>
        ) : null
      )}
    </Select>
  );
}

5. 文件命名

什么時候?qū)⑽募麨?tsx 和 jsx，什么時候又命名為 ts 與 js？

當(dāng)文件中包含組件的時候用 tsx 或 jsx 后綴命名，其它情況下用 ts 或 js 命名就可以了。正確的使用文件后綴名可以提高項(xiàng)目的可讀性，當(dāng)別人一看到該文件的后綴是以 tsx 結(jié)尾的，就能立馬知道該文件中包含的是一個組件而不是普通的函數(shù)

6. 什么時候使用組件組合？

Context 主要應(yīng)用場景在于很多不同層級的組件需要訪問同樣一些的數(shù)據(jù)。請謹(jǐn)慎使用，因?yàn)檫@會使得組件的復(fù)用性變差。

如果你只是想避免層層傳遞一些屬性， 組件組合（component composition） 有時候是一個比 context 更好的解決方案。—— React 官網(wǎng)

聽起來很高大上的名詞，其實(shí)非常簡單，就是在面對一些狀態(tài)需要層層跨組件傳遞時，如果這些狀態(tài)都是集中在某一個區(qū)域里面使用，那么可以把這一塊區(qū)域抽離出一個組件放置到狀態(tài)初始化的地方。這樣原本需要層層傳遞多個狀態(tài)，現(xiàn)在就只需要將組件傳遞過去即可。

這種做法還有一個好處就是子組件不需要擔(dān)心如何消費(fèi)上層傳入過來的狀態(tài)，只需要將注意力放到渲染傳入進(jìn)來的組件上，下面是官網(wǎng)給出的示例：

function Page(props) {
  const user = props.user;
  const userLink = (
    <Link href={user.permalink}>
      <Avatar user={user} size={props.avatarSize} />
    </Link>
  );
  return <PageLayout userLink={userLink} />;
}
// 現(xiàn)在，我們有這樣的組件：
<Page user={user} avatarSize={avatarSize} />
// ... 渲染出 ...Page的子組件
<PageLayout userLink={...} />
// ... 渲染出 ...PageLayout的子組件
<NavigationBar userLink={...} />
// ... 渲染出 ...
{props.userLink}

7. 如何將自己的項(xiàng)目部署到 github 上？

• 新建一個名為 你的github用戶名.github.io 的倉庫
• 在開發(fā)環(huán)境下安裝 gh-pages 依賴 yarn add gh-pages -D，該庫是 github 專門為開發(fā)者提供用來部署項(xiàng)目的
• 在 package.json 文件夾中找到 scripts 字段，新加下列代碼中的信息

// 如果你是用 npm 來啟動項(xiàng)目的，也可以修改為 npm run build
"predeploy": "yarn build", 
// 該字段表示的意思為將打包后的 build 文件夾推送到指定倉庫的 main 分支
"deploy": "gh-pages -d build -r 創(chuàng)建的倉庫地址 -b main"

• 在命令行中執(zhí)行 yarn deploy 命令，其會預(yù)先 predeploy 字段對應(yīng)的命令 yarn build，然后將打包后的內(nèi)容 push 到指定的倉庫中去，所有操作完成之后打開 github 指定的網(wǎng)頁即可看到你的應(yīng)用啦！如果后續(xù)需要更新項(xiàng)目，只需要更新代碼后重新執(zhí)行該命令即可

8. 部署 github 頁面報404

部署到 github 上的項(xiàng)目為啥有時刷新頁面會報 404 的錯誤？

假設(shè)我們部署在 github 上的地址為 sindu12jun.github.io，由于我們的項(xiàng)目是單頁面應(yīng)用，里面用的都是前端路由，如果當(dāng)前 url 變化為了 sindu12jun.github.io/projects，此時…

這樣服務(wù)端接收到這個 url 對應(yīng)的請求后會誤認(rèn)為是服務(wù)器路由，其并找不到該 url 匹配的接口，也不會像訪問首頁 url 一樣將 index.html 響應(yīng)給客戶端，而是返回一個404的頁面，網(wǎng)上已經(jīng)有很多成熟的解決方案了，可以參考 github.com/rafgraph/sp…

9. 我們的項(xiàng)目是用什么工具把 TS 編譯成 JS 文件的？

可能學(xué)習(xí)過 TS 的朋友都知道其真正要在瀏覽器或者 node 中被執(zhí)行需要提前編譯成 JS 文件，對于這個編譯工具大家的第一反應(yīng)可能是 tsc

其實(shí)不是， 目前大多數(shù)的 ts 項(xiàng)目都是 ts 類型檢查 + babel 編譯 這樣的組合，這個項(xiàng)目也不例外 (可以去項(xiàng)目 node_modules 下面看一下，會發(fā)現(xiàn)有個 @babel 文件夾)，用 babel 編譯 ts，就可以實(shí)現(xiàn) babel 編譯一切，從而降低開發(fā)/配置成本

10. 所有的函數(shù)式組件都應(yīng)該被 React.memo 所包裹嗎？

在子組件沒有經(jīng)過特殊處理的情況下，父組件由于狀態(tài)改變導(dǎo)致重復(fù)渲染時，子組件也會進(jìn)行重復(fù)渲染，但有的時候我們并不想讓子組件進(jìn)行無用的渲染，這時就會想到在組件外用 React.memo 來包裹

React.memo 會比較函數(shù)式組件前后兩次的 props 是否發(fā)生了變化，比較方法是淺層比較，如果判斷為沒有變化，則組件不會重新渲染，聽起來是一個很不錯的優(yōu)化方案，那是不是可以在每一個組件外面都包裹一層 React.memo 呢？

其實(shí)是不需要的，React.memo 由于自身需要做前后兩次 props 的淺層比較，是要消耗一定性能的。再者有 React diff 算法的加持下，其實(shí)很多DOM 元素并不會被真正的渲染，所以很多組件就算沒有做 memo 優(yōu)化，仍然不會對項(xiàng)目的性能造成什么影響。

所以我們在想使用 React.memo 之前最好先想想這個組件重新渲染和淺層比較 props 誰花費(fèi)的性能較大再決定是否使用它，如果子組件本身比較復(fù)雜，那確實(shí)是可以在它外面套一層 memo 進(jìn)行優(yōu)化的

總結(jié)

通過這個項(xiàng)目不僅鞏固了自己的 React 和 TS 知識，同時也學(xué)到了很多 Mock 數(shù)據(jù)、性能化、性能追蹤等新知識，希望自己可以憑借新的項(xiàng)目和自己的理解慢慢在前端領(lǐng)域有自己的見解~

以上就是Jira 任務(wù)管理系統(tǒng)項(xiàng)目總結(jié)講解的詳細(xì)內(nèi)容，更多關(guān)于Jira 任務(wù)管理系統(tǒng)的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論