解決React應用界面開發常見痛點(一)業務邏輯與UI分離

前言:本系列是針對於React在界面開發痛點的一些解決方案,只是React應用中偏向展示的一環

構建一個業務與UI分離的react應用

本篇是基於HOC方案並未使用Hooks

業務邏輯與UI

在編寫一個react組件前,我們一定要弄清兩件事。

  1. 什麼是UI?
  2. 什麼是業務邏輯?

UI:組件的具體展示元素,通俗點就是組件的長相。接受到合理的數據就可以展示出一個合格的組件。

業務邏輯:獲取數據、發送請求等等有比較明確的獨特業務的邏輯。

為什麼要業務邏輯與UI分離?

在編寫react組件的時候,經常會出現業務邏輯相似,UI基本相同的組件,可能只是獲取的數據方式有一些不同。

for example: 掘金的感興趣小冊列表為例子

解決React應用界面開發常見痛點(一)業務邏輯與UI分離

  1. 最外層的紅框為這個小冊的組件Booklet
  2. 左側的是小冊的封面
  3. 右側上方的是小冊的名稱
  4. 購買人數
  5. 小冊的鏈接

以上這些都是Booklet組件的UI元素

在Component中:

Booklet組件只需要知道以下數據就可以正常工作:

  1. 小冊的封面(imageUrl)
  2. 小冊的名稱(name)
  3. 購買人數(buyerNums)
  4. 鏈接(link)

UI組件並不需要知道:

  1. 如何獲取數據,(如何根據小冊id如何獲取到的)
  2. 數據何時回來,(請求結束填充數據)
  3. 請求的具體處理,(請求開始、結束、容錯、什麼時候開始loading等等)

以上這些應該在哪裡處理?

在Container中

  1. 根據小冊ID獲取數據。
  2. 判斷請求的當前狀態。(loading、error、success、cancel)。
  3. 製作好數據傳遞給Component

想要分離UI與業務邏輯時遇到的常見痛點

  1. 生命週期中包含請求代碼,不好抽離。
  2. 內部state導致組件後續擴展能力差。

如何解決以上問題。

recompose可以合理解決以上問題。

在傳統的寫法中:

<code>path: components/card/index.jsxclass Card extends React.PureComponent {     

state = {
name: undefined,
link: undefined,
buyerNum: undefined,
logoUrl: undefined,
}
componentDidMount() {
getCardById(this.props.id).then(card => {
const {name ,link, buyerNum, logoUrl} = card;
this.setState({
name,
link,
buyerNum,
logoUrl,
})
});
}
render() {
const {name ,link, buyerNum, logoUrl} = this.state;
return (


{name}


{name}


{buyerNum}人已購買





)
}}/<code>

上面的代碼就是標準的業務與UI不分離

難以維護的影響

後續需求仍然使用這個卡片組件的UI,但是變成了卡片列表包含多個卡片,使用卡片id獲取卡片數據的業務邏輯就很不合理。

如何解決?

UI與業務分離

UI層


解決React應用界面開發常見痛點(一)業務邏輯與UI分離

業務邏輯層


解決React應用界面開發常見痛點(一)業務邏輯與UI分離


新的代碼種Card的UI組件不再被任何業務邏輯干擾。Card的container包含了本次根據id獲取卡片的業務邏輯。如果後續需要卡片列表。只需要一個CardList的container去獲取數據,渲染Card的UI組件。

UI與業務分離的思路已經講完了。

下一期會講一講reselect這個簡潔的第三方庫如何減少react組件無意義的render。


分享到:


相關文章: