A. 如何搭建web前端框架
搭建web前端框架步驟如下：
1、確定項目使用的技術
根據項目的需求等來選擇使用的技術（這里以angular4 + typsescript + nodejs+mongodb舉例）
2、新建一個項目的工作文件夾
使用npm init初始化項目，根據問題配置，一般是直接回車使用默認配置,生成package.json文件
3、新建一個index.html頁面
4、新建配置文件system.config.js
5、新建ts的配置文件tsconfig.json
npm install typescript
6、新建webApp目錄，這裡面放的是所有html頁面和js代碼，首先得有個入口文件，與system.config.js配置文件中的入口文件名一樣，app.mole.ts，裡面引入了所有js文件，不被引入的在載入時都不會被載入
7、打包(將代碼壓縮，使程序運行速度更快）
B. 小白准備轉行學習前端，有大神可以提一些建議嗎
學習是以興趣為前提的，你要對你所要學碰配的內容產生興趣，這樣你才會花心思去學習。這和是不是小白沒關系的，對於小白而言，在學習過程中就需要更努力，多花時間和心思沒有什麼是學不會的。
自學方法：
1、作為一個初學者笑廳指，你必須明確系統的學習伏陵方案，我建議一定有一個指導的人，全靠自己學，放棄的幾率非常大，在你對於web前端還沒有任何概念的時候，需要一個人領進門，之後就都靠自己鑽研，第一步就是確定web前端都需要哪些內容，並且在多少時間內學完，建議時間6個月保底。
2、視頻為主，書為輔。很多初學者在學習前端的時候非常喜歡去買書，但是最後的結果是什麼？看來看去什麼都不會寫，所以在這里給大家提醒，書可以看，但是是在建立於你已經對於某個知識點有了具體操作的執行後，在用書去鞏固概念，這樣更加利於你對於知識的理解。
3、對於學習技術來講，掌握一個學習方法是非常重要的，其實對於學習web前端來講，學習方法確實很多都是相通的，一旦學習方法不對，可能就會造成「方法不對，努力白費」。其實關於這方面還是很多的，我就簡單說個例子，有的人邊聽課邊跟著敲代碼，這樣就不對，聽課的時候就專心聽，做題的時候就專心做題，這都是過來人的經驗，一定要聽。根據每個人的不同，可能學習方法也會有所出路，找到適合你自己的學習法方法是學習的前提。
4、不建議自己一個人瞎學，在我了解學習編程的這些人來看，從零基礎開始學並且最後成功做這份工作的其實並沒有幾個，我覺得大部分原因就是因為他們都不了解web前端是干什麼的，學什麼的，就盲目的買書看，到處找視頻看，最後看著看著就放棄了，所以我建議初學者在沒有具體概念之前，還是找有經驗的人請教一下，聊過之後你就會知道web前端具體是干什麼的，該怎麼學，這是我個人的小建議，可以不採納。
自學路線：
第1階段：前端頁面重構(4周)
內容包含了：(PC端網站布局項目、HTML5+CSS3基礎項目、WebApp頁面布局項目)
第2階段：JavaScript高級程序設計(5周)
內容包含：(原生JavaScript交互功能開發項目、面向對象進階與ES5/ES6應用項目、JavaScript工具庫自主研發項目)
第3階段：PC端全棧項目開發(3周)
內容包含：(jQuery經典交互特效開發、HTTP協議、Ajax進階與PHP/JAVA開發項目、前端工程化與模塊化應用項目、PC端網站開發項目、PC端管理信息系統前端開發項目)
第4階段：移動端項目開發(6周)
內容包含：(Touch端項目、微信場景項目、應用Angular+Ionic開發WebApp項目、應用Vue.js開發WebApp項目、應用React.js開發WebApp項目)
第5階段：混合(Hybrid,ReactNative)開發(1周)
內容包含：(微信小程序開發、ReactNative、各類混合應用開發)
第6階段：NodeJS全棧開發(1周)
內容包括：(WebApp後端系統開發、一、NodeJS基礎與NodeJS核心模塊二、Express三、noSQL資料庫)
視頻教程：
網頁鏈接
網頁鏈接
如果你對於學習前端有任何不懂的可以隨時來問我，如果沒有比較好的教程，也可以問我要。
C. 前端基礎設施怎麼搞看騰訊TDesign跨技術棧組件庫的最佳實踐
在 6 月 28 日的首屆 Techo Day 騰訊技術開放日上，騰訊發布了一系列「輕量級」產品，將騰訊多年自研產品的底層能力釋放給了開發者。
正如騰訊雲高級副總裁 & CTO 王慧星，在前不久的騰訊 TDesign 技術生態日提到的那樣：「自騰訊確立了開源協同，自研上雲的技術戰略，成立了十大技術領域委員會，推出了眾多 PaaS 能力，並將這樣的能力放在雲上，實現對內部和外部用戶的統一服務。」
而騰訊設計雲旗下的企業級產品設計體系騰訊 TDesign 正是這樣一款產品，其也在首屆 Techo Day 騰訊技術開放日活動中，發布了新的產品動態。據了解，目前騰訊 TDesign 的大部分組件已經完成了內測版本的發布， Vue 2、Vue 3、React 和移動端 Vue 3 也已經發布了公測版本和候選版本。與此同時，Augular、Flutter 、taro 等熱門技術棧也在開發的行列當中。
如果要回溯騰訊自研 UI 組件庫的緣由，這或許要先了解下前端領域的發展史。
縱覽底層的前端框架領域，先是經歷了 JQuery 一統江湖的時代，而後過渡到了 MVVM 框架成為主流的時期。目前，Vue、React 以及 Angular 則成為了前端開發人員使用最多、最廣的底層框架。可以看出，業界並沒有完全占據主導地位的前端開發框架，這也就導致前端技術團隊在迭代技術棧時，往往存在較大的切換成本，跨團隊共享前端資產時也會遇到技術棧差異的壁壘。
此外，由於組件庫和團隊技術棧存在一定耦合性的關系，對於很多企業中後台系統這樣的弱設計風格場景，我們可以根據整個棧的風格，大致推測出這個項目使用了哪種組件庫。例如，前端團隊選擇了 React 開發框架，大概率會用 AntD 組件庫；使用 Vue 開發框架，則大概率會直接用 iview-admin 頁面模板。這樣一來，技術棧的差異不僅會導致整個組件庫的選型受到一定限制，還會讓對外曝露的產品體驗存在較大的偏差。
因此，在產品體驗、開發效率與設計效率等因素的驅動下，騰訊通過開源協同的方式，與多個業務團隊共建了企業級設計體系騰訊 TDesign ，通過提供復用性的設計體系，為設計研發各個流程環節提供需要的設計和研發等解決方案。
在代碼組件庫中，騰訊 TDesign 基於業界實際的使用需求，已經覆蓋了 Vue、Vue Next、React 等主流的前端開發框架，目的在於讓公司內外部使用的同學都可以根據自身實際需求，選擇對應的組件庫產品，不再受技術選型的限制。當項目同時有桌面端和移動端使用需求的時候，騰訊 TDesign 還可以統一產品在兩端上的業務體驗。
從另一個角度來看，如果沒有統一的 UI 組件體系，UI 設計師的工作效率同樣是大打折扣的。在「騰訊前端通用 UI 組件庫技術生態日」活動中， 騰訊用戶研究與體驗設計部總經理陳妍說道：「如果沒有騰訊 TDesign 這樣的 UI 組件庫，設計師是最大的受害者，因為我橋核孝們的工作需要不斷的重復，沒有辦法把時間節省下來做更加有價值的事情。」
基於設計敏稿師的痛點，騰訊 TDesign 目前也提供了 Figma、Sketch、Axure 等設計資源以及 Sketch 設計插件，讓設計和代碼能夠無縫銜接，使設計資源分配到必要的環節。
既然騰訊 TDesign 選擇了支持各種技術棧的原生開發，就不可避免地會遇到幾類問題。例如，UI 組件庫怎麼保證與技術棧產物一致性？交互和 UI 實現怎麼保持一致？組件 API 怎麼保持一致？官網體驗與用戶氏並的實際使用如何保持一致？
據騰訊 TDesign 團隊透露，雖然業界基於上述挑戰已經有幾種不同實現的方式，但其各有優劣：
一種方案是基於 Web Components 做一個組件，將其使用在各個框架當中，但 Web Components 方案的優勢與具體實現框架沒有太大關系，因為是由瀏覽器原生支持，其最大的問題還是瀏覽器的兼容性，部分瀏覽器可以通過 polyfill 解決，但是有些政企瀏覽器的兼容性依然是不可小覷的問題。
另一種方案是直接將一份 React 代碼轉成 Vue，這帶來的好處是可以真正做到維護一份代碼，同時支持多技術棧，但統一整個前端技術棧其實是比較大的課題，目前業界還沒有統一的方案。另外，代碼轉換支持多技術棧的方案，其實在應用開發層會更常見，對於騰訊 TDesign 這種底層依賴而言，轉化後代碼的穩定性還是難以得到保障。
不僅於此，這種轉化方案的中間層代碼相當於是新的框架，既不是 Vue，也不是 React，對於貢獻者來說門檻比較高，會進一步導致開源社區不夠活躍，這同樣是騰訊 TDesign 團隊需要考慮的問題。
最終，騰訊 TDesign 團隊決定選擇用 Vue 開發 Vue 技術棧，React 開發 React 技術棧，除了 Angular、小程序等受技術棧限制，其他技術棧均統一用 Jsx 來維護組件實現，並主要解決了以下幾個問題：
組件 API 保持一致
騰訊 TDesign 團隊梳理出了開源項目前端組件上線的流程，在組件進入開發的前置階段，設置了 API / 交互稿統一評審環節，邀請各技術棧的實現者、UI/ 交互設計師以及 PMC 成員同學一起針對組件 API 的易用性、靈活性以及必要性進行評審，充分的討論過後，會將大家的意見形成整個組件的 API 描述，並錄入騰訊 TDesign 的組件 API 管理平台。
最終，API 管理平台會生成各個技術棧的 API 文檔、某個組件的 props.ts、typeb.ts 等文件。當組件開發者進行開發時，不需要對照文檔做開發，直接根據已經生成的定義文件開發即可，做 API 開發同學提了 PR 做 review 時，有任何更改會同步到各個技術棧實現的倉庫。
用戶實際使用與官網體驗保持一致
為了讓用戶的實際使用感受與官網體驗保持一致，騰訊 TDesign 做了一層官網共同的架構，目前所有的組件文檔包括文字部分，以及我們要展示的組件 Demo。各個端實現時，會各自引入一個 Web Components 實現官網的公共部分，通過統一的 Markdown 解析工具，最終解析出來的棧點就會完全一樣。
各個技術棧產物的 UI 和交互保持一致
除了要保證組件 API 一致，還要保證各個技術棧的產物里 UI 和交互都要完全一樣，這里 TDesign 做了兩件事情：第一，以 TDesign Token 貫穿設計開發流程，從最初設計師提供的設計稿，到組件庫里代碼的實現變數，一直到最終組件庫裡面 NPM 包產物，每個變數都有一一對應的關系；第二，抽取一個獨立的倉庫，將每個組件都獨立維護在 TDesign-common 倉庫，通過 Submole 的方式引入到實現倉庫里。當 UI 需要調整的時候，直接在獨立的庫里修改，再同步到各個技術棧實現的倉庫，最終保證整個 UI 和交互在各個技術棧上面實現完全一樣。
部分組件代碼復用
除了 UI 相關實現代碼做到了各技術棧復用，騰訊 TDesign 也參考了業界類似組件庫產品的實踐， 探索 了一些代碼邏輯復用的方案：一些與技術棧無關的組件抽象類，也抽取到了 TDesign-common 倉庫中；合理分層組件實現，通過 Hooks 和 Composition API 來跨技術棧復用部分代碼實現。
據了解，當前騰訊 TDesign 在內外部已經有了比較廣泛的應用基礎，騰訊內部在積極推動各個業務統一到 TDesign，也支持了多個領域和行業外部項目落地，並從中孵化出了多個行業組件庫。這些組件庫也將在未來逐步開源，持續支持各行業領域的系統建設。
而當我們開始回溯騰訊 TDesign 自開源以來的歷程，可以發現其取得的成績已經可圈可點：在開源社區的建設方面，騰訊 TDesign 仍然秉持著為社區貢獻價值的初心，不斷向有活力、高質量的開源社區進階。據統計，上半年 TDesign 共有 280+ 貢獻者，其中外部 17 ，核 貢獻者 47 ，GitHub star 4k+。
展望未來，騰訊 TDesign 還將繼續圍繞著兩個既定目標邁進：
第一，讓更多人使用騰訊 TDesign。後續組件庫各技術棧將發布 Stable 版本，並針對移動端開展專項優化，以確保提升組件質量和用戶使用體驗。為了最大化提升設計師的工作效率，還將提供 模板、移動端 Figma UIKit Variant（設計可配置能 ）等設計資源，並建設物料市場，承載更多的 業組件和模板資源。除此之外，TDesign 還計劃支持國際化以及無障礙適老化的適配；
第二，建設更有活 、更 質量的開源社區。為了幫助更多從業者了解企業級設計體系 騰訊 TDesign，社區後續計劃沉澱、總結設計體系和組件庫專業 章 / 課程。另外，為了吸引更多外部開發者加 貢獻，透明化內外部協作進度，開源社區將優化開發者的招募和激勵機制。
談及未來的發展規劃，騰訊 TDesign 團隊在接受 InfoQ 采訪時表示，未來除了會支持現有的前端技術棧，還將協同社區的力量推出 Web components、Flutter 等更多技術棧產品，服務於公司內外使用者。同時，也期待更進一步復用跨框架實現的代碼，在降低維護成本的同時，不顯著額外提升參與貢獻的門檻。
作為騰訊設計雲的關鍵產品，騰訊 TDesign 的誕生便是為了讓 UI 組件庫擺脫技術選型的影響，讓其回歸到前端基礎設施的地位上來。事實證明，在一步步的迭代與優化之下，騰訊 TDesign 已經逐步地將開源協同能力滲透給了更多企業。
與此同時， 騰訊用戶研究與體驗設計部總經理陳妍還在接受 InfoQ 采訪時透露：未來，騰訊設計雲將繼續在設計資產、設計協作效率發力，針對圖標庫、設計資產開源平台以及智能設計工具進行迭代升級。目前，騰訊設計雲已經初步完成平台建設階段，後續騰訊設計雲將逐步向內容建設方面進階。
我們也堅信，今後騰訊設計雲在實現高效設計、輕松協同目標的過程中，也將邁出更加堅實的一步。
D. 2020年前端最火的技術是什麼
我認為最火的技術有三個：TypeScript、Vue3.0、JAMStack
原因：
1、TypeScript 是一門基於 JavaScript 基礎之上的編程語言，很多時候我們都在說它是一個 JavaScript 的超集，或者叫擴展集。所謂超集，其實就是在 JavaScript 原有的基礎之上多了一些擴展特性。多出來的呢，實際上就是一套更強大的類型系統，以及對 ECMAScript 新特性的支持。而且它最終會編譯為原始的 JavaScript。
相比較於 Flow，TypeScript 作為一門完整的編程語言，它的功能更為強大。生態也更健全、更完善。特別是對於開發工具這一塊，微軟自家的開發工具對 TypeScript 的支持都特別友好。
2、Vue 是「一個用於構建用戶應用程序的漸進式框架」。它的設計非常靈活，可以將單個 Vue 庫集成到其他項目中，也可以完全使用 Vue 構建復雜的項目。Vue 通常被視為一個易於理解和實現的框架，它支持純 HTML 模板，而 React 需要使用 JavaScript 定義來 DOM 元素。
速度更快是 Vue 目前的主要賣點之一,Vue 以其渲染速度而聞名，與其他框架一樣，Vue 使用虛擬 DOM 來渲染組件。為了加速渲染過程，必須減少虛擬 DOM 的工作負載。通過編譯時間提示、組件快速路徑、單態調用、優化 slot 生成等手段來達到提速目的。
體積小
目前，Vue 的體積已經很小了（壓縮後 20KB）。由於進行了搖樹優化（消除非重要代碼），3.0 的預計大小約為 10KB（壓縮後）。主要是移除了對 Vue 項目來說不是很重要的庫，可以通過 import 語句來使用它們，而不是把它們打包在主 src 代碼中。
可維護性
Vue 3.0 將從 Flow 轉到 TypeScript，同時又非常重視兼容性易用性，不喜歡使用 TypeScript 的用戶仍然可以使用純 JavaScript。Vue 3.0 提供了更好的模塊化，從而變得更加可定製和靈活，還提供了透明性，開發人員可以深入到源代碼中。編譯器重寫是最令人興奮的功能之一，不僅帶來了更好的 IDE 支持，而且可以創建源碼映射，如果存在運行時錯誤，它將給出錯誤對應的文件位置和行號。
面向原生
Vue 3.0 將與平台無關——它將運行純 JavaScript，並且在其主構建中不會假設使用諸如 Node.js 之類的東西。這種靈活性使構建 Web、iOS 或 Android 應用程序變得更容易。面向原生使 Vue 更像是 React 的替代品。
易用性
公開 Reactivity API——新的變更允許開發人員顯式創建反應式對象和自定義重渲染 hook。3.0 還解決了 Vue 用戶經常抱怨的一個問題：什麼時候以及為什麼要重新渲染組件？3.0 提供了一個 renderTriggered 事件，人們可以通過它查看是什麼觸發了更新。這個出色的功能將使 Vue 更加透明。
3、JAMstack是指使用JavaScript、API和Markup構建的技術堆棧，JAM是JavaScript、API和Markup的簡稱，前面第一個字母縮寫，JAMstack一種基於客戶端JavaScript，可重用API和預構建Markup的現代Web開發架構
1. 更好的性能：為什麼要在部署時生成頁面時等待頁面動態構建？當談到最小化第一個位元組的時間時，沒有什麼能比通過CDN提供的預構建文件更好。
2. 安全性更高：將伺服器端進程抽象為微服務API，可以減少攻擊的表面區域。您還可以利用專業第三方服務的專業知識。
3. 更便宜，更容易擴展：當您的部署相當於可以在任何地方提供服務的一堆文件時，擴展就是在更多地方提供這些文件的問題。CDN是完美的，通常包括擴展他們的所有計劃。
4. 更好的開發者體驗：鬆散耦合和控制分離允許更有針對性的開發和調試，並且為站點生成器擴展選擇CMS選項消除了為內容和營銷維護單獨堆棧的需要。
所以我認為最火的技術應該就是這三個。
E. 前端常用的框架有哪些
有三大主流框架，分別為：Angular、vue、react
1、我們在大型超大型web應用開發上，看好Angular：
深度整合Typescript和Rxjs。ts解決了工程化的問題，rxjs解決了開發速度的問題。但是學習成本，可能對於Java，c#等OOP工程師來說比較容易上手，但是對於JavaScript工程師來說，少有工程化的經驗，接受起來比較痛苦。當然，不只是Angular可以採用Typescript開發，很多其他的Dom庫都可以，Angular相比他們的優勢在於：
1.零配置
2.深度整合設計模式
3.約定才是框架的本質
2、小型應用上，看好vue
其實絕大部分web應用，都應該只是小型應用。公司官網，論壇，甚至是規模不大的電子商務網站和基本功能的OA，ERP系統，都只是小型web應用。它們數據源穩定，對於運營的要求不高，但是對載入速度等都有很高的要求。這個時候，小巧的vue就成了首選。Proxy實現的響應式相比Angular的zone暴力代理和rxjs的復雜操作顯得更加接地氣，不需要額外地進行學習。對象式的聲明在UI實現上速度更快。生態雖然沒有react那麼熱鬧但是小而美的庫也很多，nuxt的實現值得點贊。
3、個性化需求、中型應用，更傾向react
在中大型應用中，不是一定要搞Java那一套的，而且在前端這種對工期要求很緊的領域，沒必要因為添加新功能而更換新的平台，能用到rxjs和依賴注入的前端應用場景並不多。所以如果採用react，從項目一開始就漸進式地添加模塊，往往更適合快速發展的產品。
F. 從0搭建React+antd+TypeScript+Umi Hooks+Mobx前端框架
因為現在公司的主要技術棧是React,所以也想著能夠搭建一個好的React前端框架，方便在工作中使用；框架在打包過程也做了優化，多線程，拆包，緩存等等手段提升打包速度和質量。主要用到的庫包括：
創建帶TypeScript模板的react-app，推薦使用yarn,接下來我也主要以yarn做例子
然後在項目根目錄創建一個 craco.config.js 用於修改默認配置。antd按需載入以及自定義主題
重新打包就可以了， 所有的主題配置在這里噢
這里利用React-router做路由，同時也會根據用戶角色，做許可權處理；只有當角色和路由允許的角色一致時才可以訪問和展示。
新建router下新建indext.tsx 用於渲染頁面
引入Router/index.tsx
新建hasPermission.ts,如果頁面 roles 包括用戶的角色則返回true,在渲染menu和子頁面的時候就根據這個值渲染頁面。
比如Home頁面，渲染子頁面的邏輯：
在這里 SubPages1 下面的 page1 就無法展示出來和訪問，如果直接輸入路由也會訪問頁面不存在，因為page1允許的角色 user 而我們角色是 admin 所以無法展示。
useImmer 很好的解決了ReactHooks中的賦值的性能問題，可以單獨更新某個對象的某個屬性。
上面的賦值方法也可以寫到一起,效果是一樣的：
Umi Hooks 是一個 React Hooks 庫，致力提供常用且高質量的 Hooks。提供了非常多的Hooks組件，比如上面使用的 usePersistFn ，他的作用：在某些場景中，你可能會需要用 useCallback 記住一個回調，但由於內部函數必須經常重新創建，記憶效果不是很好，導致子組件重復 render。對於超級復雜的子組件，重新渲染會對性能造成影響。通過 usePersistFn ，可以保證函數地址永遠不會變化。Umi Hooks功能還是非常強大的，有很多功能很強大的API。大家可以去官方文檔看看 https://hooks.umijs.org/zh-CN/hooks/life-cycle/use-update-effect 。
自定義 hooks 其實在我們的開發工作中，還是很常遇到的。 hooks 的好處就是可以抽離公共方法，像組件一樣的隨意使用，對於快節奏的開發工作還是很舒服的，比如你覺得 react hooks 或者 umi hooks 的api，不能滿足自己的需求，也可以自己創新一些api。我這里舉個例子，大家寫 class 組件寫的很多的話，會經常用的 this.setState() ，大家都知道 this.setState() 是非同步執行，你無法直接拿到最新的 state 。 hooks 中的 useState 同樣也是非同步的，你無法直接獲取到最新的 state ，所以我自己寫了一個 useSetState 方法，用於在修改完狀態後能夠立即拿到最新的 state 。
我們在src/hooks文件夾下新建 useSetState.ts
使用的方式也很簡單，基本和useState一致，只是在setState的時候提供一個回調函數。
這就完成了帶回調的 useSetState hooks 的編寫，不過這種寫法不太推薦在 hooks 中使用，建議需要獲取最新的數值都在 useEffect 或者 useUpdateEffect(umi hooks) 中去。
狀態管理選擇的Mobx,Mobx和Rex我都用過，不過當我習慣用Mobx後，就感覺還是Mobx更方便一些，所以更喜歡在項目中用Mobx,現在Mobx已經更新到5.0版本了，不過5.0版本並不支持ie11，所以如果想要兼容性可以選擇4.0的版本，或者Rex。
這里推薦一個針對Mobx的庫， mobx-react-lite :它是基於 React 16.8 和 Hooks 的 MobX 的輕量級React綁定。
這個主要影響的是調用方法的形式，對於Mobx的書寫是一樣的，比如寫一個加減數值：
這里你的typeScirpt可能會編譯不了，會報錯：Experimental support for decorators is a feature that is subject to change in a future release. Set the 'experimentalDecorators' option in your 'tsconfig' or 'jsconfig' to remove this warning.
解決方法是在 tsconfig.json 加入配置：
完畢以後，一定要把 storeProvider 包裹所需要共享狀態的頁面，我這里直接放到app.tsx
剩下來就僅僅是調用的事情了：
此外axios的配置應該大家都知道，所以我這也不多說了，具體在我的源碼裡面也有，utils下的axios.ts
加入了打包分析 webpack-bundle-analyzer speed-measure-webpack-plugin
加入了打包進度條 webpackbar
加入了打包壓縮 compression-webpack-plugin terser-webpack-plugin
還對包進行拆包
開發環境的域名代理 devServer
加快打包速度，還可以考慮刪除antd-icons，單獨去iconfont網站下，按需引入。不然打包會費很多時間
引入dotenv-cli
新增開發環境配置文件 .env.development 和 .env.proction 兩個文件
然後修改package.json中的啟動腳本：
現在 yarn start 或者 yarn build 就會根據環境配置來處理。
還有一些細節的調整，會盡力將這個框架更加完善的。
github地址： https://github.com/Benzic/React-typescript-umihooks-mobx
歡迎star 和提意見
G. 基於Vue3+TS+ElementPlus+Qiankun構建微應用項目
Hello 大家好，這里是Anyin。
最近打算把一個小型項目（小程序點餐系統）重構為微服務+微應用模式，前端的技術棧打算使用Vue3 + TS + ElementPlus + Qiankun 。這里記錄下我在構建基礎微應用的過程。
重構後的項目相關地址：
•後端： Anyin Cloud [1]
•前端基座： Anyin Cloud Parent[2]
•前端微應用： Anyin Cloud Base[3]
好了，接下來，我們來看看如何基於 Vue3+TS+ElementPlus+Qiankun 構建我們的微應用項目。
另外說下，這正銷猛里為什麼不用 Vite 進行構建，原因是 Vite 目前結合 Qiankun 構建為應用還有點問題（采坑了），所以這里就放棄了。
首先，我們使用 vue-cli 創建一個parent項目:
接著，手動選擇我們要添加的組件：
我們選擇以下組件進行應用的構建，使用空格鍵進行多選，然後回車即可：
選擇vue3.x版本
相關代碼風格、路由模式都是使用默認，css編譯我們使用less：
相關編碼規范我們使用ESLint + Airbnb Config ：
最後，完整的選項如下：
當vue-cli幫我們創建好項目，我們進入項目查看下項目目錄，如下：
首先，Qiankun的主應用是需要安裝依賴的，微應用無需安裝依賴，修改配置即可。這里我們先在主應用安裝依賴
接著，進行相關微應用配置。我們新增一個 app.ts ，用於記錄所有的微應用斗慧的入口：
然後，注冊微應用，並導出start方法
導出 start 方法之後，需要在入口處執行該方法
對於整個界面，我們希望整體的布局是這個樣子的：
所以，我們在安裝 ElementPlus 之後，需要做這樣子的布局。
首先，安裝 ElementPlus
接著，在 main.ts 引入 ElementPlus 組件，如下:
然後，創建一個布局組件 Layout.vue ，如下：
最後，在App.vue注冊該組件
運行起來呈現的效果如下：
微應用的初始化項目同主應用，這里就不詳細說明。
微應用無需依賴 Qiankun ，這里我們做一些配置即可。
在 src 目錄下新增一個 public-path.js 文件，內容如下：
在 main.ts 引入該文件
新增一個路由配置文件，這里我們創建對應的路由信息，並且兼容獨立運行，內容如下：
接著，修改 main.ts 關於實例化的代碼，如下：
這里主要是定義個渲染的方法，然後暴露舉橋Vue實例，因為等下在微應用的生命周期的鉤子會使用到。
對於微應用還需要暴露生命周期的鉤子方法，這樣子主應用才能夠識別，在 main.ts 添加如下方法：
使用 vue 創建項目是沒有 vue.config.js 文件的，這里我們手動創建一個，並且配置相關詳細，代碼如下：
•這里我們導入了 package.json 的 name 欄位，因為這里需要和主應用配置的 app.ts 文件的 name 欄位一致 • headers 添加跨域配置，因為主應用是通過 fetch 方法來獲取微應用的資源的，而微應用是啟動在另外一個埠，所以需要添加跨域配置 • output 配置了微應用的打包格式，主應用才能正確識別微應用的一些配置
還記得我們以下這個圖不？
我認為 Header 應該是屬於主應用，而下面的 Aside 和 Main 都是屬於微應用， Aside 塊一般都是用於展示菜單，個人認為各個微應用應該各自維護自己的菜單，而不是交由主應用維護。
所以，在微應用，我們還需要處理下左側的菜單布局。
我們新增一個 Layout.vue 布局文件
至此，Vue3+TS+ElementPlus+Qiankun構建微應用項目的一個基本結構我們已經處理完成，整體運行看下效果：
首頁
微應用
好了，基於 Vue3+TS+ElementPlus+Qiankun 的微應用項目基本框架我們已經搭建好了，後續就是慢慢填充一些工具和頁面了。
相關源碼地址：
•主應用： Anyin Cloud Parent
•微應用： Anyin Cloud Base
[1] Anyin Cloud : https://gitee.com/anyin/anyin-cloud
[2] Anyin Cloud Parent: https://gitee.com/anyin/anyin-cloud-parent
[3] Anyin Cloud Base: https://gitee.com/anyin/anyin-cloud-base