Typescript算是最近比較流行的「語言」(強語言類型檢測),有利於編寫大型程序。strong typing貌似如今不少人比較承認。例如如今比較流行的Go以及新近的Kotlin。也是由於最近在使用antd而接觸到,Angular2用的可能比較多。
TypeScript是一種由微軟開發的自由和開源的編程語言。它是JavaScript的一個超集(ES6的超集),並且本質上向這個語言添加了可選的靜態類型和基於類的面向對象編程。
若是說只是簡單的認爲TS(Typescript之後用縮寫TS來表示)是ES6的超集更趨進於ES8這種理解,在我看來是不對的。(緣由後面再說 -。- 踩坑血淚史)。javascript
前端發展的必然趨勢前端
前端最近幾年成井噴式發展,mvc、mvvm、mvp各類框架層出不窮,可是就是這種井噴式的發展給前端注入了一些新的活力,前端將來的發展趨勢也是逐漸的趨於規範化,遙想當年java不也經歷過這麼一段「動盪」的時期麼。而javascript自己就是一個弱語言沒法和java這種強語言類型進行比較,可是一個強語言類型帶來的優點又是如此的鮮明--健壯、易維護...(幹嗎讓我寫這麼全~我又不是搞java的-。-)那麼問題來了怎麼才能圓jser的這麼一個夢想呢?Typescript!雖然我不能保證Typescript可以長久的活下去可是在我看來這個思路是對的!java
這裏就不詳細展開typescript的文檔了,舉個TS比較經常使用的例子。node
interface TableProps<T>{ prefixCls?: string; dropdownPrefixCls?: string; rowSelection?: TableRowSelection<T>; pagination?: PaginationProps | boolean; size?: 'default' | 'small'; dataSource?: T[]; columns?: ColumnProps<T>[]; rowKey?: string | ((record: T, index: number) => string); ... }
定義了一個TableProps接口規範--用來檢測當前使用props是否符合規範,能夠理解爲React中的propTypes類型校驗。其中還使用了<T>泛型。
若是想深刻研究TS的話,能夠直接訪問Typescript官網,這裏不作贅述。react
TS爲了兼容jsx專門實現了tsx的文件,能夠更方便的使用React。webpack
使用ES六、ES7語法es6
固然babel已經能夠解析ES六、ES7語法babel polyfill
,可是若是使用typescript的編譯tsx/ts的時候使用的ts-loader
或者awesome-typescript-loader
,必須將tsconfig.json
lib添加須要的解析的語法,不然TS會檢測出錯。web
{ "compilerOptions": { "moduleResolution": "node", "module": "commonjs", "target": "es6", "sourceMap": true, "allowSyntheticDefaultImports": true, "jsx": "react", "lib": [ "dom", "es2015.promise", "es5", "es2015.iterable", "es2015.generator", "es2015.symbol", "es7"] }, "exclude": [ "node_modules" ] }
這個並不算完,由於這裏設置target爲ES6--編譯後的js爲ES6。若是須要編譯成ES5那麼ts將不會把ES6中 Generator
和ES7語法中的async await
編譯成ES5。若是想將其編譯成ES5的話那麼就須要在loader中加入babel-loader。如:(使用webpack2語法)typescript
{ test: /src\\pages(\\.*).(tsx|ts)/, use: [ 'bundle-loader?lazy', 'babel-loader', 'ts-loader', ], },
同時typescript做者將在2.3 (May 2017) Generator support for ES3/ES5。npm
關於ts中全局變量/函數的定義及使用
使用場景:想在全部ts/tsx中引用一個輔助函數。(使用import太麻煩並且使用頻率很高)。
解決方案(不完整):
一、webpack(Resolve alias)
建立全局變量別名,編寫時直接引用,交給webpack解析。
二、發佈一個npm,同時建立d.ts文件用來聲明
@types/whatwg-fetch是使用的這種方案,編寫中能夠直接引用fetch,TS會檢測到對應聲明的d.ts文件,從而不會報錯。
三、掛在到window
例如:encodechar -> 全局
建立一個global.d.ts文件,在其中聲明declare const encodechar: string;
d.ts文件
這個算是一個小缺陷吧(這須要時間和積累),主流的框架或者插件是有@type的實現,可是不少小的框架是沒有對應TS版本的,致使了不少小玩意在ts中玩不了,若是想玩須要用一些黑科技(本身聲明一個d.ts版本....)舉一個例子:
若是想使用import { bindActionCreator } from ‘redux’;
在TS檢測是不經過的由於它沒有實現bindActionCreator
的聲明,因此一個黑暗的解決方案出現了,就是本身封裝了一個bindActionCreator
同時寫一個d.ts文件給TS進行識別。
說一下TS使用中的一些感受很差的地方吧(用的比較淺顯,純屬我的見解)。
一、d.ts文件要和js同樣不斷的進行同步迭代,不然會致使新加的接口報錯。
二、增長了學習的複雜度,對於沒有接觸過C#,JAVA...來講,也是須要一點時間來接受的。
三、相對於React來講有點重合(純屬我的見解),由於React中也有props的類型檢測,固然TS是一個全局的檢測,不是一個量級的。
四、國內沒有大範圍使用,若是踩坑十分痛苦。
五、另外再說一下antd
和tsx
結合使用稍微會比jsx痛苦一點。(有些d.ts文件沒有跟上迭代)例如:
antd V2.6.3
在Pagination.d.ts中
showTotal?: (total: number) => React.ReactNode;
沒有第二個參數,可是源碼中是有的。因此若是想使用只能人工添加TS纔不會報錯
showTotal?: (total: number, range?: [number,number]) => React.ReactNode;