模組化 React 架構

淺談模組化架構

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

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

要求以及如何找到它們

我們的網站有一個位於網站標題中的按鈕。它顯示有多少
使用者已經離開了 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% 的情況下似乎都是值得的。

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

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

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

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

最後的想法

這種模組化架構增加了大量樣板，最終可以提供
零利益。

如果您正在從事一個充滿熱情的專案或
，我實際上無法推薦它 優先考慮運輸和提供價值。如果你有
的東西 似乎它的範圍可能會隨著時間的推移而擴大，或者您可能想要
在 POC 後進行徹底檢修，有時可以減少技術債。

您可以使用 Plop 等工具來產生此樣板。

那我從 Jimbo 的工作和模組化架構中真正學到了什麼？

我們在學校和世界各地的 Well Ackshuallys 中學習的乾淨程式碼和縮寫
是一系列的一端。將功能性義大利麵程式碼組合在一起是另一回事
結束，並且通常效果很好，因為最終所有代碼都是技術債。

最佳解存在於某種量子態或這些末端的組合中，而
我們選擇的路徑可能取決於：

• 我們有多在乎我們正在建造的東西
• 管理階層要求更新和預計到達時間的頻率
• 讀到這樣的東西，一種方法剛好出現在你的 當你建構下一個東西的意識
• 沮喪、痛苦
• 義大利麵變成了效能瓶頸，你必須重寫它
• 樣板檔案變得如此枯燥，以至於你不得不偷工減料

以上是模組化 React 架構的詳細內容。更多資訊請關注PHP中文網其他相關文章！