大家好，我是林三心，用最通俗易懂的話講最難的知識點是我的座右銘，基礎是進階的前提是我的初心~

本文源碼地址：https://github.com/sanxin-lin/use-dsp

背景

在平時的開發中，表格數據->(增加/編輯/查看)行->(增加/編輯)提交，這是很常見且簡單的業務，但是就是這些業務，我也發現一些問題

圖片

首先我們來理性一下這些業務的邏輯

• 第一步：請求回表格的數據
• 第二步：點開(增加/編輯/查看)彈窗，如果是(編輯/查看)，則需要將表格行的數據傳到彈窗中回顯
• 第三部：如果是(編輯)彈窗，則需要把表單數據提交請求接口

我用一個圖來概括大概就是：

圖片

問題所在

我不知道其他公司怎么樣，但是就拿我自身來舉例子，公司的后端跟前端的命名規則是不同的

• 后端命名： 請求方法+字段類型+字段含義+下劃線命名(比如 in_name、os_user_id)
• 前端命名： 字段含義+駝峰命名(比如 name、userId)

回到剛剛的業務邏輯，還是那張圖，假如我們前端不去管命名的話，那么數據的傳輸是這樣的，發現了很多人都懶得去轉換后端返回的字段名，直接拿著后端的字段名去當做前端的表單字段名，但這是不符合前端規范的

圖片

理想應該是表單要用前端的命名，比如這樣

圖片

但是很多前端就是懶得去轉換，原因有多個：

• 開發者自身比較懶，或者沒有規范意識
• 回顯時要轉一次，提交時還要再轉一次，每次總是得寫一遍

解決方案

所以能不能寫一個工具，解放開發者的壓力又能達到期望的效果呢？比如我開發一個工具，然后像下面這樣在彈窗里用

• state： 響應式表單數據，可以用在彈窗表單中
• resetState： 重置表單
• inputState： 將表格行數據轉成表單數據
• outputState： 將表單數據轉成提交請求的數據

配置的含義如下：

• default： 表單字段默認值
• input： 轉入的字段名
• output： 轉出的字段名
• inputStrategy： 轉入的轉換策略，可以選擇內置的，也可以自定義策略函數
• outputStrategy： 轉出的轉換策略，可以選擇內置的，也可以自定義策略函數

圖片

轉入和轉出策略，內置了一些，你也可以自定義，內置的有如下

圖片

下面是自定義策略函數的例子，必須要在策略函數中返回一個轉換值

圖片

這樣的話，當我們執行對應的轉換函數之后，會得到我們想要的結果

圖片

use-dsp

所以我開發了一個工具

源碼地址：https://github.com/sanxin-lin/use-dsp

其實 dsp 意思就是

• data
• state
• parameter

npm i use-dsp
yarn i use-dsp
pnpm i use-dsp

import useDSP from 'use-dsp'

為啥不從一開始就轉？

有人會問，為啥不從一開始請求表格數據回來的時候，就把數據轉成前端的命名規范？

其實這個問題我也想過，但是設想一下，有一些表格如果只是單純做展示作用，那么就沒必要去轉字段名了，畢竟不涉及任何的數據傳遞。

但是需要編輯或者查看彈窗的表格，就涉及到了行數據的傳遞，那么就需要轉字段名