介紹
踏上新的職業旅程常伴隨著興奮和高期望。然而，當面對類似混亂謎題的程式碼庫時，現實可能會截然不同。為了緩解這種常見情況，特別是對於擔任高階角色的開發人員來說，採用特定的最佳實踐勢在必行。這不僅可以確保程式碼品質，還可以讓您成為一絲不苟的專業人士，獲得公司內部的認可和潛在的晉升。
-
最優路徑處理：絕對路徑優於相對路徑
想像一下，在迷宮中航行時，除了「後退四步，左轉兩次」這樣的神秘線索外，什麼都沒有。這就是程式碼中相對路徑的感覺。相反，擁抱絕對路徑的力量！這些提供了文件的完整地址，使導入變得一目了然，並使您免於無休止的猜測遊戲。設定它們可能需要使用 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，請認真考慮將它們合併到您的工作流程中，因為它們將使您的團隊和整個專案受益匪淺。
結論：
透過將這些最佳實踐合併到您的 React 開發工作流程中，您可以為一個更有組織、可讀和可維護的程式碼庫做出貢獻。繼續致力於提高編碼標準，如果您發現這些做法有用，請不要忘記按讚🦄！快樂編碼！ 🚀
原文出處：https://dev.to/sufian/5-essential-practices-for-front-end-developers-react-edition-3h96
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式