模組化 React 架構-js教程-PHP中文網

首頁

web前端

js教程

模組化 React 架構

Linda Hamilton

Nov 09, 2024 pm 07:29 PM

Modular React architecture

淺談模組化架構

什麼是模組化架構？讓我們透過一個例子來了解它不是什麼，並且
我們將努力改變它。到最後你可能會相信它
優點或這是對時間的巨大浪費。

這是我在工作中經歷的一個成長心態的真實場景。姓名和詳細資料
雖然是匿名的，但一個常見概念的現實世界範例應該很有趣
如果沒有別的的話，通過。

要求以及如何找到它們

我們的網站有一個位於網站標題中的按鈕。它顯示有多少
使用者已經離開了 V-Bucks，但也融入了一些商業邏輯：

如果這是他們第一次造訪網站，請打開一個彈出視窗來歡迎他們並展示他們可以用 V-Bucks 做些什麼
如果他們有
如果他們是基本用戶，則顯示一種樣式的按鈕；如果是 SuperDuper 用戶，則顯示另一個更漂亮的按鈕

等等。我們的產品經理和專案經理這樣的例子還有很多
設計經理和 V-Bucks 集團董事夢想著我們需要
手柄。

實習生 Jimbo 的任務是實現這個，因為這只是一個
按鈕！

他篩選了 Figma 設計的 15 種相互衝突的迭代。他發現有多少個 PM，就在多少個單獨的 Word 文件中包含這些要求。他組織並
與七個團隊一起進行七次知識轉移會議，以揭開
古老的專有知識知道哪些服務將提供他所需的數據
用於使用者類型和 V-Bucks 數量。內容團隊向他保證
所有字串的最終版本將在年底獲得法律和行銷部門的批准
一周，這樣，他就準備好要建造這個按鈕了。

駭客方法

這是他的 V-Bucks 按鈕、彈出視窗和相關內容的第一次迭代

業務邏輯。

Jimbo 對他所提出的簡單目錄結構感到滿意：

/v-bucks-button
├── button.tsx
├── index.ts
└── /v-bucks-popover
│ ├── popover.tsx

登入後複製

所以他開始建造這個按鈕，而且一開始很天真。

export const VBucksButton: React.FC<VBBProps> = ({ ... }) => {
  // Set up state
  const authConfig    = { ... }
  const { user }      = useAuth({ ...authConfig })
  const { vBucks }    = useGetVBucks({ user })
  const { telemetry } = useTelemetry()
  const { t }         = useTranslation('vBucksButton.content')
  const styles        = useButtonStyles()

  // Derive some state via business logic
  const handleClick = () => { ... }
  const buttonText  = vBucks === ERROR ? '--' : vBucks.toString();
  // About 25 more lines of various button state, error handling,
  // conditional rendering, with comments throughout explaining
  // why we're showing or hiding something or other

  const popoverProps = {
    // About 200 lines of typical popover handling,
    // telemetry, business logic, content to display, etc
  }

  const tooltipProps = {
    // Another 100 lines of the same for tooltip
  }

  return (
    <VBucksPopover
      {...popoverProps}
      trigger={
        <Tooltip {...tooltipProps}>
          <button
            ariaLabel={t('ariaLabel')}
            className={`
              about seven-hundred classnames for responsive design,
              accessibility, conditional premium styles, et cetera`}
            onClick={handleClick}>
            {buttonText}
          </button>
        </Tooltip>
      }
    />
  )
}

登入後複製

他已經實現了第一次嘗試。 VBucksPopover 也有類似的複雜

業務邏輯、錯誤處理、狀態管理、樣式與註解
以運輸名義的技術債。

這個按鈕不到 400 行，非常簡單。即使彈出視窗是

另外500行義大利麵。真的是「清理」還是分裂
以任何方式使我們或我們的用戶受益？這取決於。如果這就是我們所需要的
這個按鈕，誰在乎呢。讓我們繼續前進吧！

但是兩個月過去了，另一個產品團隊的PM和設計師愛上了
您的按鈕並希望將其放在應用程式的標題中。他們有一個簡單列表，沒有
來自他們的壓力，他們希望你適應一些改變，如果
您可以在當天結束前給出 LT 的預計到達時間，那就太好了，謝謝：

更新按鈕的樣式並根據其顯示的應用程式顯示文字
每個應用程式顯示一組完全不同的彈出視窗
當使用者用完 V-Bucks 時，開啟一個新的全公司範圍內的標準追加銷售模式，但僅限於某些地區，並且僅限 16 歲的用戶，並且僅限於實驗A組

Jimbo 能否將所有這些新功能塞進同一個元件中？

是的。拆分或重構會給用戶帶來好處還是給你的經理留下深刻印象？

不。但在這種複雜程度上，重構有一些強而有力的論點：

開發理智
當 Jimbo 因不重構而被 PIP 時取代他的開發人員的理智
更多次數，讓你下次從一開始就做得更好
稍後寫部落格的內容

模組化架構方法

清潔守則倡導者和其他了解足夠知識的肛門類型的道德
定期在 Stack Overflow 上回答，連你的祖父母也會看一些東西
像這樣：

KISS、DRY 和其他縮寫毯子
關注點分離
原子性！脫鉤！擬聲詞！

這些都很棒，有助於為 Jimbo 的下一次嘗試提供資訊。
之後他就沒有被畫中畫了所有，而且實際上還得到了提前交付和分享的促銷
這麼多的會議和文件。

但他現在更聰明了，學會了一種很酷的方法來實踐這些格言。看起來
像這樣的東西：

/v-bucks-button
├── button.tsx
├── index.ts
└── /v-bucks-popover
│ ├── popover.tsx

登入後複製

看起來像大量按鈕和彈出框的樣板。為什麼會這樣
更好嗎？

這取決於。以下是 Jimbo 的簡要概述及其基本原理：

將每個元件拆分為容器和渲染器
將狀態和業務邏輯移入鉤子
容器使用鉤子並將任何道具傳遞給渲染器
渲染器只關心渲染它所提供的內容
通用功能、業務邏輯或常數可以存在於 utils 中
不同類型的單獨文件；它們往往被導入到多個文件中並且成為你無論如何都需要提取的循環依賴
提取的 TailwindCSS - 下面有更多內容

它無限可擴充！ 這些構建塊不會被
分解任意規則，例如程式碼行或“複雜性”。它們被分解為
目的：每個概念邊界都有一個目的。

PM 要你做 10 個新的爆米花？沒問題－Jimbo 的架構可以
處理一下。

領導階層希望在某些應用程式中獲得更好的銷售指標，但其他團隊則不然
有資金建立遙測技術來支持這一點。偉大的！我們有
我們可以水平擴展以滿足各種變化的遙測實用程式
要求。

徹底的重新設計意味著每個彈出視窗都需要顯示不同的內容，
根據不同的條件。現在，通常要簡單得多，因為所有
我們渲染的東西，以及我們用來渲染它的所有邏輯，都存在於明確定義的
中塊。它們不再混雜在一大堆衝突和邏輯中
鍊長 20 行。

這是此容器/渲染器模式的範例：

/v-bucks-button
├── button.tsx
├── index.ts
└── /v-bucks-popover
│ ├── popover.tsx

登入後複製

export const VBucksButton: React.FC<VBBProps> = ({ ... }) => {
  // Set up state
  const authConfig    = { ... }
  const { user }      = useAuth({ ...authConfig })
  const { vBucks }    = useGetVBucks({ user })
  const { telemetry } = useTelemetry()
  const { t }         = useTranslation('vBucksButton.content')
  const styles        = useButtonStyles()

  // Derive some state via business logic
  const handleClick = () => { ... }
  const buttonText  = vBucks === ERROR ? '--' : vBucks.toString();
  // About 25 more lines of various button state, error handling,
  // conditional rendering, with comments throughout explaining
  // why we're showing or hiding something or other

  const popoverProps = {
    // About 200 lines of typical popover handling,
    // telemetry, business logic, content to display, etc
  }

  const tooltipProps = {
    // Another 100 lines of the same for tooltip
  }

  return (
    <VBucksPopover
      {...popoverProps}
      trigger={
        <Tooltip {...tooltipProps}>
          <button
            ariaLabel={t('ariaLabel')}
            className={`
              about seven-hundred classnames for responsive design,
              accessibility, conditional premium styles, et cetera`}
            onClick={handleClick}>
            {buttonText}
          </button>
        </Tooltip>
      }
    />
  )
}

登入後複製

/vBucksButton
├── /hooks
│ ├── index.ts
│ └── useButtonState.hook.ts
├── /vBucksPopover
│ ├── /app1Popover
│ │ ├── /hooks
│ │ │ ├── index.ts
│ │ │ └── usePopoverState.hook.ts
│ │ ├── ...
│ ├── /app2Popover
│ ├── index.ts
│ ├── popover.renderer.tsx
│ ├── popover.styles.ts
│ ├── popover.tsx
│ └── popover.types.ts
├── /utils
│ ├── experimentation.util.ts
│ ├── store.util.ts
│ ├── telemetry.util.ts
│ └── vBucks.businessLogic.util.ts
├── button.renderer.tsx
├── button.styles.ts
├── button.tsx
├── button.types.ts
└── index.ts

登入後複製

旁白：TailwindCSS 文件明確建議不要使用 @apply 來提取這樣的公共類別。這導致包大小幾乎為零差異，除了“你必須想出類別名稱”之外沒有其他差異。生產級 CSS 幾乎總是有幾十行那麼長，乘以給定元件中需要樣式化的元素數量。這種權衡在 90% 的情況下似乎都是值得的。

其餘現有的和新的業務邏輯位於鉤子和實用程式中！

這種新架構滿足了狂熱者的需求，並使事情更容易擴展或
刪除或移動。

寫單元測試變得不那麼痛苦，因為你已經有了明確的定義
邊界。您的渲染器不再需要模擬十種不同的服務來
驗證它是否在給定一些輸入的情況下顯示了一組閃光。你的鉤子可以
單獨測試它們是否符合您預期的業務邏輯。

你的整個狀態層剛剛改變了嗎？如果您的
中的程式碼那就太可惜了鉤子與使用它的程式碼緊密耦合，但現在它更簡單
更改，您的渲染器仍然只是等待一些輸入。