Jira 任務管理系統專案總結講解

跨元件狀態管理

簡單場景

對於不復雜的情況，比如父元件傳遞狀態給子元件，可以使用 props 進行傳遞。如果需要傳遞的狀態過多，我們還可以使用組合元件的方法將子元件內的部分元件提升到父元件中去，這樣就不需要再一層層的傳遞狀態了

伺服器端狀態

對於伺服器端狀態的維護，也就是傳送網路請求才能獲取到的資料，如果這些資料需要在多個元件中共用，以前可能很多人會選擇用 context 或 redux 來管理伺服器端的狀態，但這樣會導致他們所維護的狀態樹過重，不利於專案的維護。

不過隨著 react-query 和 swr 這些庫的火爆，越來越多的人願意使用它們來管理伺服器端的狀態，除了管理狀態以外，他們還可以對我們的專案做一些優化，比如 react-query 可以避免重複傳送相同的請求、以及方便實現樂觀更新等操作

使用者端狀態

對於複雜的使用者端狀態來說，我們一般有幾種方法來管理，一是通過網頁的 url，這種方式可以有效的管理較少的狀態。二是通過傳統的 redux，但是大部分的專案其實並沒有那麼多的全域性狀態要管理，如果都使用 redux 進行管理的話，反而會讓整個專案顯得笨重很多，所以，隨著 react hooks 的火爆，contex 結合 hooks 慢慢成為了專案中狀態管理的主流

專案初始化

• 使用 React 官方提供的腳手架 create-react-app 來初始化 React + TS 專案
• 使用統一的程式碼格式化工具 prettier（www.prettier.cn/docs/instal…），這樣你的團隊成員無論使用什麼 IDE 和外掛，格式化專案的時候效果都是一樣的，不容易產生分歧
• 設定 commitlint 幫助我們檢查每次 git commit 的資訊是否符合規範，如果不符合就讓本次提交失敗，這回讓團隊共同作業的效率更高，專案的可維護性也會更強

Mock 方案

• 直接在程式碼中寫死 Mock 資料，或者請求原生的 JSON 檔案
• 請求攔截向後端傳送的請求，比如使用 Mock.js 來模擬資料
• 使用介面管理工具來 mock 資料，比如 apipost、yapi 等等，但前提專案是檔案先行而不是程式碼先行
• 自己用 node 開啟一個本地伺服器，也可以藉助一些好用的庫，比如 json-server

錯誤邊界

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

錯誤邊界可以捕獲發生在整個子元件樹的渲染期間、生命週期方法以及建構函式中的錯誤。

useState 的惰性初始化

當引數是函數的時候，useState 幫我們儲存的狀態並不是該函數，而是其返回值，為了獲取到該返回值，react 會在元件第一次渲染的時候執行該函數，後續元件的重複渲染中，該函數就不會再被執行了，所以這種初始化 state 的方法也叫作惰性初始化，其適用於初始 state 需要通過複雜計算才能獲得的情況。所以如果想用 useState 儲存函數，不能直接傳入函數，而是需要多巢狀一層函數

樂觀更新

使用者端假設請求必然成功，因此不等待介面的返回，先行對檢視進行更新，隨後再根據請求返回的結果調整資料，如果請求是成功的，則不改變提前更新好的 UI；如果請求失敗了，則需要將資料和 UI 檢視回滾至請求前的狀態並用此時資料庫中的準確資料代替

效能追蹤

Profiler 測量一個 React 應用多久渲染一次以及渲染一次的“代價”。 它的目的是識別出應用中渲染較慢的部分，或是可以使用類似 memoization 優化的部分，並從相關優化中獲益

效能追蹤是我們在開發專案時經常會被忽略的一個問題，React 恰好為我們提供了用於效能追蹤的一個 API—Profiler，它的用法很簡單，只需要巢狀在元件外部就可以知道該元件渲染所花費的時間，很方便幫助我們去定位哪些元件需要被優化

自動化測試

很多時候我們都需要對原先的專案新增新的功能，相信很多人都會遇到新增了新功能後，原先的功能卻出現 bug 的情況，以至於我們每次加一個功能都還需要手動檢查原先的功能有沒有被影響

自動化測試就可以很方便的解決剛剛的問題，每當程式碼更改都會使用我們預先寫好的程式碼測試原先的函數、hook、元件、頁面是否能夠正常工作，返回我們想要的結果，這樣我們開發完新功能之後就不用在手動的去測試了，不過由於這一塊知識點難度較大，所以我也只是做了一個簡單的瞭解~

Q & A

1. 如何實現頁面重新整理後持久化儲存使用者資訊？

在正常的專案中，我們可以先在本地儲存使用者的 token 和使用者資訊，每當使用者初始化頁面時，我們就判斷使用者的瀏覽器本地是否存有 token，如果沒有則直接跳轉到登入頁面；如果有則先展示本地儲存的使用者資訊，然後根據 token 查詢資料庫中最新的使用者資訊並更新到本地

2. 如何在不同路由元件中實現網頁標題的切換？

網上已經針對該問題給出了很多的解決方案，比如可以使用 react-helmet 這個庫，不過我們也可以自己實現：使用原生的 doucument.title 來控制標題的變換。為了增強該功能的複用性，我們可以將其封裝成一個自定義 hook 在不同的元件中使用

export default function useDocumentTitle(title: string, keepOnUnmount: boolean = true) {
  // 儲存當前路由對應的標題
  const oldTitle = useRef(document.title).current
  useEffect(() => {
    // 當該元件掛載到頁面中時，將開發者指定的文字替換成網頁標題
    document.title = title
    // 根據傳入該函數的引數來決定元件解除安裝時是否回滾到先前的網頁標題
    return () => {
      if (!keepOnUnmount) document.title = oldTitle
    }
  }, [oldTitle, keepOnUnmount, title])
}

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

我們儘量控制傳遞給 useEffect 的依賴項陣列中的變數可以是元件中管理的狀態 state，也可以是 useRef 儲存的值或者基本資料型別，但一定不能是物件型別的變數，因為不同的物件即使看起來是一樣的但本質上它們的地址卻是不同的，而 react 內部在比較新舊兩個變數時用的是 === 號，在這種情況下，每次元件重複渲染時 useEffect 所比對出的新舊依賴都不相同，從而導致元件無限渲染。所以如果要傳遞普通物件，則該物件一定需要用 useMemo 包裹處理以避免元件無限迴圈渲染

4.TS 允許擴充套件元件的 props

如何在自己封裝的元件以 antd 元件為基礎的情況下，讓 TS 允許擴充套件元件的 props？

ComponentProps 是 React 內建的型別，用於獲取元件的 props 型別，其需要傳遞一個元件（函數式或類）的型別

import { ComponentProps } from "react";
import { Select } from "antd";
type SelectProps = ComponentProps<typeof Select>;
// 其實上述的方法和下面的是等價的  // type SelectProps = Parameters<typeof Select>[0]
// Parameters 可以獲取函數的引數並放置到一個元組中，而 antd 的元件恰好是一個函數，所以 [0] 就表示取出 props 的型別
// 建立自己元件的 props 型別，用好 TS 的內建型別 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 元件的基礎上再封裝一個元件，使得該元件不僅可以傳遞原先 antd 元件中的引數，還可以傳遞一些我們定義的屬性
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. 檔案命名

什麼時候將檔案命名為 tsx 和 jsx，什麼時候又命名為 ts 與 js？

當檔案中包含元件的時候用 tsx 或 jsx 字尾命名，其它情況下用 ts 或 js 命名就可以了。正確的使用檔案字尾名可以提高專案的可讀性，當別人一看到該檔案的字尾是以 tsx 結尾的，就能立馬知道該檔案中包含的是一個元件而不是普通的函數

6. 什麼時候使用元件組合？

Context 主要應用場景在於很多不同層級的元件需要存取同樣一些的資料。請謹慎使用，因為這會使得元件的複用性變差。

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

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

這種做法還有一個好處就是子元件不需要擔心如何消費上層傳入過來的狀態，只需要將注意力放到渲染傳入進來的元件上，下面是官網給出的範例：

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

7. 如何將自己的專案部署到 github 上？

• 新建一個名為 你的github使用者名稱.github.io 的倉庫
• 在開發環境下安裝 gh-pages 依賴 yarn add gh-pages -D，該庫是 github 專門為開發者提供用來部署專案的
• 在 package.json 資料夾中找到 scripts 欄位，新加下列程式碼中的資訊

// 如果你是用 npm 來啟動專案的，也可以修改為 npm run build
"predeploy": "yarn build", 
// 該欄位表示的意思為將打包後的 build 資料夾推播到指定倉庫的 main 分支
"deploy": "gh-pages -d build -r 建立的倉庫地址 -b main"

• 在命令列中執行 yarn deploy 命令，其會預先 predeploy 欄位對應的命令 yarn build，然後將打包後的內容 push 到指定的倉庫中去，所有操作完成之後開啟 github 指定的網頁即可看到你的應用啦！如果後續需要更新專案，只需要更新程式碼後重新執行該命令即可

8. 部署 github 頁面報404

部署到 github 上的專案為啥有時重新整理頁面會報 404 的錯誤？

假設我們部署在 github 上的地址為 sindu12jun.github.io，由於我們的專案是單頁面應用，裡面用的都是前端路由，如果當前 url 變化為了 sindu12jun.github.io/projects，此時…

這樣伺服器端接收到這個 url 對應的請求後會誤認為是伺服器路由，其並找不到該 url 匹配的介面，也不會像存取首頁 url 一樣將 index.html 響應給使用者端，而是返回一個404的頁面，網上已經有很多成熟的解決方案了，可以參考 github.com/rafgraph/sp…

9. 我們的專案是用什麼工具把 TS 編譯成 JS 檔案的？

可能學習過 TS 的朋友都知道其真正要在瀏覽器或者 node 中被執行需要提前編譯成 JS 檔案，對於這個編譯工具大家的第一反應可能是 tsc

其實不是， 目前大多數的 ts 專案都是 ts 型別檢查 + babel 編譯 這樣的組合，這個專案也不例外 (可以去專案 node_modules 下面看一下，會發現有個 @babel 資料夾)，用 babel 編譯 ts，就可以實現 babel 編譯一切，從而降低開發/設定成本

10. 所有的函數式元件都應該被 React.memo 所包裹嗎？

在子元件沒有經過特殊處理的情況下，父元件由於狀態改變導致重複渲染時，子元件也會進行重複渲染，但有的時候我們並不想讓子元件進行無用的渲染，這時就會想到在元件外用 React.memo 來包裹

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

其實是不需要的，React.memo 由於自身需要做前後兩次 props 的淺層比較，是要消耗一定效能的。再者有 React diff 演演算法的加持下，其實很多DOM 元素並不會被真正的渲染，所以很多元件就算沒有做 memo 優化，仍然不會對專案的效能造成什麼影響。

所以我們在想使用 React.memo 之前最好先想想這個元件重新渲染和淺層比較 props 誰花費的效能較大再決定是否使用它，如果子元件本身比較複雜，那確實是可以在它外面套一層 memo 進行優化的

總結

通過這個專案不僅鞏固了自己的 React 和 TS 知識，同時也學到了很多 Mock 資料、效能化、效能追蹤等新知識，希望自己可以憑藉新的專案和自己的理解慢慢在前端領域有自己的見解~

以上就是Jira 任務管理系統專案總結講解的詳細內容，更多關於Jira 任務管理系統的資料請關注it145.com其它相關文章！