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要放在元件的內部 - 超過兩個地方可以用的東西，要抽象