Typescript配合React實踐
使用ts寫React程式碼寫了將近三個月,從剛開始覺得特別垃圾到現在覺得沒有ts不行的一些實踐以及思考。 如果按部就班的寫React就體會不到使用ts的樂趣,如果多對程式碼進行優化,進行重構,在業務中實踐比較好的一些方案就會體會到ts真正的樂趣,但是ts也在過程中給我帶來了痛苦,在本文的最後會具體展開一下。
使用ts的心態變化
剛開始覺得ts好垃圾,覺得React的PropType
和PropDefault
幾乎能做ts的靜態型別檢查能做到的事情,甚至做的還能比ts做的多。比如說對於元件間設定預設值,ts對於支援的就是不太好。
後來由於一個需求我改變了一點我的想法,當時的想法就是:“你還別說,這個ts還有點用”。這個場景分為兩種情況:
-
父元件傳遞子元件的引數名要發生變化,按照以前都是要通過
commamd(ctrl) + f
的方式去全域性搜尋並且修改,但是這樣還是如果對於量大話就很不友好(我遇到的就是量大的情況),如果統一替換的話,比如說這個變數叫做user,就有很大概率會包含其他的變數,這樣統一替換就會很尷尬。但是ts的靜態型別檢查就幫你解決了這個問題,對於每一個父元件沒有傳遞的值來說,都會提示錯誤。而且ts的報錯是在編譯時,不是在執行時 。 - 但是如果傳遞的引數名不變,引數值變了的話,ts的靜態型別也會幫你檢查出來,然後開發人員再去做修改。說了這些比較抽象,上個示例程式碼比較清晰:
// 父元件 render(): ReactNode { const { user, loading, namespaceList, yarnList, workspace } = this.state; return ( <UserDetail user={user} loading={loading} namespaceList={namespaceList} yarnList={yarnList} workspace={workspace} onLoadWorkspace={(params: IParams) => this.onLoadWorkspace(params)} onUpdateUser={(field: string, data: IUserBaseInfo) => this.handleUpdateUser(field, data)} onToCreateAk={(userId: number) => this.handleToCreateAk(userId)} onDelete={(ids: number[]) => this.handleDelete(ids)} onUpdateResource={(userId: number, data: IResources) => this.onUpdateResource(userId, data)} onAkDelete={(ak: IPermanentKey) => this.handleDeleteAk(ak)} onChangeAkStatus={(ak: IPermanentKey, status: string) => this.onChangeAkStatus(ak, status)} /> ); } 複製程式碼
只要注意第一個引數就可以了,這個是實際的業務場景,下面是子元件:
export interface IProps { user: IUser | null; loading: boolean; namespaceList: { namespace: string }[]; yarnList: IYarn[]; workspace: { list: IWorkspace[] | null, total: number, } | null; onLoadWorkspace: (params: IParams) => void; onUpdateUser: (field: string, data: IUserBaseInfo) => void; onToCreateAk: (userId: number) => void; onDelete: (ids: number[]) => void; onUpdateResource: (userId: number, data: IResources) => void; onAkDelete: (ak: IPermanentKey) => void; onChangeAkStatus: (ak: IPermanentKey, status: string) => void; } class UserDetail extends Form<IProps, {}> { 複製程式碼
看,如果這樣寫的話,就能覆蓋住上面的兩種情況了。
當我硬著頭皮準備去修改同事上千行的React程式碼時候,我剛開始猶豫了好長時間,怕趕在上線發版之前搞不完之類的,後來實踐的時候發現意淫的有點多了,有了ts不用關心這麼多了呀。大致為父元件給子元件傳遞的值和回撥定義好就ok了。這麼說可能有點寬泛,好像自己寫一個元件也是這樣的,哈哈。後面會具體的提到怎麼使用ts重構的。這個時候對於ts的心態就是:“這個東西是真的厲害”。
經歷了幾次重構自己和重構其他人程式碼的時候,我現在對於ts的心態就是:“我可能以後的前端生涯離不開這玩意兒了”。
專案架構
因為在網上能搜到的ts+react
的專案還是比較少,真實的實踐也是比較少,都是一些從頭開始配置專案的。檔案的目錄結構怎麼做比較好還是沒有具體的實踐方案。當然,這種方案還是要根據具體的業務來分析的。在上一篇文章ofollow,noindex">編寫不用redux的React程式碼
中說明我當前遇到的業務場景。
最終決定把所有的interface 都放在公用的schemas目錄 然後在具體的業務中進行具體引用。 具體的common的目錄結構如下(schems目錄下面就儲存著所有的介面資訊):
common ├── component │├── delete-workspace-modal ││├── delete-workspace-modal.less ││├── delete-workspace-modal.less.d.ts ││└── index.tsx │└── step-complete │├── index.tsx │├── step-complete.less │└── step-complete.less.d.ts ├── css │└── global.less ├── hoc │├── workspace-detail.tsx │└── workspace-list.tsx ├── schemas │├── dialog.ts │├── k8s.ts │├── ldap.ts │├── message.ts │├── params.ts │├── password.ts │├── section.ts │├── table.ts │├── user.ts │├── workspace.ts │└── yarn.ts └── util ├── field-value.ts ├── format-datetime.ts ├── genURL.ts ├── getNamespaceList.ts ├── getYarnList.ts └── validation.ts 複製程式碼
在schems目錄下面的檔案就類似於通用的靜態型別,和業務相關但並不是和某個模組進行強繫結,這是因為在每個模組之間難免會遇到一些交叉。下面是某個具體模組的靜態型別:
export interface IYarnResource { id: number; namespace: string; user: string; queue: string; } export interface IYarnStatus { name: string; error: string; maxCapacity: number; state: string; used: number; capacity: number; } export interface IYarnEntity extends IYarnResource { status: IYarnStatus; keytab: string; } 複製程式碼
和模組強耦合的靜態型別比如說props 和state 的靜態型別,都會放在絕體的業務檔案中,就比如說下面的這個程式碼(簡化後):
import React, { PureComponent, ReactNode, Fragment } from 'react'; import { IComplex } from 'common/schemas/password'; export interface IProps { onClose(): void; onOK(data: IComplex): void; complex: IComplex | null; } export interface IState extends IComplex { } class PasswordComplex extends PureComponent<IProps, IState> { state: IState = { leastLength: 6, needCapitalLetter: false, needLowercaseLetter: false, needNumber: false, needSpecialCharacter: false, }; } 複製程式碼
所有的業務靜態型別一般都是不可複用的,一般是通用靜態型別以及某些特殊的靜態型別組合而成的。
state的初始化不一定要放在constructor
裡面,但是一定要給state指定型別,具體的原因見:Typescript in React: State will not be placed in the constructor will cause an error
具體靜態型別實踐
如果我們安裝了@types/react
,在react目錄下的index.d.ts
會有react的所有靜態型別定義。
具體元件架構
現在比如寫一個模組叫使用者管理,裡面包含檢視使用者詳情
,檢視使用者列表
,新建使用者
等功能。這也就對應這三個路由/users/:id
,/users
,/users/create
。這也就對應著三個有狀態元件分別為:user-detail-wrapper
,user-list-wrapper
,user-form-wrappper
。有狀態元件裡面只是請求或者獲取資料之類的。展示是通過component
下面的無狀態元件。可以看看下面的目錄結構:
user ├── component │├── password-complex ││├── index.tsx ││├── password-complex.less ││└── password-complex.less.d.ts │├── user-detail ││├── index.tsx ││├── user-detail.less ││└── user-detail.less.d.ts │├── user-detail-ak ││├── index.tsx ││├── user-detail-ak.less ││└── user-detail-ak.less.d.ts │├── user-detail-base-info ││├── index.tsx ││├── user-detail-base-info.less ││└── user-detail-base-info.less.d.ts │├── user-detail-resource ││├── index.tsx ││├── user-detail-resource.less ││└── user-detail-resource.less.d.ts │├── user-detail-workspace ││└── index.tsx │├── user-form-dialog ││├── index.tsx ││├── user-form-dialog.less ││└── user-form-dialog.less.d.ts │└── user-list │├── index.tsx │├── user-list.less │└── user-list.less.d.ts ├── user-form-wrapper │└── index.tsx ├── user-detail-wrapper │└── index.tsx └── user-list-wrapper └── index.tsx 複製程式碼
有狀態元件
設定只讀的state
看過網上的好多實踐,為了防止state
的不可篡改,都會把state
通過下面的方式設定為只是可讀的,這種方式雖然好,但是在我的專案中不會出現,這種錯誤只有React接觸的新人或者以前寫Vue的人會犯的,我的專案中一共兩個人,不會出現在這種問題。
const defaultState = { name: string; } type IState = Readonly<typeof defaultState> class User extends Component<{}, IState> { readonly state: IState = defaultState; } 複製程式碼
但是上面這種方式只是適合型別為typescript的基本型別,但是如果有自己定義的複雜型別,比如說下面這種:
interface IUser { name: string; id: number: age: number; ... } interface IState { list: IUser[]; total: number; } // default state const userList: IUser = [] const defaultState = { list: userList, total: 0, } 複製程式碼
上面這種就不能通過一個單純的空陣列就推斷出list的型別是IUser的陣列型別,所以要新增無謂一個userList
定義。
無狀態元件
無狀態元件也被稱為展示元件,如果一個展示元件沒有內部的state可以被寫為純函式元件。
如果寫的是函式元件,在@types/react
中定義了一個型別type SFC<P = {}> = StatelessComponent<P>;
。我們寫函式元件的時候,能指定我們的元件為SFC
或者StatelessComponent
。這個裡面已經預定義了children
等,所以我們每次就不用指定型別children的型別了。
下面是一個無狀態元件的例子:
import React, { ReactNode, SFC } from 'react'; import style from './step-complete.less'; export interface IProps{ title: string | ReactNode; description: string | ReactNode; } const StepComplete:SFC<IProps> = ({ title, description, children }) => { return ( <div className={style.complete}> <div className={style.completeTitle}> {title} </div> <div className={style.completeSubTitle}> {description} </div> <div> {children} </div> </div> ); }; export default StepComplete; 複製程式碼
泛型元件
先看一個元件,這個元件就是展示一個列表。
import React, { Fragment, PureComponent } from 'react'; export interface IProps<T> { total: number; list: IYarn[]; title: string; cols: IColumn[]; } class YarnListextends PureComponent<IProps> { } 複製程式碼
當我們想通用這個元件的時候,但是就是列表的欄位不一樣,也就是列表對應的不同的型別。這個時候我們可是使用泛型,把型別傳遞進來(也可以說是通過typescript的型別推斷來推斷出來)。來看下面的具體實現:
export interface IProps<T> { total: number; list: T[]; title: string; cols: IColumn[]; } class ResourceList<T> extends PureComponent<IProps<T>> { // 我們現在業務的場景會把這個list傳遞給table,table不同的欄位通過外部的父元件傳遞進來。 tableProps(): ITable<T> { const columns: IColumn[] = [ ...this.props.cols, { title: '操作', key: 'operation', render: (record: T) => this.renderOperation(record) }, ]; return { columns, data: this.props.list, selectable: false, enabaleDefaultOperationCol: false, searchEmptyText: '沒有搜尋到符合條件的資源', emptyText: '尚未新增資源', }; } } 複製程式碼
設定預設值
如果使用的typescript是3.x的版本的話,就不用擔心這個問題,就直接在jsx中使用defaultProps
就可以了。
如果使用的是2.x的版本就要如果定義一個類似下面這樣一個可選的值:
interface IProps { name?: string; } 複製程式碼
我們如果在class裡面設定defaultProps的話,ts是不認識的。還是要在程式碼裡面進行非空判斷。對用這好昂方法可以寫一個高階元件。高階元件來源
export const withDefaultProps = < P extends object, DP extends Partial<P> = Partial<P> >( defaultProps: DP, Cmp: ComponentType<P>, ) => { // 提取出必須的屬性 type RequiredProps = Omit<P, keyof DP>; // 重新建立我們的屬性定義,通過一個相交型別,將所有的原始屬性標記成可選的,必選的屬性標記成可選的 type Props = Partial<DP> & Required<RequiredProps>; Cmp.defaultProps = defaultProps; // 返回重新的定義的屬性型別元件,通過將原始元件的型別檢查關閉,然後再設定正確的屬性型別 return (Cmp as ComponentType<any>) as ComponentType<Props>; }; 複製程式碼
Typescript不好的地方
就型別定義起來有點費勁,有的時候廢了大半天的力氣發現都是在整ts型別的問題。 然後。。。應該沒有了。
前端開發規範
這裡就主要介紹在書寫元件的時候的個人開發規範:
-
欄位內容要儘量到末尾再去解釋。
- 例: 一個元件要給一個子(子...)傳遞一個物件引數,但是現在可以想象到的這個元件只用name欄位,為了可擴充套件,不要只是給這個子(子...)只是傳遞name屬性,要把整個物件傳遞過去。
- 例:一個無狀態元件能修改使用者的姓名,當點選確定按鈕進行修改的時候,不要只是把修改後的姓名傳遞回去,要把整個都傳遞回去。
-
有狀態元件只是處理響應和請求邏輯,不處理任何展示資訊。也就是說有狀態元件中的
render
函式中只是給子元件傳遞資訊 - 無狀態元件可以儲存一些state的資訊,比如說一個彈窗的展示和隱藏。
- 一個元件不能超過300行程式碼
- 兩行鎖進(不同的編譯器使用.editorconfig)
-
通用的
interface
放在common 下面的schemas 下面 -
非通用的
interface
比如說IProps
或者IState
要放在元件的內部 - 超過兩個地方可以用的東西,要抽象