感覺自己有點(diǎn)狂，居然敢在自己的文章中說這是最佳實(shí)踐。不過有人不是說了嗎，牛皮還是要吹的，萬一實(shí)現(xiàn)了呢？
接下來公司的項(xiàng)目，就是純粹的RN項(xiàng)目，從這個(gè)項(xiàng)目開始，做一些最佳實(shí)踐的總結(jié)，我想是個(gè)不錯的開始。
今天搭建了windows的開發(fā)環(huán)境，不是特別順利，主要可能是資源被墻的原因，導(dǎo)致安裝出錯，或者安裝緩慢。如果后面我想摸索了，可以專門嘗試下，看看到底哪些資源需要翻墻，如果不翻墻該怎么解決的文章。
開發(fā)RN項(xiàng)目，首選還是MAC,畢竟跨平臺，iOS也是不能少的。我前面都是用的Mac，想熟悉下windows，所以……
扯遠(yuǎn)了，其實(shí)也還好，如果出一篇開發(fā)環(huán)境該安裝哪些工具和插件，也算是最佳實(shí)踐的一部分吧[/狗頭]。
下面列出【我以為】的最佳實(shí)踐
集成Typescript
使用npx react-native init myrnprojectname --template react-native-template-typescript初始化項(xiàng)目，因?yàn)闀詣蛹蓆ypescript到項(xiàng)目中。
原因：
為新建的項(xiàng)目創(chuàng)建git倉庫
原因：
使用module別名，減縮導(dǎo)入module的長度
原因：
Using Custom Path Aliases with TypeScript
babel-plugin-module-resolver
使用Fastlane自動化打包、上傳、發(fā)布
原因：
使用文件夾的方式組織組件
在接觸 react-native 開發(fā)時(shí)，基本上看到的例子，都是將組件實(shí)現(xiàn)和樣式寫在同一個(gè)文件中。這種方式將相關(guān)實(shí)現(xiàn)集中在一起，但是同時(shí)也讓它們糅合在一起，反而又不便于管理。
我喜歡用 typescrit 的方式寫 react-native 項(xiàng)目。那么在創(chuàng)建一個(gè)組件時(shí)，我通常需要些組件、樣式、限定props 和 state 的類型。如果寫在一個(gè)文件中，有很大的概率讓這個(gè)文件變得非常臃腫。
我這里說的“文件夾的方式組織組件”，就是想保持組件集中實(shí)現(xiàn)的同時(shí)，又能保證組件內(nèi)各部分的相對獨(dú)立。
比如我想創(chuàng)建一個(gè)SearchBar,我可以使用以下結(jié)構(gòu)來定義：
- SearchBar
- index.tsx (組件渲染)
- styles.tsx (樣式)
- types.tsx (類型)
以上定義乍一看還麻煩了，你試想下如果我們有一個(gè)復(fù)雜的組件，其實(shí)可以分成上、中、下三部分再組合在一起,然后按照“文件夾”的方式，將它們組織成如下結(jié)構(gòu)：
- ComplexComponent
- index.tsx
- Top.tsx
- Middle.tsx
- Bottom.tsx
- styles
- index.tsx
- top.tsx
- middle.tsx
- bottom.tsx
- types
- index.tsx
- top.tsx
- middle.tsx
- bottom.tsx
上面的結(jié)構(gòu)有個(gè)明顯的好處，所有關(guān)于 ComplexComponent的信息都在它所在的文件夾中，集中管理。內(nèi)部組件、樣式和類型又各司其職，調(diào)理清晰。即便有更復(fù)雜的組件，我們也可以用這種方式來擴(kuò)展。
想必你會說這樣寫太繁瑣，但是我想說的是，效率固然重要，代碼可讀性、可維護(hù)性也同樣重要。不要只圖一時(shí)之快。
使用Axios做網(wǎng)絡(luò)請求，使用Axios攔截器
- axios-logger ：輕松攔截請求、響應(yīng)日志，并輸出到控制臺；
將iOS/Android原生依賴庫封裝成本地React Native Module
方便升級和代碼復(fù)用
發(fā)布APP時(shí)移除console.log
babel-plugin-transform-remove-console
