我已經(jīng)用靜態(tài)類型語(yǔ)言編碼多年了，我從匯編開始，然后轉(zhuǎn)到C語(yǔ)言，經(jīng)過(guò)Visual Basic和C#，但是當(dāng)我轉(zhuǎn)到JavaScript時(shí)，我對(duì)軟件的所有理解都改變了。

在給出我現(xiàn)在的工具鏈之前，有一個(gè)建議：自己練習(xí)自己想掌握的語(yǔ)言，不受任何強(qiáng)加的限制，在這之后，找一份符合自己喜好的工作，否則，你可能最后會(huì)覺得很痛苦，因?yàn)槟銜?huì)用錯(cuò)了自己的工具，從而永遠(yuǎn)無(wú)法發(fā)揮出自己的潛力。

[[326577]]

1. TypeScript

主頁(yè)上的介紹：

是什么讓我在每個(gè)項(xiàng)目中都使用TypeScript?

(1) 編譯錯(cuò)誤

在編譯時(shí)發(fā)現(xiàn)錯(cuò)誤是一件好事，愚蠢的錯(cuò)誤，莫名其妙的運(yùn)行時(shí)錯(cuò)誤，顯示得太遲的錯(cuò)誤的無(wú)奈使我對(duì)這個(gè)職業(yè)的熱愛減少了，但是TypeScript再次帶來(lái)了歡樂(lè)。

(2) 類型

表現(xiàn)力和依從性，意圖和一致性，設(shè)計(jì)和力量，類型需要時(shí)間來(lái)掌握，但是，孩子們，他們是值得的。Every、Single、Time，我太想念那些類型了。TypeScript既兼容面向?qū)ο箢愋停布嫒莺瘮?shù)類型，非常棒。

當(dāng)你有類型的時(shí)候，你會(huì)省去很多時(shí)間給試圖理解和使用你的代碼的人，你會(huì)變得能夠在不看手冊(cè)的情況下發(fā)現(xiàn)整個(gè)庫(kù)的使用方法，而且由于類型的約束，你可以確定事情會(huì)被按他們應(yīng)該使用的那樣使用。

TypeScript中的類型還有很長(zhǎng)的路要走，但是今天的類型系統(tǒng)已經(jīng)為前端帶來(lái)了很多強(qiáng)大的功能。沒有類型系統(tǒng)的感覺就像試圖用腳跑過(guò)賽車一樣。它給人一種工程化的感覺，這是JavaScript所缺少的，我用類型來(lái)設(shè)計(jì)和強(qiáng)制執(zhí)行正確的接口使用，而我每花一個(gè)小時(shí)寫類型的時(shí)間就能讓我安全地度過(guò)幾天(好吧，這主要是我的看法)。

(3) 減輕我的挫敗感

有了TypeScript，我每小時(shí)的錯(cuò)誤以及因此而感到沮喪的機(jī)會(huì)大大減少了，僅此部分就值得了。

TypeScript也越來(lái)越好，它迅速采用了新的ECMAScript功能。

所以，我放棄了用普通的JavaScript進(jìn)行編碼，TypeScript有JavaScript的所有優(yōu)點(diǎn)。

2. Visual Studio Code

這不是一個(gè)IDE，而是一個(gè)文本編輯器，最好的前端文本編輯器，來(lái)自他們的首頁(yè)的介紹：

為什么選擇VSCode?

(1) 到處運(yùn)行，無(wú)處不在

這句話是對(duì)的，我已經(jīng)在需要使用的每個(gè)操作系統(tǒng)上可靠地使用了VSCode，它速度很快，并且在所有地方都有很多優(yōu)點(diǎn)，無(wú)需擔(dān)心平臺(tái)支持。

(2) IntelliSense

它在JavaScript中的效果非常好，但在TypeScript中，它就像神一樣，快速，可靠，并且在編譯之前就能發(fā)現(xiàn)錯(cuò)誤!我認(rèn)為這是VSCode最好的功能之一。我認(rèn)為這是VSCode最好的功能之一，它就像多了一雙眼睛。

(3) 減輕我的挫敗感

當(dāng)年Sublime的每一個(gè)插件都很慢，而且缺乏IntelliSense，VSCode的速度很快，而且越發(fā)布越快，說(shuō)實(shí)話，我很驚訝這么好的軟件竟然是免費(fèi)的。

一切都按預(yù)期運(yùn)行，它有我能想到的所有功能，那些不應(yīng)該是核心的，都是擴(kuò)展，說(shuō)實(shí)話，掌握它是值得的。

最后，用一句話來(lái)形容我的VSCode代碼體驗(yàn)：我沒有任何怨言。

3. React

他們的主頁(yè)的介紹：

如前所述，我開始使用AngularJS，全功能強(qiáng)大的前端框架，但轉(zhuǎn)到React對(duì)我來(lái)說(shuō)是不可避免的，下面是原因。

(1) 不是框架

沒錯(cuò)，這不是框架，而這是我最喜歡的事情之一，我通常編寫小型程序，不需要大量的框架，只需要一點(diǎn)幫助我就可以構(gòu)建小型UI。

(2) 擁抱函數(shù)式編程

最好的賣點(diǎn)是，React接受了函數(shù)式編程，與我對(duì)JavaScript的新認(rèn)識(shí)保持一致。

React在簡(jiǎn)潔方面做了很大的努力，我很欣賞這一點(diǎn);React用最小的語(yǔ)法表達(dá)了復(fù)雜的概念，像 useState 和高階組件這樣的東西就是一個(gè)例子，說(shuō)明了擁有正確的抽象比擁有一堆可能最終會(huì)用錯(cuò)的工具要好得多。

(3) 全部加起來(lái)+TypeScript

我不使用Svelte或Vue的原因是我不喜歡模板，而我喜歡類型。在模板文件中，你沒有TypeScript，也沒有JavaScript，你有模板腳本，一些特殊的標(biāo)記，可以幫助你做一些事情，無(wú)類型的，用不同的推理。

我確實(shí)喜歡React的整體特性。也就是說(shuō)，我用JSS代替了CSS，而不是HTML+JS，我用TSX，所有的CSS、HTML、JS都在一個(gè)文件中的TypeScript中，我喜歡它，所有的東西都有IntelliSense，編譯錯(cuò)誤，類型，沒有上下文切換。

在我看來(lái)，小的組件是CSS+HTML+JS的混合體，將它們?nèi)亢喜⒌絋ypeScript中，對(duì)我來(lái)說(shuō)是有利的。

它更優(yōu)秀的一面是?它的性能很好，而且每一個(gè)新版本都在不斷地改進(jìn)，更多的JSS被移植到靜態(tài)CSS中，更多的TSX被優(yōu)化，等等，所以你可以用它來(lái)編程，隨著時(shí)間的推移，移植器的輸出也會(huì)越來(lái)越好。

在我工作過(guò)的公司里，我們?cè)谛〉某绦蛑芯幊龈邔哟蔚母拍睿皇堑蛯哟蔚臇|西，我相信公司在大多數(shù)時(shí)候并不是花錢給程序員優(yōu)化什么，他們要的是可用的、可靠的、快速的軟件。

4. Ramda

Ramda是一款實(shí)用的 JavaScript 函數(shù)式編程庫(kù)。

(1) 代碼可重用性

我在上面抱怨過(guò)重復(fù)的代碼，大部分的代碼都是一些小的實(shí)用程序函數(shù)，當(dāng)我成功地?fù)碛辛艘粋€(gè)文件夾，如果我開始了另一個(gè)項(xiàng)目，我必須重新編寫它們，所以我一直在尋找一個(gè)好的實(shí)用程序庫(kù)。

現(xiàn)在，我在抽象函數(shù)的時(shí)候，幾乎沒有想到要讓函數(shù)變得更可重用，因?yàn)樗械耐ㄓ每芍赜煤瘮?shù)都在Ramda中，有一個(gè)非常強(qiáng)大的函數(shù)優(yōu)先的接口。

(2) 純函數(shù)，無(wú)副作用且不變

一個(gè)實(shí)用程序應(yīng)該包含純粹的函數(shù)，這意味著這些函數(shù)需要：無(wú)副作用，并將數(shù)據(jù)視為不可變的。這些東西與實(shí)用程序庫(kù)不一致，哎呀，甚至在JavaScript內(nèi)置Array函數(shù)中也不一致，不相信我嗎?看這個(gè)：

 

原生數(shù)組的sort方法改變了原始數(shù)據(jù)，而 Ramda的sort方法不會(huì)。

(3) 轉(zhuǎn)換器(Transducers)/

實(shí)事求是地描述轉(zhuǎn)換器：轉(zhuǎn)換器消除了組合多個(gè)數(shù)組函數(shù)的性能損失。

我認(rèn)為圖像勝于文字，轉(zhuǎn)換器難以理解：

Ramda充滿了轉(zhuǎn)換器函數(shù)，這意味著性能非常好，您可以堆疊多個(gè) filter，map 和21個(gè)其他功能，它將僅迭代數(shù)組并應(yīng)用一次功能，而不是N次。

(4) 缺點(diǎn)

Ramda很棒，但是所有的好東西都是有代價(jià)的……如果你正在考慮使用TypeScript。

Ramda的類型、類型推理和類型解析的復(fù)雜度是非常高的;;除此之外，主要的貢獻(xiàn)者對(duì)TypeScript根本不感興趣。

他們似乎是一群了不起的開發(fā)人員，他們?cè)跊]有TypeScript的情況下就馴服了JavaScript，并且對(duì)將這個(gè)令人驚嘆的庫(kù)移植到TypeScript的興趣為零。

盡管如此，Ramda仍然是我樂(lè)于使用的最精良的實(shí)用程序庫(kù)之一，在我馴服JavaScript的過(guò)程中，它讓我非常感動(dòng)。

5. FP-TS

雖然Ramda是一個(gè)很好的解決方案，只要我們停留在JavaScript領(lǐng)域，一旦我完全采用了TypeScript，它就會(huì)變得...........使用起來(lái)很尷尬，類型推理也不是很好，所以我尋找了其他考慮到TypeScript的解決方案，或者說(shuō)最好是用TypeScript寫的。

幸運(yùn)的是，我從他們的主頁(yè)上找到了fp-ts，這是庫(kù)的奇跡，他們的主頁(yè)：

• TypeScript中的類型化函數(shù)式編程。
• fp-ts為開發(fā)者提供了TypeScript中的類型化函數(shù)式語(yǔ)言中的流行模式和可靠的抽象。

老實(shí)說(shuō)，fp-ts是一個(gè)杰作，它為TypeScript帶來(lái)了很多好處，并且以一種不引人注目的方式，它的類型也是完全慣用語(yǔ)的。

為什么我在100%的項(xiàng)目中使用fp-ts?

(1) 管道(Pipe)

我故意避免談?wù)揜amda的管道，因?yàn)轭愋头治鰪淖蟮接业男再|(zhì)，fp-ts版本更……是TypeScript和IntelliSense的慣用語(yǔ)。

這是沒有管道的代碼：

在 main 中，我需要使用中間變量來(lái)分配中間結(jié)果，在 main2 中，要從右到左讀取執(zhí)行順序是很尷尬的。

有了管道，我們不需要中間變量，所有的數(shù)據(jù)都是流動(dòng)的，但是，TypeScript在使用Ramda的管道時(shí)，大多數(shù)時(shí)候會(huì)產(chǎn)生錯(cuò)誤，因?yàn)檩斎胫捣旁谧詈螅圆荒芡茢喑鍪裁词禽斎氲牡谝粋€(gè)函數(shù)，以此類推，因?yàn)門ypeScript從左到右推斷。而Ramda的管道要起作用，推理應(yīng)該從左到右和從右到左，Ramda的管道類似于Haskell、OCalm和F#等函數(shù)式語(yǔ)言的類型推理系統(tǒng)中的常見特征，但在TypeScript中卻沒有，雖然在JavaScript中完全不是問(wèn)題。

現(xiàn)在看一下fp-ts版本的管道：

不同的是，fp-ts 將pipe的輸入放在第一位，讓TypeScript的推理變得很開心。在JavaScript領(lǐng)域，Ramdas的方法是100%有效的慣用代碼，但TypeScript缺乏從右到左的推理，使得它 "無(wú)效 "或者說(shuō)一般情況下很難使用，所以我一般傾向于使用fp-ts版本的pipe，而不是Ramda的。

6. XState

讓我來(lái)介紹一下XState這個(gè)應(yīng)該已經(jīng)取代Redux的庫(kù)。主頁(yè)介紹：

很長(zhǎng)時(shí)間以來(lái)，我的Redux商店都缺少一些東西，我試圖制作一些小的中間件來(lái)幫助我馴服Redux，但是感覺……不完整。直到我找到XState。

為什么我在100%的React項(xiàng)目中使用XState?

我的問(wèn)題是Redux是一半，不知不覺中我在每個(gè)React組件中都在做小狀態(tài)機(jī)，用Redux做擴(kuò)展?fàn)顟B(tài)(或者說(shuō)是無(wú)限狀態(tài))，一旦我發(fā)現(xiàn)XState，所有設(shè)計(jì)問(wèn)題都遇到了有價(jià)值的競(jìng)爭(zhēng)者。

是否應(yīng)該顯示一個(gè)按鈕?啟用?顯示文字A還是B? 所有這些 "域" 的規(guī)格都不外乎是幾個(gè)狀態(tài)，有限的，事先指定好的;如果明確寫出這樣的狀態(tài)，讀取和升級(jí)組件就成了一件樂(lè)事。

用AngularJS和模板，我的狀態(tài)是由一堆交織在一起的變量組成的，無(wú)法讀取，用React和Redux，所有的數(shù)據(jù)都在一個(gè)地方，但狀態(tài)沒有任何表示，是對(duì)數(shù)據(jù)的一種解釋，但用XState，我的狀態(tài)其實(shí)是顯式的。