本文共 8873 字,大约阅读时间需要 29 分钟。
我们公司在德国还有个团队. 我们这次要接他们的一个库. 其中的一个API要求我们传入参数, 这个API是这样定义的:
/* * * @param {Object} input The first object * @param {Object} options The second object * /function init(input, options){ ...} 复制代码
看到这样的代码, 我是崩溃的. 这个input是个Object类型, 很清楚, 可是Object在JavaScript世界里可是千变万化的, 这我到底要传一个什么样的值过去呢.
这其实就是最典型的例子, 一个"为什么我们需要使用TypeScript"的例子.
其实TS还有一些好处, 比如说类型很强大(因此也更难掌握啦), 支持一些现代语言的新特性(如泛型)... 这些我们在本文中就不赘述了. 我其实更想讲解一下在使用TypeScript开发React/ReactNative(下方简称R/RN)时的一些坑与注意点, 帮助你更平滑地过渡到TypeScript的世界里来.
JS世界里我们使用PropTypes
来定义类型, 但它不是很精确, 如PropTypes.object
就不能精确到这个object需要什么成员, 这样你一不小心传少了值, 就会有NPE错误.
TS中对props, state都可以进行限制 - 这适用于类组件与函数组件.
interface IProps { name: string;}interface IState { offset: number;}class SomeScreen extends React.Component{ state = { offset: 0 }; constructor(props: IProps) { super(props); console.log(props.name); }}复制代码
这里就限定了Props与state的精确类型了. 你不可能再传错或少传props了
interface IProps { name: string;}const SomeScreen = (props: IProps) => { const [offset, setOffset] = useState(0); console.log(props.name);};复制代码
这时其实就是我们child view可能有一个, 也可能有多个, 这个可能要根据数据来定的. 比如你给我一个array, 有几个item我就显示几个view.
这时这些灵活的子View就可以被定义为JSX.Element
类型.
render() { const children : JSX.Element[] = this.props.data.map((item, index) => { return ; }); return ({children} ); }复制代码
当然, 这些灵活的子View自然是要有个key了, 不然你会有一个yelloe box来警告你了.
这个就要区分了. 类组件与函数组件写法还不一样.
// 函数组件interface IProps { id: number; text?: string;}const MyView = (props: IProps) => { return ( <>.... );};MyView.defaultProps = { text: "default"};复制代码
= = = = = = = = = =
// 类组件class MyScreen extends Component{ static defaultProps = { text: "default" };复制代码
其实这里有个小坑. 就是你的defaultProps设定其实可以乱加乱写属性, 可以完全不按IProps来. 这个TS是没法限定的. 网上有专门解决这些问题的文章, 但在我看来都过于复杂, 反而不如这些写来得好看. 好在IProps能扛住大多数的检查, 我们使用也是使用IProps, 而不直接使用defaultProps.
5.1 React
React中使用ref其实也有多种方式的, 比如说下面两种:
// React (Approach 1)const MyView = () => { let viewRef : HTMLDivElement | null; return (viewRef = v} /> );};复制代码
// React (Approach 2)const MyView = () => { const viewRef = createRef(); return ( );};复制代码
5.2 React Native
在ref这一块, React Native异于React的就是类型了, 它不再是HTML****Element
了.
const MyView = ()=>{ let ref: View|null = null ; let imageRef = createRef(); return ()}复制代码
当然, 我们要注意, 涉及到函数组件, 使用ref是要小心些的. 详细可见.
HoC说是高阶组件, 但它其实就是个函数.只不过入参与返回值都是组件而已. HoC也是一种组合多种组件的一种方式, 用得好了那重复代码大量减少, 逻辑分工明确.
当然用得差了, 那就是HoC Hell, 比如说:
(图片来源: )
不过在本文中我们还是紧贴TS来讲解. 使用TS来做HoC, 问题主要还是在类型上. 你传进来的组件与返回的新组件, 其类型是什么.
一个给入参组件添加一个Loading效果的HoC, 可以这样写:
interface IProps { loading: boolean;}const withLoader =(InputComponent: React.ComponentType
): React.FC
=> { props.loading ? (... ) : (...) ...;复制代码
注意, 这里使用的是React.ComponentType
, 这个类型的定义其实就是type ComponentTYpe<P = {}> = ComponentClass<P> | FunctionComponent<P>;
, 即函数组件或类组件都行.
另外, 也注意下Props的声明. 我们的入参因为可以是任意组件, 所以Props不要写死了, 也就是要用泛型. 至于我们的HoC要是有什么自己的需求, 那就可以用 P & IProps
来组合.
p.s. 这个A & B
, A | B
正是TypeScript的强大之处. 它的类型组件很容易. 这要是换成java, 肯定得再定义一个新类型叫C, 然后C中赋值A与B的所有属性 -- 这就有了重复代码了.
乍一听, 这好像不算是什么麻烦事. 但在TS中, 你要是没有定义type, 那就是寸步难行. 所以我们得知道一些常见库, 还有React中的常用属性到底是什么类型. 举个例子, react-navigation与redux中那几个dispatch, navigation
都是些什么类型啊?
下面就是我写的一个成功的例子:
interface IViewProps { // ... your own props}type IProps = IViewProps & ViewProps & NavigationScreenProps & ReturnType& ReturnType class MyScreen extends React.Component { // ....}复制代码
其中:
ViewProps
就包含了style
, children
, onLayout
, testID
这些属性. 注意这是个react-native类NavigationScreenProps
: 它来自于react-navigation
库, 具有navigation
, screenProps
, navigationOptions
等属性ReturnType<xxx>
则是对应了redux生成的props. 这一个我们后面一章节会讲到Redux, 这个大名鼎鼎的状态容器自然不用详细介绍了. 不过使用TypeScript版本的Redux还是有些地方要注意的.
Redux中有一个AnyAction
的类型的, 表示任意Action都行. -- 当然也这要遵循
而一般在一个模块中, 我们都是说某一个模块是只处理特定一些action的. 如audioPlayer模块就只处理audio play相关的action. 这时我们可以这样:
export interface IAddAction{ type: "Add"}export interface IRemoveAction{ type: "Remove", paylaod: { id: number }}export type MyAction = IAddAction | IRemoveAction复制代码
我们可以组合不同的action, 变成一个总的Action. 这样后面的reducer()中就可以使用这个总Action. -- 否则的话, 使用范围更广的AnyAction
就定位不准, 容易出错了
这里的state一定要加个类型. redux因为其是Single Source的缘故, 一般它存储的state都不小. 特别是我们有很多个reducer还要一一combine组合之后, 整个应用的全局state就十分大并有层次了. 要是没有一个明确的类型说明, 半年或一两年之后, 整个state就很乱, 不知道哪是哪了. 写过大型项目的同学肯定心有体会了.
export interface IProduct { id: string; name: string; category: IProductCategory; sku: Sku;}export interface MyState { readonly products: IProduct | null;}复制代码
有了上面的state与action的定义, 现在我们的reducer就空前地清晰起来了. 在reducer里面使用state.某field
也会有提示是否正确的, 减少了typo的笔误可能性.
export const MyReducer : Reducer= ( state = new MyState(), action: MyAction) => { switch(action.type){ ... } return state;}复制代码
这里store就麻烦些了, 不过也更清晰了. 麻烦还是主要麻烦在整个应用中的各个reducer可以以不同层次地组合起来. -- 这也将影响我们的state的布局.
下面就讲一个最简单的例子, 就是只有一层combineReducer()的.
export interface IAppState { products: MyState, books: AnotherState}const rootReducer = combineReducer({ products: MyReducer, books: ANotherReducer})export const store = createStore(rootReducer, undefined, applyMiddleware(...));复制代码
你要是说你的reducer层次很复杂, 比如说像这样:
const RootReducer = combineReducer({ oneReducer, combineReducer( twoReducer, combineReducer(fourReducer, fiveReducer)), })复制代码
然后要依样画葫芦地写state的层次, 是蛮累的. 所以你还可以这样来减少你的工作量:
export type IAppState = ReturnType复制代码
我在项目是使用Redux-Saga
来做异步的. 不过你要是想用Thunx
也容易, 就这样:
export const fetches = async (): Promise=> { await wait(1000); return products;}复制代码
前面讲过, 我们有一个built-in的AnyAction类型, 它的源码其实就是:
export interface AnyAction extends Action { // Allows any extra properties to be defined in an action. [extraProps: string]: any}复制代码
备注: 在TS中, [extraProps: string]: any
中有前半截就是指任意key名字(只要其类型是string就行), 至于value是any类型就行.
这个AnyAction
还是少用, 这就像any要少用一样.
若你在项目中使用了Redux-Persist库, 那上面的IAppState
的定义就有问题了. 因为Redux-Persist会在我们的appState里再加一个自己的定义, 所以TS会检测到类型不匹配而报错.
举个栗子来说吧: 我们现在要存一个state是这样的: {book: {id: 22, name: "Harry" } }
但一旦使用了Redux-Persist, 那state就变成了: {book: {id: 22, name: "Harray", _persist: {....} } }
所以这时我们需要这样改:
interface IAppState { // book: IBookState // ERROR!!! book: IBookState & PersistPartial; }复制代码
这个其实在上面讲过了, 就是使用ReturnType来做到灵活配置.
type IProps = ReturnType& ReturnType & ViewProps复制代码
我看到很多书或网页上都是这样定义中间件的:const middleware = store => next => action => {...}
. 但其实现在的store真的不是指Redux中的那个store了. 其类型是一个新定义的类型: MiddlewareApi
.
看下它的源码: type MiddlewareAPI = {dispatch: Dispatch, getState: ()=> State}
哈哈, 好吧, 其实和store真的好像.
那我们要如何用TypeScript来定义一个中间件呢? -- 其中的麻烦还是你不知道一些函数入参的类型. 下面这个小片段就是一个成功的例子:
const myMiddleware = (store: MiddlewareAPI) => (next: Dispatch) => (action: AnyAction) => { ... ...}复制代码
注意: 我们在Dispatch中都使用了泛型, 不然编译通不过. 这里其实也是一个你可能会使用AnyAction的地方. 因为你确实不知道会有什么样的action会过来.
先说结论哦, 使用TypeScript来写测试会比较麻烦. 因为TS会检测各种类型, 这样一些Mock的手段会过于hacky而被TS报错, 说类型不匹配.
下面的例子就是我们使用jest.mock()
来注入一些mock方法到Worker
类中. 但TS会不知道Workder
还有mockReturnThis()
方法而报错.
import { work } from "../Worker"jest.mock("../Worker")test("some...", ()=>{ work.mockReturnThis(); // ERROR!!!, as TypeScript does not know this method exist ...})复制代码
结果为了让其能运行, 你不得不加一个@ts-ignore:
// @ts-ignore work.mockReturnThis()复制代码
但加了@ts-ignore, 总是让人不舒服的. 所以我个人推荐, 测试还是用js文件吧.
TypeScript虽然强大, 也不是尽善尽美. 比如Kotlin中很好用的lateinit var
, 在TS中就没有. TS像KotLin一样, 一开始声明const对象就得给值.
不过我们其实可以走点偏锋.
interface People { id: number, name: string}...// const p = {} // ERROR! `{}` and `People` are not compatilbeconst p = {} as People// when time is ripep.id = 100复制代码
上面的as People
, 指明了类型, 还不用所有属性都赋值, 是方便了. 但也请不要滥用哦, TS的static check正是我们要用它的地方. 像用了上面的这样技巧的地方, 我们最好都是要code review下的.
备注: 要是使用any那就更不可取了. any基本上TS世界的一个大毒瘤, 不是万不得已不应该使用, 伤人更伤己啊. 以后我可能会专门就这个any, 来讲一下如何避免使用any
泛型是个强大的工具, 用过java或swift的同学都有所了解. 对于js的同学可能比较新, 但也建议去学习一下.
同样, 在TS中使用泛型要注意. 比如说下面的写法就报错了:
你去比照下TS官网上的泛型写法,一点都不带差的. 那怎么还报错啊?
哈哈,这就是个坑了. 注意, 上面出错的代码是在一个.tsx
文件里的.
.tsx
文件看到<>
时, 首先反应就是, "这是个React的element", 于是想去加载组件.
所以说:
.ts
文件中, 上面的代码不会报错..tsx
文件中, 上面的代码会报错. 要想修复, 就得告诉TS编译器, "这是个泛型, 不是组件"具体方法就是:
// ***.tsxconst example =(url: T) : number => { return 20;};复制代码
好了, TypeScript的一些进阶技术就介绍完了. 主要还是一些不熟悉的三方库的类型, 和不熟悉的TS的用法 (和java/swift这些语言比起来, 差异性还是有些的). 以后我若有了更多技巧, 再介绍给大家. 多谢大家捧场~
作者:snwrking 链接:https://juejin.im/post/5dcb1848f265da4d40713340 来源:掘金 著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。