阿川私房教材：學程式，拿 offer！

63 個專案實戰，直接上手！
無需補習，按步驟打造你的面試作品。

小編精選 - 技術文章翻譯 · 03月15日

前端開發者的 5 個基本實務（React 版）

介紹

前端開發者的 5 個基本實務（React 版）

踏上新的職業旅程常伴隨著興奮和高期望。然而，當面對類似混亂謎題的程式碼庫時，現實可能會截然不同。為了緩解這種常見情況，特別是對於擔任高階角色的開發人員來說，採用特定的最佳實踐勢在必行。這不僅可以確保程式碼品質，還可以讓您成為一絲不苟的專業人士，獲得公司內部的認可和潛在的晉升。

前端開發者的 5 個基本實務（React 版）

最優路徑處理：絕對路徑優於相對路徑

想像一下，在迷宮中航行時，除了「後退四步，左轉兩次」這樣的神秘線索外，什麼都沒有。這就是程式碼中相對路徑的感覺。相反，擁抱絕對路徑的力量！這些提供了文件的完整地址，使導入變得一目了然，並使您免於無休止的猜測遊戲。設定它們可能需要使用 Webpack 或 TypeScript 等工具進行一些配置魔法，但相信我們，這是值得的。

額外提示：對於使用 create-react-app 的專案，一個簡單的 jsconfig.json 檔案可以成為你的英雄。只需幾行程式碼，您就可以定義導入的基本 URL，將怪物路徑 ../../../../../components/Button 轉換為時尚的 @/components/Button。

如果您使用 TypeScript，請將下列設定新增至「tsconfig.json」檔案：

{
  "compilerOptions": {
    "baseUrl": "src",
    "paths": {
      "@/*": ["src/*"]
    }
  },
  "include": ["src"]
}

透過這樣做，您可以將程式碼片段轉換為如下所示：

//from this
import { Button } from '../../../../components/Button'
import { Icon } from '../../../../components/Icon'
import { Input } from '../../../../components/Input'
Into something cleaner and easier to read, like:
//to this
import { Button } from '@/components/Button'
import { Icon } from '@/components/Icon'
import { Input } from '@/components/Input'

2.精簡模組組織：「出口桶」的威力

「導出桶」技術（也稱為「再導出」）大大提高了程式碼的可讀性和維護性。在資料夾中建立“index.js”（或 TypeScript 的“index.ts”）檔案並匯出所有模組可以簡化匯入並增強程式碼組織。

實施例：

想像一個包含「Button.tsx」、「Icon.tsx」和「Input.tsx」的「元件」資料夾。利用“匯出桶”，您可以建立一個“index.ts”檔案來簡化導入：

export * from './Button'
export * from './Icon'
export * from './Input'

這種做法不僅減少了單獨導入的需求，還有助於建立更清晰、更易於理解的程式碼庫——這對於中型到大型專案至關重要。

選擇“預設導出”和“命名導出”

當我們深入研究「出口桶」主題時，必須注意它可能與「出口預設」的使用相衝突。如果這還不清楚，我將舉例說明情況：

讓我們回到我們的元件：

export const Button = () => {
  return <button>Button</button>
}
export default Button
export const Icon = () => {
  return <svg>Icon</svg>
}
export default Icon
export const Input = () => {
  return <input />
}
export default Input

想像一下，每個元件都在一個單獨的檔案中，並且您希望一次匯入所有元件。如果您習慣預設導入，您可以嘗試以下操作：

import Button from '@/components'
import Icon from '@/components'
import Input from '@/components'

但是，這不起作用，因為 JavaScript 無法確定要使用哪個“導出預設值”，從而導致錯誤。你將被迫做這樣的事情：

import Button from '@/components/Button'
import Icon from '@/components/Icon'
import Input from '@/components/Input'

然而，這抵消了「出口桶」的優勢。如何解決這個困境？解決方案很簡單：使用“命名導出”，即不使用“預設”導出：

import { Button, Icon, Input } from '@/components'

與「匯出預設值」相關的另一個關鍵問題是重新命名導入內容的能力。我將分享我職業生涯早期的一個現實生活中的例子。我繼承了一個 React Native 專案，之前的開發人員對所有內容都使用「匯出預設值」。有一些名為「登入」、「註冊」和「忘記密碼」的畫面。然而，所有三個螢幕都是彼此的副本，並進行了微小的修改。問題是，在每個螢幕檔案的末尾，都有一個「匯出預設登入」。這導致了混亂，因為路由文件導入正確：

import Login from '../../screens/Login'
import Register from '../../screens/Register'
import ForgotPassword from '../../screens/ForgotPassword'

// Further down, the usage in routes:

  {
    ResetPassword: { screen: ResetPassword },
    Login: { screen: LoginScreen },
    Register: { screen: RegisterScreen },
  }

但是當打開螢幕檔案時，它們都導出相同的名稱：


const login() {
  return <>tela de login</>
}
export default Login
const login() {
  return <>tela de registro</>
}
export default Login
const login() {
  return <>tela de esqueci minha senha</>
}
export default Login

這造成了維護的噩夢，伴隨著持續的混亂，並且需要極度警惕以避免錯誤。

總之，強烈建議在專案中的大多數情況下使用“命名導出”，並僅在絕對必要時才使用“預設導出”。在某些情況下，例如 Next.js 路由和 React.lazy，可能需要使用「匯出預設值」。然而，在程式碼清晰度和符合特定要求之間取得平衡至關重要。

正確的文件命名約定

假設您有一個包含以下文件的元件資料夾：

--components:
----Button.tsx
----Icon.tsx
----Input.tsx

現在，假設您想要將這些元件的樣式、邏輯或類型分開到單獨的文件中。你會如何命名這些文件？一個明顯的方法可能如下：

--components:
----Button.tsx
----Button.styles.css
----Icon.tsx
----Icon.styles.css
----Input.tsx
----Input.styles.css

當然，這種方法可能看起來有些混亂且難以理解，特別是當您打算將元件進一步劃分為不同的文件（例如邏輯或類型）時。但如何才能保持結構井井有條呢？這是解決方案：

--components:
----Button
------index.ts (exports everything necessary)
------types.ts
------styles.css
------utils.ts
------component.tsx
----Icon
------index.ts (exports everything necessary)
------types.ts
------styles.css
------utils.ts
------component.tsx
----Input
------index.ts (exports everything necessary)
------types.ts
------styles.css
------utils.ts
------component.tsx

這種方法可以輕鬆辨識每個文件的用途，並簡化對所需內容的搜尋。此外，如果您使用 Next.js 或類似框架，則可以調整檔案命名以指示該元件是用於客戶端還是伺服器端。例如：

--components:
----RandomComponent
------index.ts (exports everything necessary)
------types.ts
------styles.css
------utils.ts
------component.tsx
----RandomComponent2
------index.ts (exports everything necessary)
------types.ts
------styles.css
------utils.ts
------component.server.tsx

這樣，區分元件是用於客戶端還是伺服器端變得非常簡單，而無需打開程式碼進行驗證。組織和標準化文件命名對於保持開發專案的清晰度和效率至關重要。

5.正確使用ESLint和Prettier進行程式碼標準化

想像一下您與 10 多名同事一起處理一個專案，每個人都從過去的經驗中汲取了自己的編碼風格。這就是 ESLint 和 Prettier 發揮作用的地方。他們在維護整個團隊的程式碼一致性方面發揮著至關重要的作用。

Prettier 充當程式碼格式的“守護者”，確保每個人都遵守為專案設定的風格指南。例如，如果專案標準規定使用雙引號，則您不能簡單地選擇單引號，因為 Prettier 會自動替換它們。此外，Prettier 還可以執行各種其他修復和格式化，例如程式碼對齊、在語句末尾加入分號等等。具體的 Prettier 規則可以查看官方文件：Prettier Options。

另一方面，ESLint 對程式碼強制執行特定規則，有助於維護有凝聚力和連貫性的程式碼庫。例如，它可以強制使用箭頭函數而不是常規函數，確保正確填充 React 依賴項陣列，禁止使用“var”聲明以支援“let”和“const”，並應用駝峰命名法等命名約定。具體的ESLint規則可以在官方文件：ESLint Rules中找到。

ESLint 和 Prettier 的結合使用有助於保持原始程式碼的一致性。如果沒有它們，每個開發人員都可以遵循自己的風格，這可能會導致將來出現衝突和維護困難。設定這些工具對於專案的長壽至關重要，因為它有助於保持程式碼的組織性和易於理解。如果您還沒有使用 ESLint 和 Prettier，請認真考慮將它們合併到您的工作流程中，因為它們將使您的團隊和整個專案受益匪淺。