重新定義受控與非受控組件的邊界
對非受控組件與受控組件作了如圖中下劃線的邊界定義。一經推敲, 該定義是缺乏了些完整性和嚴謹性的, 比如針對非表單組件(彈框、輪播圖)如何劃分受控與非受控的邊界? 又比如非受控組件是否真的如文案上所說的數據的展示與變更都由 dom 自身接管呢?
在非受控組件中, 通常業務調用方只需傳入一個初始默認值便可使用該組件。以 Input 組件為例:
// 組件提供方
function Input({ defaultValue }) {
return <input defaultValue={defaultValue} />
}
// 調用方
function Demo() {
return <Input defaultValue={1} />
}在受控組件中, 數值的展示與變更則分別由組件的 state 與 setState 接管。同樣以 Input 組件為例:
// 組件提供方
function Input() {
const [value, setValue] = React.useState(1)
return <input value={value} onChange={e => setValue(e.target.value)} />
}
// 調用方
function Demo() {
return <Input />
}有意思的一個問題來了, Input 組件到底是受控的還是非受控的? 我們甚至還可以對代碼稍加改動成 <Input defaultValue={1} /> 的最初調用方式:
// 組件提供方
function Input({ defaultValue }) {
const [value, setValue] = React.useState(defaultValue)
return <input value={value} onChange={e => setValue(e.target.value)} />
}
// 調用方
function Demo() {
return <Input defaultValue={1} />
}儘管此時 Input 組件本身是一個受控組件, 但與之相對的調用方失去了更改 Input 組件值的控制權, 所以對調用方而言, Input 組件是一個非受控組件。值得一提的是, 以非受控組件的使用方式去調用受控組件是一種反模式, 在下文中會分析其中的弊端。
如何做到不管對於組件提供方還是調用方 Input 組件都為受控組件呢? 提供方讓出控制權即可, 調整代碼如下:
// 組件提供方
function Input({ value, onChange }) {
return <input value={value} onChange={onChange} />
}
// 調用方
function Demo() {
const [value, setValue] = React.useState(1)
return <Input value={value} onChange={e => setValue(e.target.value)} />
}經過上述代碼的推演后, 概括如下: 受控以及非受控組件的邊界劃分取決於當前組件對於子組件值的變更是否擁有控制權。如若有則該子組件是當前組件的受控組件; 如若沒有則該子組件是當前組件的非受控組件。
職能範圍
基於調用方對於受控組件擁有控制權這一認知, 因此受控組件相較非受控組件能賦予調用方更多的定製化職能。這一思路與軟件開發中的有異曲同工之妙, 同時讓筆者受益匪淺的 也是類似的思想。
藉助受控組件的賦能, 以 Input 組件為例, 比如調用方可以更為自由地對值進行校驗限制, 又比如在值發生變更時執行一些額外邏輯。
// 組件提供方
function Input({ value, onChange }) {
return <input value={value} onChange={onChange} />
}
// 調用方
function Demo() {
const [value, setValue] = React.useState(1)
return <Input value={value} onChange={e =>
// 只支持數值的變更
if (/\D/.test(e.target.value)) return
setValue(e.target.value)}
/>
}因此綜合基礎組件擴展性與通用性的考慮, 受控組件的職能相較非受控組件更加寬泛, 建議優先使用受控組件來構建基礎組件。
反模式 —— 以非受控組件的使用方式調用受控組件
首先何謂反模式? 筆者將其總結為增大隱性 bug 出現概率的模式, 該模式是最佳實踐的對立經驗。如若使用了反模式就不得不花更多的精力去避免潛在 bug。官網對反模式也有很好的。
緣何上文提到以非受控組件的使用方式去調用受控組件是一種反模式? 觀察 Input 組件的第一行代碼, 其將 defaultValue 賦值給 value, 這種將 props 賦值給 state 的賦值行為在一定程度上會增加某些隱性 bug 的出現概率。
比如在切換導航欄的場景中, 恰巧兩個導航中傳進組件的 defaultValue 是相同的值, 在導航切換的過程中便會將導航一中的 Input 的狀態值帶到導航二中, 這顯然會讓使用方感到困惑。
// 組件提供方
function Input({ defaultValue }) {
// 反模式
const [value, setValue] = React.useState(defaultValue);
React.useEffect(() => {
setValue(defaultValue);
}, [defaultValue]);
return <input value={value} onChange={e => setValue(e.target.value)} />;
}
// 調用方
function Demo({ defaultValue }) {
return <Input defaultValue={defaultValue} />;
}
function App() {
const [tab, setTab] = React.useState(1);
return (
<>
{tab === 1 ? <Demo defaultValue={1} /> : <Demo defaultValue={1} />}
<button onClick={() => (tab === 1 ? setTab(2) : setTab(1))}>
切換 Tab
</button>
</>
);
}如何避免使用該反模式同時有效解決問題呢? 官方提供了兩種較為優質的解法, 將其留給大家作為思考。
- 方法一: (更為推薦)
- 方法二:
歡迎關注
本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】
※網頁設計公司推薦更多不同的設計風格，搶佔消費者視覺第一線
※廣告預算用在刀口上，網站設計公司幫您達到更多曝光效益
※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象
