{props.title}
{renderBody()}
{renderFooter()}
我們通常會在組件文件頂部導入組件所需的依賴項。對于不同類別的依賴項,建議對它們進行分組,這有助于幫助我們更好的理解組件??梢詫氲囊蕾嚪譃樗念悾?/p>

創(chuàng)新互聯(lián)從2013年成立,是專業(yè)互聯(lián)網(wǎng)技術(shù)服務(wù)公司,擁有項目成都網(wǎng)站設(shè)計、成都網(wǎng)站建設(shè)網(wǎng)站策劃,項目實施與項目整合能力。我們以讓每一個夢想脫穎而出為使命,1280元天山做網(wǎng)站,已為上家服務(wù),為天山各地企業(yè)和個人服務(wù),聯(lián)系電話:18980820575
// 外部依賴
import React from "react";
import { useRouter } from "next/router";
// 內(nèi)部依賴
import { Button } from "../src/components/button";
// 本地依賴
import { Tag } from "./tag";
import { Subscribe } from "./subscribe";
// 樣式
import styles from "./article.module.scss";
對導入依賴項進行手動分組可能比較麻煩,Prettier 可以幫助我們自動格式化代碼。可以使用 prettier-plugin-sort-imports 插件來自動格式化依賴項導入。需要在項目根目錄創(chuàng)建prettier.config.js配置文件,并在里面配置規(guī)則:
module.exports = {
// 其他 Prettier 配置
importOrder: [
// 默認情況下,首先會放置外部依賴項
// 內(nèi)部依賴
"^../(.*)",
// 本地依賴項,樣式除外
"^./((?!scss).)*$",
// 其他
"^./(.*)",
],
importOrderSeparation: true,
};
下面是該插件官方給出的例子,輸入如下:
import React, {
FC,
useEffect,
useRef,
ChangeEvent,
KeyboardEvent,
} from 'react';
import { logger } from '@core/logger';
import { reduce, debounce } from 'lodash';
import { Message } from '../Message';
import { createServer } from '@server/node';
import { Alert } from '@ui/Alert';
import { repeat, filter, add } from '../utils';
import { initializeApp } from '@core/app';
import { Popup } from '@ui/Popup';
import { createConnection } from '@server/database';
格式化之后的輸出如下:
import { debounce, reduce } from 'lodash';
import React, {
ChangeEvent,
FC,
KeyboardEvent,
useEffect,
useRef,
} from 'react';
import { createConnection } from '@server/database';
import { createServer } from '@server/node';
import { initializeApp } from '@core/app';
import { logger } from '@core/logger';
import { Alert } from '@ui/Alert';
import { Popup } from '@ui/Popup';
import { Message } from '../Message';
import { add, filter, repeat } from '../utils';
prettier-plugin-sort-imports:https://github.com/trivago/prettier-plugin-sort-imports
在導入依賴項的下方,通常會放那些使用 TypeScript 或 Flow 等靜態(tài)類型檢查器定義的文件級常量和類型定義。
組件中的所有 magic 值,例如字符串或者數(shù)字,都應(yīng)該放在文件的頂部,導入依賴項的下方。由于這些都是靜態(tài)常量,這意味著它們的值不會改變。因此將它們放在組件中是沒有意義的,因為放在組件中的話,它們會在每次重新渲染組件時重新創(chuàng)建。
const MAX_READING_TIME = 10;
const META_TITLE = "Hello World";
對于更復雜的靜態(tài)數(shù)據(jù)結(jié)構(gòu),可以將其提取到一個單獨的文件中,以保持組件代碼整潔。
下面是使用 TypeScript 聲明的組件 props 的類型:
interface Props {
id: number;
name: string;
title: string;
meta: Metadata;
}如果這個 props 的類型不需要導出,可以使用 Props 作為接口名稱,這樣可以幫助我們立即識別組件 props 的類型定義,并將其與其他類型區(qū)分開。
只有當這個 Props 類型需要在多個組件中使用時,才需要添加組件名稱,例如ButtonProps,因為它在導入另一個組件時,不應(yīng)該與另一個組件的Props類型沖突。
定義函數(shù)組件的方式有兩種:函數(shù)聲明和箭頭函數(shù), 推薦使用函數(shù)聲明的形式,因為這就是語法聲明的內(nèi)容:函數(shù)。官方文檔的示例中也使用了這種方法:
function Article(props: Props) {
/**/
}只會在必須使用 forwardRef 時才使用箭頭函數(shù):
const Article = React.forwardRef(
(props, ref) => {
/**/
}
);
通常會在組件最后默認導出組件:
export default Article;
接下來,我們就需要在組件里面進行變量的聲明。注意,即使使用 const 聲明,這里也稱為變量,因為它們的值通常會在不同的渲染之間發(fā)生變化,只有在執(zhí)行單個渲染過程時是恒定的。
https://back-media.51cto.com/editor?id=708865/h26976cb-bHg6me3D
這里通常包含在組件級別使用的所有變量,使用 const 或 let 定義,具體取決于它們在渲染期間是否更改其值:
一些較大的組件可能需要在組件中聲明很多變量。這種情況下,建議根據(jù)它們的初始化方法或者用途對它們進行分組:
// 框架 hooks
const router = useRouter();
// 自定義 hooks
const user = useLoggedUser();
const theme = useTheme();
// 從 props 中解構(gòu)的數(shù)據(jù)
const { id, title, meta, content, onSubscribe, tags } = props;
const { image, author, date } = meta;
// 組件狀態(tài)
const [email, setEmail] = React.useState("");
const [showMenu, toggleMenu] = React.useState(false);
const [activeTag, dispatch] = React.useReducer(reducer, tags);
// 記憶數(shù)據(jù)
const subscribe = React.useCallback(onSubscribe, [id]);
const summary = React.useMemo(() => getSummary(content), [content]);
// refs
const sideMenuRef = useRef(null);
const subscribeRef = useRef(null);
// 計算數(shù)據(jù)
const initials = getInitials(author);
const formattedDate = getDate(date);
變量分組的方法在不同組件之間可能會存在很大的差異,它取決于變量的數(shù)量和類型。關(guān)鍵是要將相關(guān)變量放在一起,在不同組之間添加一個空行來提高代碼的可讀性。
注:上面代碼中的注釋僅用于標注分組類型,在實際項目中不會寫這些注釋。
Effects 部分通常會寫在變量聲明之后,它們可能是React中最復雜的構(gòu)造,但從語法的角度來看它們非常簡單:
useEffect(() => {
setLogo(theme === "dark" ? "white" : "black");
}, [theme]);任何包含在effect之內(nèi)但是在其外部定義的變量,都應(yīng)該包含在依賴項的數(shù)組中。
除此之外,還應(yīng)該使用return來清理副作用:
useEffect(() => {
function onScroll() {
/*...*/
}
window.addEventListener("scroll", onScroll);
return () => window.removeEventListener("scroll", onScroll);
}, []);組件的核心就是它的內(nèi)容,React 組件的內(nèi)容使用 JSX 語法定義并在瀏覽器中呈現(xiàn)為 HTML。所以,推薦將函數(shù)組件的 return 語句盡可能靠近文件的頂部。其他一切都只是細節(jié),它們應(yīng)該放在文件較下的位置。
function Article(props: Props) {
// 變量聲明
// effects
// 自定義的函數(shù)不建議放在 return 部分的前面
function getInitials() {
/*...*/
}
return /* content */;
}
export default Article;function Article(props: Props) {
// 變量聲明
// effects
return /* content */;
// 自定義的函數(shù)建議放在 return 部分的后面
function getInitials() {
/*...*/
}
}
export default Article;難道return不應(yīng)該放在函數(shù)的最后嗎?其實不然,對于常規(guī)函數(shù),肯定是要將return放在最后的。然而,React組件并不是簡單的函數(shù),它們通常包含具有各種用途的嵌套函數(shù),例如事件處理程序。最后的return語句以及前面的一堆其他函數(shù),實際上阻礙了代碼的閱讀,使得很難找到組件渲染的內(nèi)容:
當然,可以根據(jù)個人喜好來決定函數(shù)定義的位置。如果將函數(shù)放在return的下方,那么如果想要使用箭頭函數(shù)來自定義函數(shù),那就只能使用var來定義,因為let和const不存在變量提升,不能在定義的箭頭函數(shù)之前使用它。
在處理大型 JSX 代碼時,將某些內(nèi)容塊提取為單獨的函數(shù)來渲染組件的一部分是很有幫助的,類似于將大型函數(shù)分解為多個較小的函數(shù)。
function Article(props: Props) {
// ...
return (
{props.title}
{renderBody()}
{renderFooter()}
);
function renderBody() {
return /* article body JSX */;
}
function renderFooter() {
return /* article footer JSX */;
}
}
export default Article;那為什么不將它們提取為組件呢?關(guān)于部分渲染函數(shù)其實是存在爭議的,一種說法是要避免從組件內(nèi)定義的任何函數(shù)中返回 JSX,另一種說法是將這些函數(shù)提取為單獨的組件。
function Article(props: Props) {
// ...
return (
{props.title}
);
}
export default Article;
function ArticleBody(props: Props) {}
function ArticleFooter(props: Props) {}在這種情況下,就必須手動將子組件所需的局部變量通過props傳遞。在使用 TypeScript 時,我們還需要為組件的props定義額外的類型。最終代碼就會變得臃腫,這就會導致代碼變得難以閱讀和理解:
function Article(props: Props) {
const [status, setStatus] = useState("");
return (
{props.title}
);
}
export default Article;
interface BodyProps extends Props {
status: string;
}
interface FooterProps extends Props {
setStatus: Dispatch>;
}
function ArticleBody(props: BodyProps) {}
function ArticleFooter(props: FooterProps) {} 這些單獨的組件不可以重復使用,它們僅被它們所屬的組件使用,單獨使用它們是沒有意義的。因此,這種情況下,還是建議將部分 JSX 提取成渲染函數(shù)。
React 組件通常會包含事件處理函數(shù),它們是嵌套函數(shù),通常會更改組件的內(nèi)部狀態(tài)或調(diào)度操作以更新組件的狀態(tài)。
另一類嵌套函數(shù)就是閉包,它們是讀取組件狀態(tài)或props的不純函數(shù),用于構(gòu)建組件邏輯。
function Article(props: Props) {
const [email, setEmail] = useState("");
return (
{/* ... */}
);
// 事件處理
function subscribe(): void {
if (canSubscribe()) {
// 發(fā)送訂閱請求
}
}
function canSubscribe(): boolean {
// 基于 props 和 state 的邏輯
}
}
export default Article;最后就是純函數(shù),我們可以將它們放在組件文件的底部,在 React 組件之外:
function Article(props: Props) {
// ...
// 純函數(shù)不應(yīng)該放在組件之中
function getInitials(str: string) {}
}
export default Article;function Article(props: Props) {
// ...
}
// 純函數(shù)應(yīng)該放在組件之外
function getInitials(str: string) {}
export default Article;首先,純函數(shù)沒有依賴項,如 props、狀態(tài)或局部變量,它們接收所有依賴項作為參數(shù)。 這意味著可以將它們放在任何地方。 但是,將它們放在組件之外還有其他原因:
完整示例下面是一個完整的典型 React 組件示例。由于重點是文件的結(jié)構(gòu),因此省略了實現(xiàn)細節(jié)。
// 1?? 導入依賴項
import React from "react";
import { Tag } from "./tag";
import styles from "./article.module.scss";
// 2?? 靜態(tài)定義
const MAX_READING_TIME = 10;
interface Props {
id: number;
name: string;
title: string;
meta: Metadata;
}
// 3?? 組件定義
function Article(props: Props) {
// 4?? 變量定義
const router = useRouter();
const theme = useTheme();
const { id, title, content, onSubscribe } = props;
const { image, author, date } = meta;
const [email, setEmail] = React.useState("");
const [showMenu, toggleMenu] = React.useState(false);
const summary = React.useMemo(() => getSummary(content), [content]);
const initials = getInitials(author);
const formattedDate = getDate(date);
// 5?? effects
React.useEffect(() => {
// ...
}, []);
// 6?? 渲染內(nèi)容
return (
{title}
{renderBody()}
);
// 7?? 部分渲染
function renderBody() { /*...*/ }
function renderSubscribe() { /*...*/ }
// 8?? 局部函數(shù)
function subscribe() { /*...*/ }
}
// 9?? 純函數(shù)
function getInitials(str: string) { /*...*/ }
export default Article;
參考:https://andreipfeiffer.dev/blog/2021/react-components-anatomy