我的 React 最佳實踐

可以看到，我們新增了 loading 變數，用來優化互動的程序，新增了 ITableProps 型別，用來宣告表格資料的型別，此時應當和服務端的同學溝通，從介面檔案中獲取到相關的資料結構，并補全這一塊的型別，

假設我們此時已經完成了型別的補全，那接下來我們需要完善 columns

const columns: ColumnType<ITableProps>[] = [];

這里存在部分分歧，有部分人認為需要加上 useMemo，
為什么不加 useMemo？

1. 因為 useMemo 主要是為了快取計算量比較大的值，而此處并沒有計算量，只是一個變數的宣告而已
2. 如果重復宣告 useMemo 的話，是否會導致 Table 的重復渲染，我認為過早的性能優化不如不優化，如果真的存在這樣子的問題再進行優化也不急，
3. 如果這里加上 useMemo 在某些情況下會有比較多的 depths 需要加到依賴項里，個人感覺這不優雅

在完善 columns 后，我們繼續剛才提到的 Pagination 和 total 欄位，
這里我們需要宣告兩個變數

const [pagination, setPagination] = useState({current: 1, pageSize: 20});
const [total, setTotal] = useState(0);

思考：這里的 total 和 pagination 是否可以合并成一個變數？

答：可以，但是我不愿意，因為我們后面會有存在如下代碼，會導致無限回圈

useEffect(() => { 
  // getDataSourceList 中存在改變 total 的值，會導致無限回圈
  // 如果要解決這個問題，則需要在 depths 中分別寫 current 和 pageSize
  // 我不愿意
  getDataSourceList();
},[pagination]);

然后接下來我們要實作請求功能，不難總結出我們需要在以下幾種情況下做請求：

• 頁面初始化
• Pagination 改變進行請求
• 篩選條件改變進行請求
• Table 的 filter 或 sorter 發生改變進行請求
• 互動修改資料后進行請求（如洗掉，新增等）

除了最后這個暫時不做考慮，第三和第四項的請求我們可以再細分為如圖所示

那么，就可以和前兩項進行合并，總結如下：

• 頁面初始化
• Pagination 改變

將上述思路轉化為代碼可得

function (){
  const [filter, setFilter] = useState<Record<string, any>>({
    a: undefined,
    b: undefined,
    c: undefined,
    d: undefined,
    sorter: undefined
  });
  const [pagination, setPagination] = useState({ current: 1, pageSize: 20 });

  const getDataSourceList = () => {};

  useEffect(() => {
    setPagination(p => ({ ...p, current: 1 }));
  }, [filter]);

  useEffect(() => {
    getDataSourceList();
  }, [pagination]);
}

到這里，我們已經實作了絕大部分主要功能，接下來我們簡單實作一個 selectedRows即可，

function (){
  const [selectedRows, setSelectedRows] = useState([]);

  return (
    <Table
      rowSelection={{
        selectedRowKeys,
        onChange: (selected) => setSelectedRows(selected)
      }}
    />
  )
}

問：為什么這里的 rowSelection 不提出來，放到 useMemo 里去？

至此，一個滿足業務的一類業務相關的框架代碼已經撰寫完成，
到這里之后，一類業務頁面還有剩下什么東西需要開發？

第二類

二類頁面的特點通常是新增和編輯復用同一個頁面，需要 Form 表單，

除此之外，通常二類頁面有通過 Drawer 或者 Modal 或者跳轉路由的方式，但這不影響代碼的書寫，
不論是 Drawer 還是 Modal 還是路由的方式，我們都需要將表單內容抽離出一個新的組件，

首先，我們看一個比較普遍且較為簡單的新增或編輯頁面

可以觀察到，這個表單通過 Steps 組件分割成了 3 個步驟

這里我們需要明確一個思想，即上面強調的 ，那么這里不論是新增還是編輯，其差異只存在于 data 中是否存在 id 值，
這里有兩種做法，第一種做法是 3 個步驟只用一個 Form，第二種做法是 3 個步驟 3 個 Form，我個人比較喜歡第一種做法，理由如下：

• 因為 data 是一份的，如果用第二種做法，需要將一份 data 拆分成三份
• 倘若出現在第一步中填寫某個值會影響第二步中的下拉項，如果是第二種做法，還需要將 Form 的值傳給第二步的組件，第一步的做法可以直接通過 form.getFieldValue('xxx')
• 無它，就是圖個簡潔

比較復雜的表單通常都有聯動情況，比如資料同步任務的表單，或者這里的資料源和表選擇的互動，
這一類互動在 antd@3 中通常實作起來會比較的繁瑣，在 antd@4中善用 dependencies和 onValuesChanged可以很好地解決這一類問題，

{[TRINO, KINGBASEES8, SAPHANA1X].includes(dataSourceType) && (
  <FormItem
    name="schemaName"
    label="選擇Schema"
    initialValue=https://www.cnblogs.com/dtux/archive/2022/11/02/{schemaName}
    rules={[
      {
        required: true,
        message:'請選擇Schema',
      },
    ]}
    >
    <Select
      showSearch
      style={{
        width: '100%',
      }}
      onSelect={this.onSchemaChange}
      onPopupScroll={this.handleSchemaScroll}
      onSearch={this.handleSchemaSearch}
      >
      {this.renderSchemaListOption(currentSchema)}
    </Select>
  </FormItem>
)}

如上代碼所示， schema 的欄位只有在所選擇的資料源是 xxx 這幾種情況下才會展示，如果我們按照上述代碼的寫法的話，需要在 state 中新增 dataSourceType欄位
那如果用 dependencies的話，可以改成如下寫法：

<FormItem noStyle dependencies={['sourceId']}>
  {({ getFieldValue }) => (
  isXXXXX(options.find(o => o.sourceId === getFieldValue('sourceId'))?.type) && (
    <FormItem
      name="schemaName"
      label="選擇Schema"
      initialValue=https://www.cnblogs.com/dtux/archive/2022/11/02/{schemaName}
      rules={[
        {
          required: true,
          message:'請選擇Schema',
        },
      ]}
      >
      <Select
        showSearch
        style={{
          width: '100%',
        }}
        onSelect={this.onSchemaChange}
        onPopupScroll={this.handleSchemaScroll}
        onSearch={this.handleSchemaSearch}
        >
        {this.renderSchemaListOption(currentSchema)}
      </Select>
    </FormItem>
  )
)}
</FormItem>

更進一步，可以把 find 抽象一個 getTypeBySourceId函式出來，即優化了可維護性，又減少了變數宣告，

除此之外，還有下拉選單的聯動，如 A 的選擇會引起 B 的下拉選單獲取，B 的下拉選單可能又會引起 C 的下拉選單改變，如此鏈路下去，會導致宣告的 handleChange 函式又多又長

function(){
  const handleAChanged = () => {};
  
  const handleBChanged = () => {};
  
  const handleCChanged = () => {};
  
  return (
    <Form>
      <FormItem name ="a">
        <Select onChange={handleAChanged} />
      </FormItem>
      <FormItem name ="b">
        <Select onChange={handleBChanged} />
      </FormItem>
      <FormItem name ="c">
        <Select onChange={handleCChanged} />
      </FormItem>
    </Form>
  )	
}

那我們可以借助 antd@4 的 onValuesChanged函式，來把所有相關組件的 onChange 做合并，即如下：

function(){
   const handleFormFieldChanged = (changed: Partial<IFormFieldProps>) => {
    if('a' in changed){
      // do something about a
      getOptionsForB();
      form.resetFields(['b', 'c']);
    }

    if('b' in changed){
      // do something about b
      getOptionsForC();
      form.resetFields(['c']);
    }

    if('c' in changed){
      // do something about c
      getOptionsForD();
    }
  }
  
  return (
    <Form onValuesChanged={handleFormFieldChanged}>
      <FormItem name ="a">
        <Select />
      </FormItem>
      <FormItem name ="b">
        <Select />
      </FormItem>
      <FormItem name ="c">
        <Select />
      </FormItem>
    </Form>
  )	
}

同時，在這個函式里我們也可以順便把 reset 的操作做了

到這里，我們大致完成了 Form 表單的架構思路，接下來，我們需要處理新增和編輯的區分，
通常來說，新增是不需要賦初始值的，而編輯是需要賦初始值的，
這里需要注意的點在于，我們所理解的初始值并不是 Form 組件中 initialValue 的含義，（至少我認為不是）
我認為 Form 組件的生命周期應當分為如下部分：

• 初始化階段（該階段 Form 表單用 initialValue把表單 UI 渲染出來）
• 賦值階段（該階段用戶通過 set 操作把初始值賦給表單的 state）
• 互動階段
• 提交階段

如上階段中說明所示，我認為初始值的操作應當通過 set 操作完成，那代碼實作起來應當如下所示：

function(){
  useEffect(() => {
    if(router.record.id){
      setLoading(true);
      api.getxxx({recordId: record.id}).then(res => {
        if(res.success){
          form.setFieldsValue({
            a: res.data.a,
            b: res.data.b
          })
        }
      }).finally(() => {
        setLoading(false);
      });
    }
  }, []);
}

把編輯的賦值操作全都放到 useEffect 中執行，統一了書寫的地方，有利于后期的維護，

總結后，可以得出整個 Form 表單頁面的概覽大致如下圖所示

相信各位同學到這里之后，面對一個表單的原型圖，心里已經有一個大致的偽代碼的實作了，

第三類

通常概覽頁面的要素是，統計資料、時間選擇、圖表，這一類頁面由于通常是作為用戶第一個打開的頁面，所以需要額外注意的是 loading 狀態的展示，

需要注意的是這里的 loading 會存在以下幾種情況：

• 整個頁面的 loading，這種情況通常是全域的一個時間選擇器，然后同時獲取統計資料和圖表，需要借助 Promise.all 或 Promise.allSettled 實作，
• 磁區域的 loading，如圖表區有圖表區的 loading，表格區有表格的 loading，統計資料區有統計資料區的 loading，這種時候需要把 loading 更加細分，為每一個區域增加 loading 變數，確保各個請求都有 loading 狀態展示

其他沒什么好說的，主要是 CSS 的要求會更高，大致的偽代碼會如下：

function(){
  const [options, setOptions] = useState({...defaultOptions});
  const [loading, setLoading] = useState(false);
  const [timeRange, setTimeRange] = useState([moment(), moment()]);
  const [statistic, setStatistic] = useState({
    a: 0,
    b: 0,
  });

  const getStatistic = () => {
    return new Promise((resolve) => {
      setStatistic({a: 1000, b: 30});
      resolve();
    });
  };

  const getCharts = () => {
    return new Promise((resolve) => {
      options.xxx = xxxx;
      setOptions({...options});
    });
  };

  useEffect(() => {
    setLoading(true);
    Promise.all([getStatistic(), getCharts()]).finally(() => {
      setLoading(false);
    });
  }, [timeRange]);


  return (
    <>
      <DateRange value=https://www.cnblogs.com/dtux/archive/2022/11/02/{timeRange} onChange={(val) => setTimeRange(val)} />
      
      
    
  )
}

代碼開發

通常來說，我個人的習慣是先實作需求，再進行代碼優化和分割，模塊的提取等，所以以下優化都是基于所有業務邏輯已經完成的情況下，

hooks

通常，在完成業務后，一個組件內部會包含大量的 hooks 相關的東西，通常優化手段如下：

• 減少 useState的使用，將不影響渲染的資料放到 useRef 里去，甚至說常量可以放到函式外部，同時，如果是同一個種類的可以進行合并
• 減少 useMemo 的時候，普通的賦值或宣告或簡單的計算完全不需要引入 useMemo，可以在復雜的計算時加上 useMemo
• 避免 useCallback 的使用，目前想到的 useCallback 的場景，只有addEventListener的時候，其余情況下大部分都用不到，
• useEffect 可以進行寫多個的，所以有些時候不同的邏輯可以放到不同的 useEffect 里去
• useRef 可以大量持有，useRef 能 cover 的場景遠大于 ref
• useContext在簡單場景下完全可以替代 redux，但是有性能問題，所以復雜場景下，建議是配合use-context-selector使用，或者選擇其他狀態管理工具，如：recoil
• useLayoutEffect 和 useEffect在絕大部分應用情況下沒有差異，只需要直接使用 useEffect 即可，目前考慮前者的唯一不可替代性僅存在于「閃爍」場景，
• useReducer 一般來說用不到，其使用場景應該是當存在多個資料，而某一個引數的改變會引起其他資料同時改變，從而引起頁面重渲染，

const initialState = {count: 0};

function reducer(state, action) {
  switch (action.type) {
    case 'increment':
      return {count: state.count + 1};
    case 'decrement':
      return {count: state.count - 1};
    default:
      throw new Error();
  }
}

function Counter() {
  const [state, dispatch] = useReducer(reducer, initialState);
  return (
    <>
      Count: {state.count}
      <button onClick={() => dispatch({type: 'decrement'})}>-</button>
      <button onClick={() => dispatch({type: 'increment'})}>+</button>
    </>
  );
}

• useImperativeHandler在通常情況下避免使用，使用場景應該只有兩種，第一種是要做 ref 的轉發，比如封裝了一個組件，需要把組件內部的某一個 input 的 ref 轉發給父組件，第二種是封裝了一個組件，該組件內部實作邏輯是非 JSX 的，存在實體，則需要通過該 hooks 把相關實體轉發給父組件，
• useDebugValue不熟
• useDeferredValue不熟
• useTransition不熟
• useId不熟
• useSyncExternalStore不熟
• useInsertionEffect不熟

Ant Design 相關

眾所周知，React 庫搭配 Ant Design 食用是后臺管理系統的高效的原因之一，
Ant Design 相關實踐如下：

• 巧用 Space 組件，個人感覺有點類似于簡單場景的 Grid 組件
• 復雜表單經常使用 Steps 做步驟分割，個人更加推薦 Steps+Form 而不是 Steps.item+Form
• AutoComplete 個人感覺有很多問題，譬如資料回填高亮等問題，個人感覺不如直接 Input
• Form組件比較復雜，且配合其他組件的用法比較多，如 Form+Steps Form+Tabs Form+Modal 等，需要注意 inactiveDestroy + preserve={false}，另外需要注意 requiredMark 和 required 的區別，validator 和其他 rules 的區別，setFieldsValue 和 setFields 的區別
• Input等輸入控制元件需要注意 placeholder 的值，Select 需要額外主要 allowSearch
• Select個人習慣直接通過 options 賦值，而不是 children（原因：相比 jsx 會有更加好的渲染性能）
• select可以通過 dropdownRender自定義下拉內容
• Tree 組件面向的場景比較復雜的情況下，個人覺得 antd 的 tree 組件不好用，偏向于自己手寫
• 所有的 popup 相關組件都可以設定 getPopupContainer，該屬性用來修改組件渲染位置，如果遇到彈出層沒有隨滾動條滾動可以設定，但是設定完可能需要考慮 overflow:hidden 的問題
• Table組件的 rowKey 屬性很重要，必加，
• 需要注意 Table + Modal 的寫法，不要把 Modal 寫到操作列里面去
• Modal 和 Drawer組件不推薦用 visible && <Modal />的寫法，會導致影片丟失，建議在寫 Modal 或者 Drawer 的時候，把「空狀態」考慮進去，同時可以配合 Modal 的 destroyOnClose屬性可以讓每次 Modal 打開內容都是新內容，（PS：Form 除外）
• Spin 可以多，但不能少

其他

• 愛惜你的 div，不要動不動就搞個 div，過多的層級結構會影響加載速度的，量變引起質變
• 盡量避免 ref 的使用，在通常情況下如果考慮用 ref 解決問題的話，那可能代表了你的思路不對或代碼設計不對，
• 有時候，可以用 IIFE，做到不脫離當前的背景關系，又實作了相關邏輯的提取，比函式中定義函式更好一些，

總結

以上的相關實踐，是本人在榷訓月累中總結和摸索出來的，
如有雷同，說明你和我有一樣的感受，

標籤：其他

上一篇：谷歌瀏覽器插件MV3報錯"Uncaught ReferenceError: window is not defined"

下一篇：(ECMAScript)ES標準下中的let、var和const