模塊引用方式利弊辨析： 全局絕對引用(alias) && 長相對引用

前言

這個問題首先要從咱們項目的require語句開始提及。

當打開咱們項目的時候，咱們可能會看到一大堆長相對引用，以下所示：

import component from '../../../../component/aaa.js'

你必定知道，webpack中有個叫作alias的配置屬性，能夠幫助咱們搞全局引用配置。好比說，在webpack.config.js中配置相應的鍵值對，咱們就能夠經過require(‘util’) 這種方式，而非require(‘../../../util’)這種方式，去作引用。

項目中雖然沒有用webpack,可是用到了babel，而babel有個叫作babel-plugin-module-resolver能夠作相似的事情

介紹：    https://www.jianshu.com/p/beafc1470fca 
npm地址： https://www.npmjs.com/package/babel-plugin-module-resolver

 

好，最關鍵的問題來了，究竟是選用全局絕對引用(alias)   仍是  長相對引用？？？ 其利弊幾何？？

兩種方式

• 使用全局路徑，依靠babel插件實現全局引用(alias)
• 使用相對路徑，並依靠VScode自帶功能提高效率

使用全局路徑，依靠babel插件實現全局引用(alias)

利

• 代碼簡潔，短小精悍

弊

• 沒法利用VScode默認自帶功能實現點擊跳轉，好比咱們看代碼時候常常須要點擊一個require的連接，而後實現跳轉，可是使用這種alias的時候不能實現自動跳轉
• 沒法利用VScode默認自帶的路徑導入功能，寫成alias雖然簡單了，可是形式上簡單，實際工程中卻未必簡單，這是由於，若是是採用相對路徑的話，根據系統的默認自帶功能，能夠自動引入相對路徑的，根本無需編寫。若是你採用絕對路徑的方式書寫方法時，VScode的這一功能就心有餘而力不足了
• 徹底不須要考慮代碼重構問題
• RN-web和RN的代碼打包方式不一致，可能產生衝突，由於RN用的是babel結合bundleJS打包的，而web是根據webpack打包的，二者在設置全局alias的時候方式可能不同，須要測試預估風險

使用相對路徑，並依靠VScode自帶功能提高效率

利

實際上，今天的VScode已經很是強大了，上面的對比其實就講了VScode自帶功能，給相對路徑的效率帶來的巨大提高：

• VScode默認自帶相對路徑跳轉功能，實現相對路徑點擊跳轉。這是個很是有用的功能，當你在A文件中，看到它引用了一個B文件下的類，你能夠直接跳轉到B文件，讓代碼閱讀變得很是方便
• VScode默認自帶相對路徑導入功能，若是是採用相對路徑的話，根據系統的默認自帶功能，你敲出方法名的時候，會逐個字母篩選並顯示提示，同時選擇對應方法的時候，文件上方會自動引入那個模塊的相對路徑。
• 文件路徑修改時候，VScode自帶一鍵更新路徑功能，因此重構什麼的so easy！
• 思路保守，不會發生不可預測的問題

弊

額。。。。。。 好像除了寫起來不太好看以外，沒有什麼明顯的缺點，哈哈哈哈

折中方案， 以及進一步的利弊分析

OK，那咱們能不能既讓代碼好看，同時還使用方便簡單呢？？

其實我想過這麼一種方案：

1.經過加入alias的功能，讓代碼簡潔漂亮，不像長相對路徑那樣那麼冗長

2.經過IDE插件，如VScode插件，讓代碼編寫的流暢性和相對路徑同樣

 

可是這種方式的缺點顯而易見：

• 插件生態問題：咱們團隊不可能你們都用VScode, 並且原本VScode就不必定有這種插件，而其餘IDE的社區就更差了，我認爲能經過插件達到效果的但願不大
• 就算真的有這些插件，使用起來彷佛也不太方便，VScode的擴展插件的代碼是不能上傳到github的，要本身下載，而同步的話又須要額外的插件，這樣，新人加進來就不能作到開箱即用了。咱們之間團隊的協調還不能作到徹底一致，可能新人進來沒人引導他下載這些VScode插件
• 好吧，就算前2種都沒問題，但其實仍是有問題，由於咱們沒辦法徹底禁掉相對路徑引用，因此結果就是相對引用和絕對引用並存的狀態，這時候風格就很亂，不統一

結論

 

就用相對路徑吧！！ 難看就難看唄，我們追求的是實用主義