Ⅰ 微前端 quankun + vue
1、安裝 qiankun
2、在主應用中注冊微應用
1、main.js 導出相應的生命周期鉤子
2、vue.config.js 配置微應用的打包工具
Ⅱ 為什麼前端用vue的公司越來越多
1、對於創業公司一般起步的產品都是信息類（比如知乎、微博、商城類，並沒有太多對底層硬體的依賴的應用）的ios+安卓客戶。
用vue類的框架可以做出spa頁面，然後只需要套殼就可以生成ios/安卓客戶端，同時只需要維護一套代碼即可，大大縮短了上線時間，對於創業公司可謂下對了葯，要知道創業初期老闆最著急上線的。
2、weex to native對於已經有成熟的互聯網公司，他們更看重的是用戶體驗，自然對產品的流暢程度有了更高的要求，套殼應用的性能受所在手機的瀏覽器性能的影響。
在復雜操作的頁面自然不能和原生比，好消息是隨著前端技術的不斷探索，藉助node.js前端們可以讓js生成ios/安卓的代碼，比如阿里的weex，fb的react-native都可以直接用原生js的語法生成原生應用，這里的weex就是淘寶用vue的api設計的。
3、微信小程序還有最近火的微信小程序，其代碼就是JS。微信小程序的API也是按照Vue來設計的，也就是學會了Vue，學weex和小程序就會非常快。之所以這兩者在用Vue的API也正是因為Vue設計的API比較易懂上手快。
(2)vue微前端技術選型外包擴展閱讀：
Vue.js的目標是通過最簡單的API實現相應的數據綁定和組合的視圖組件。
它不僅易於上手，而且還便於與第三方庫或既有項目整合。另一方面，當與單文件組件和Vue生態系統支持的庫結合使用時，Vue也完全能夠為復雜的單頁應用程序提供驅動。
Vue.js自身不是一個全能框架——它只聚焦於視圖層。因此它非常容易學習，非常容易與其它庫或已有項目整合。另一方面，在與相關工具和支持庫一起使用時，Vue.js也能完美地驅動復雜的單頁應用。
Ⅲ qianKun + VUE 實現微前端架構 (基於vue2實現)
創建兩個項目作為實現demo，一個為主應用，一個為子應用
3.配置函數文件 microAppSetting
4.微應用出口文件 index.js
5.在App.vue內配置微應用容器及跳轉菜單
6.在main.js文件內引入微應用出口文件 index.js
7.運行後展示
8.在配置完子應用後的主應用展示
點擊子應用菜單
1.修改子應用路由文件內路由實例屬性： base 為 "/child"
2.在main.js文件內導出生命周期鉤子
3.配置Webpack、跨域與埠號
在vue.config.js內添加：
4.運行後展示
package.json
Ⅳ 電商後台管理系統的前端技術棧-----vue
現在市面上流行的框架有Jquery，Angular,Vue,React，下面說一下為什麼vue勝出了。
1.首先上場的是陪伴了我們N多多多年的jq大哥，他是原生js的封裝，幫助我們快速操作Dom，vue和react則是顛覆了操作dom的思想，通過數據的雙向綁定更改數據；
2.jq更偏向於js操作樣式，而vue和react這是進行數據操作較多一些；
3.在我們的項目中選用了vue，因為公司前端人員都會vue，不再需要學習成本，並且vue適合各種大小的項目，react更偏向於大型的項目；
4.在搭建後台管理系統上，大家都明白的基本上是不需要太多ui圖的，我們採用了ui庫（iview），這個iview是跟element對比後，做出的選擇，因為iview的功能更全，組件ui樣式更多一些；
5.項目的搭建沒有採用vue-cli，我認為vue-cli是為了模塊化，現在我們使用了iview這個ui組件庫，就沒有必要封裝自己的組件了。所以我們採用了多頁面的vue；
6.項目在css上選擇less，後期的打包還是使用webpack的，後期會出一篇文章講解webpack的多頁面打包。
總結：如果我的方向哪裡有錯誤的地方，還希望多多指教。
Ⅳ qiankun 實戰（一）
前兩天用了一下微前端框架 icestark , 在實際架構搭建過程中發現中發現在 Vue 主應用子應用之間切換 tag （tag 分別主應用和子應用的頁面）頁簽時會有子應用數據狀態無法保存的情況，搜索了一波解決方案後發現， icestark 中 React 應用實現了對數據狀態的緩存， Vue 裡面沒有這個實現。
React 實現的思路是通過 Tabs 組件結合 icestark 實現的一種機制，但是沒有用到路由。由於架構時間有限，發現按照那個方案調整是實現方面時間代價有點大，嘗試了一下 qiankun 發現框架中可以不存在這個問題，所以決定更換微前端框架方案為 qianun 。
如果想了解 icestark 可以看如下文章, 裡面有一些關於微前端架構理念的思考
快速上手微前端框架 icestark （一）
快速上手微前端框架 icestark （二）
本地使用 vue-cli 創建了一個 Vue2.0 純凈項目作為主應用，執行 yarn add qiankun 命名安裝 qiankun ，在 main.js 中引入 qiankun , 注冊並啟動
安裝 vue-router 時遇到一個版本兼容問題，通過 npm install vue-router --save 命令安裝會提示版本不兼容，如下效果
提示版本不兼容，如果通過控制台提示執行 npm install vue-router --save --force 或 npm install vue-router --save --legacy-peer-deps 可以安裝 vue-router ，但是在 Vue 項目中使用時會有無法正確引入的異常
因為默認安裝的 vue-router 是4.0大版本和現在的 vue 版本不兼容，要麼升級 vue , 要麼降級 vue-router ，公司前端團隊技術棧定的 Vue2.0 版本，果斷降級 vue-router , 安裝時 vue-router 時指定一個3.0的版本就行了, 執行 npm install [email protected] --save 命令即可。
src 目錄創建 public-path.js 文件，如果項目 lint 校驗不通過需要添加 /* eslint-disable */
修改 main.js 文件, 引入 public-path , 添加 qiankun 配置
修改 vue.config.js 文件中的打包配置
這時子應用的配置就添加好了
Vue 子應用的 @vue/cli-xxx 依賴不能為 5.0 版本，當前配置下導致無法單獨運行子應用。如果是安裝的最新 vue-cli 腳手架創建的項目最好看一下 @vue/cli-xxx 相關版本。
Ⅵ 前後端分離方案以及技術選型
作者：關開發
一.什麼是前後端分離？
理解前後端分離大概可以從3個方面理解：
1. 交互形式
2. 代碼組織形式
3. 開發模式與流程
1.1 交互形式
前後端不分離
後端將數據和頁面組裝、渲染好了之後，向瀏覽器輸出最終的html；瀏覽器接收到後會解析html，解析引入的css、執行js腳本，完成最終的頁面展示。
前後端分離
後端只需要和前端約定好接收以及返回的數據格式（一般用JSON格式），向前端提供API介面。前端就可以通過HTTP請求調用API的方式進行交互。前端獲取到數據後，進行頁面組裝、渲染，最終在瀏覽器呈現。
1.2 代碼組織形式
前後端不分離
在web應用早期的時候，前端頁面以及後台業務數據處理的代碼都放在一個工程下，甚至放在同一目錄下，前端頁面夾雜著後端代碼。前、後端開發工程師都需要把整套代碼導入開發工具才能開發。此階段下前後端代碼以及工作耦合度太高，前端不能獨立開發和測試，後端人員也要依賴前端完成頁面後才能完成開發。最糟糕的情況是前端工程師需要會後端模板技術（jsp），後端工程師還要會點前端技術，需要口頭說明頁面數據介面，才能配合完成開發。否則前端只能當一個「切圖仔」，只輸出HTML、CSS、以及很少量與業務邏輯無關的js；然後由後端轉化為後端jsp，並且還要寫業務的js代碼。
前後端分離
前後端代碼放在不同的工程下，前端代碼可以獨立開發，通過mock/easy-mock技術模擬後端API服務可以獨立運行、測試；後端代碼也可以獨立開發，運行、測試，通過swagger技術能自動生成API文檔供前端閱讀，還可以進行自動化介面測試，保證API的可用性，降低集成風險。
1.3 開發模式與流程
前後端不分離
在項目開發階段，前端根據原型和UI設計稿，編寫HTML、CSS以及少量與業務無關的js（純效果那些），完成後交給後台人員，後台人員將HTML轉為jsp，並通過JSP的模板語法進行數據綁定以及一些邏輯操作。後台完成後，將全部代碼打包，包含前端代碼、後端代碼打成一個war，然後部署到同一台伺服器運行。頂多做一下動靜分離，也就是把圖片、css、js分開部署到nginx。
具體開發流程如下：圖略
前後端分離
實現前後端分離之後，前端根據原型和UI設計稿編寫HTML、CSS以及少量與業務無關的js（純效果那些），後端也同時根據原型進行API設計，並與前端協定API數據規范。等到後台API完成，或僅僅是API數據規范設定完成之後。前端即可通過HTTP調用API，或通過mock數據完成數據組裝以及業務邏輯編寫。前後端可以並行，或者前端先行於後端開發了。
具體開發流程如下：圖略
二、前後端分離的好處與壞處。
從上面3個方面對比了之後，前後端分離架構和傳統的web架構相比，有很大的變化，看起來好處多多。到底是分還是不分，我們還是要理性分析是否值得才去做。
從目前應用軟體開發的發展趨勢來看，主要有兩方面需要注意：
· 越來越注重用戶體驗，隨著互聯網的發展，開始多終端化。
· 大型應用架構模式正在向雲化、微服務化發展。
我們主要通過前後端分離架構，為我們帶來以下四個方面的提升：
· 為優質產品打造精益團隊
通過將開發團隊前後端分離化，讓前後端工程師只需要專注於前端或後端的開發工作，是的前後端工程師實現自治，培養其獨特的技術特性，然後構建出一個全棧式的精益開發團隊。
· 提升開發效率
前後端分離以後，可以實現前後端代碼的解耦，只要前後端溝通約定好應用所需介面以及介面參數，便可以開始並行開發，無需等待對方的開發工作結束。與此同時，即使需求發生變更，只要介面與數據格式不變，後端開發人員就不需要修改代碼，只要前端進行變動即可。如此一來整個應用的開發效率必然會有質的提升。
· 完美應對復雜多變的前端需求
如果開發團隊能完成前後端分離的轉型，打造優秀的前後端團隊，開發獨立化，讓開發人員做到專注專精，開發能力必然會有所提升，能夠完美應對各種復雜多變的前端需求。
· 增強代碼可維護性
前後端分離後，應用的代碼不再是前後端混合，只有在運行期才會有調用依賴關系。應用代碼將會變得整潔清晰，不論是代碼閱讀還是代碼維護都會比以前輕松。
那麼前後端分離有什麼不好的地方嗎？我目前是沒有想到，除非你說會增加前端團隊的配備，後端工程師會變的不全能。。。
二、前後端分離架構方案。
實現前後端分離，主要是前端的技術架構變化較大，後端主要變為restfull 風格API，然後加上Swagger技術自動生成在線介面文檔就差不多了。
對於目前用於前後端分離方案的前端技術架構主要有兩種：
· 傳統SPA
· 服務端渲染SSR
2.1 傳統SPA
傳統SPA指的是單頁面應用，也就是整個網站只有一個頁面，所有功能都通過這一個頁面來呈現。因為一個人的肉眼，某一個時間點看一個頁面，既然如此何必要不同功能做多個頁面呢？只保留一個頁面作為模板，然後通過路由跳轉來更新這個模板頁面的內容不就可以了嗎？確實如此，現在通過reac全家桶、tvue全家桶，模塊化、路由、wabpack等技術輕而易舉就能實現一個單頁面應用。
單頁面應用的運行流程
1.用戶通過瀏覽器訪問網站url
2.單頁面的html文件（index.html）被下載到瀏覽器，接著下載html裡面引用的css，js。
3.css，js下載到瀏覽器完成之後，瀏覽器開始解析執行js向後端服務非同步請求數據。
4.請求數據完成後，進行數據綁定、渲染，最終在用戶瀏覽器呈現完整的頁面。
2.2 服務端渲染
服務端渲染的方案指的是數據綁定，渲染等工作都放在服務端完成，服務端向瀏覽器輸出最終的html。大家看完這個是不是有個疑問，這不是又回到了前後端不分離的時代了嗎？答案是否定的，因為這里的服務端是用來執行前端數據綁定、渲染的，也就是把瀏覽器的一部分工作分擔到了服務端。而目前具備這只種能力的服務端是NodeJs服務端。
它的原理其實就是在瀏覽器與前端代碼中間插入了一個NodeJs服務端。瀏覽器請求前端頁面時，會先經過NodeJS服務端，由NodeJs去讀取前端頁面，並執行非同步後端API，獲取到數據後進行頁面數據綁定，渲染等工作，完成一個最終的html然後返回瀏覽器，最後瀏覽器進行展示。
服務端渲染應用的運行流程：
1.用戶通過瀏覽器訪問網站url
2.NodeJS服務端接收到請求，讀取到對應的前端html，css，js。
3.NodeJS解析執行js向後端API非同步請求數據。
4.NodeJs請求數據完成之後，進行數據綁定、渲染，得到一個最終的html。
5.NodeJs向瀏覽器輸出html，瀏覽器進行展示。
PS：其實本質就是把前端編寫成一個nodeJs的服務端web應用。實施服務端渲染後，我們最終運行的是一個Nodejs服務端應用。而單頁面應用是把靜態頁面部署到靜態資源伺服器進行運行。
看到這里，你是否又有疑問，為什麼要這么麻煩搞服務端渲染呢？
2.3 SPA與服務端渲染方案對比
SPA的優點是開發簡單，部署簡單；缺點是首次載入較慢，需要較好的網路，不友好的SEO。
so，以下就是使用服務端渲染的理由了（摘取vue官方說法）：
與傳統 SPA (單頁應用程序 (Single-Page Application)) 相比，伺服器端渲染 (SSR) 的優勢主要在於：
· 更好的 SEO，由於搜索引擎爬蟲抓取工具可以直接查看完全渲染的頁面。
請注意，截至目前，Google 和 Bing 可以很好對同步 JavaScript 應用程序進行索引。在這里，同步是關鍵。如果你的應用程序初始展示 loading 菊花圖，然後通過 Ajax 獲取內容，抓取工具並不會等待非同步完成後再行抓取頁面內容。也就是說，如果 SEO 對你的站點至關重要，而你的頁面又是非同步獲取內容，則你可能需要伺服器端渲染(SSR)解決此問題。
· 更快的內容到達時間 (time-to-content)，特別是對於緩慢的網路情況或運行緩慢的設備。
無需等待所有的 JavaScript 都完成下載並執行，才顯示伺服器渲染的標記，所以你的用戶將會更快速地看到完整渲染的頁面。通常可以產生更好的用戶體驗，並且對於那些「內容到達時間(time-to-content) 與轉化率直接相關」的應用程序而言，伺服器端渲染 (SSR) 至關重要。
使用伺服器端渲染 (SSR) 時還需要有一些權衡之處：
· 開發條件所限。瀏覽器特定的代碼，只能在某些生命周期鉤子函數 (lifecycle hook) 中使用；一些外部擴展庫 (external library) 可能需要特殊處理，才能在伺服器渲染應用程序中運行。
· 涉及構建設置和部署的更多要求。與可以部署在任何靜態文件伺服器上的完全靜態單頁面應用程序 (SPA) 不同，伺服器渲染應用程序，需要處於 Node.js server 運行環境。
· 更多的伺服器端負載。在 Node.js 中渲染完整的應用程序，顯然會比僅僅提供靜態文件的 server 更加大量佔用 CPU 資源 (CPU-intensive - CPU 密集)，因此如果你預料在高流量環境 (high traffic) 下使用，請准備相應的伺服器負載，並明智地採用緩存策略。
以vue為例，實施服務端渲染可以查看官方指南： https://ssr.vuejs.org ，或選擇Nuxt.js
2.4 預渲染技術
如果你調研伺服器端渲染 (SSR) 只是用來改善少數營銷頁面（例如 /, /about, /contact 等）的 SEO，那麼你可能需要預渲染。無需使用 web 伺服器實時動態編譯 HTML，而是使用預渲染方式，在構建時 (build time) 簡單地生成針對特定路由的靜態 HTML 文件。優點是設置預渲染更簡單，並可以將你的前端作為一個完全靜態的站點。
如果你使用 webpack，你可以使用 prerender-spa-plugin 輕松地添加預渲染。它已經被 Vue 應用程序廣泛測試 - 事實上，作者是 Vue 核心團隊的成員。
prerender-spa-plugin: https://github.com/chrisvfritz/prerender-spa-plugin
三、前後端分離技術選型
- artTemplate + bootstrap（不推薦， 不算完全前後端分離）
- vue全家桶（推薦）
- react全家桶 （推薦，生態全）
Ⅶ 微前端——乾坤qiankun Demo
微前端就是將不同的功能按照不同的維度拆分成多個子應用。通過主應用來載入這些子應用。微前端的核心在於拆，拆完後在合！
我們可以將一個應用劃分成若干個子應用，將子應用打包成一個個的 lib 。當路徑切換 時載入不同的子應用。這樣每個子應用都是獨立的，技術棧也不用做限制了！從而解決了前端協同開發問題。
文檔地址： https://qiankun.umijs.org/zh
2018 年 Single-SPA 誕生了， single-spa 是一個用於前端微服務化的 JavaScript 前端解決方案 ( 本身沒有處理樣式隔離， js 執行隔離 ) 實現了路由劫持和應用載入。
2019 年 qiankun 基於 Single-SPA, 提供了更加開箱即用的 API （ single-spa + sandbox + import-html-entry ） 做到了，技術棧無關、並且接入簡單（像 i frame 一樣簡單）。
這里我們打算建立三個項目進行實操，一個Vue項目充當主應用，另一個Vue和React應用充當子應用
基座：qiankun-base 子應用：qiankun-vue、qiankun-react
react + react-router 技術棧的主應用：只需要讓子應用的 activeRule 包含主應用的這個路由即可。
vue + vue-router 技術棧的主應用:
用絕對路徑，不用用相對路徑，例如
qiankun 只能解決子項目之間的樣式相互污染，不能解決子項目的樣式污染主項目的樣式
沖突的樣式，採用BEM命名方式
子應用，需要增加 update 鉤子以便主應用手動更新微應用
主應用，直接調用子應用實例的 update 方法即可
Ⅷ 輕量、高效、功能強大的微前端框架-MicroApp
這幾年後端的微服務是比較火爆，我們公司目前只要是新項目，基本上都是基於微服務去架構的，那麼微前端是什麼呢？
微前端是借鑒了微服務的架構理念，核心在於將一個龐大的前端應用拆分成多個獨立靈活的小型應用，每個應用都可以獨立開發、獨立運行、獨立部署，再將這些小型應用融合為一個完整的應用，或者將原本運行已久、沒有關聯的幾個應用融合為一個應用。微前端既可以將多個項目融合為一，又可以減少項目之間的耦合，提升項目擴展性，相比一整塊的前端倉庫，微前端架構下的前端倉庫傾向於更小更靈活
以前我們為了把幾個獨立運行的小型應用合並成一個應用都是通過iframe的方式去實現的，如果不考慮體驗問題，iframe 幾乎是最完美的微前端解決方案了。
iframe 最大的特性就是提供了瀏覽器原生的硬隔離方案，不論是樣式隔離、js 隔離這類問題統統都能被完美解決。但他的最大問題也在於他的隔離性無法被突破，導致應用間上下文無法被共享，隨之帶來的開發體驗、產品體驗的問題
micro-app不是基於iframe架構的
micro-app提供了js沙箱、樣式隔離、元素隔離、預載入、數據通信、靜態資源補全等一系列完善的開箱即用功能
micro-app沒有任何依賴
為了保證各個業務之間獨立開發、獨立部署的能力，micro-app做了諸多兼容，在任何技術框架中都可以正常運行。
下面我講一下如何在Vue中使用micro-app
1、初始化一個基座應用
2、基座應用的文件修改
main.js修改
router.js修改
3、main-page.vue頁面
4、創建一個子應用
5、子應用的router.js文件修改
6、src目錄下新建 public-path.js
7、 main.js 引入public-path.js
到此這個簡單的微應用就搭好了
覺得效果不錯的請幫忙加個關注點個贊，經常分享前端實用開發技巧
Ⅸ Vue與Qiankun微前端組合
參考： https://blog.csdn.net/qq_42268364/article/details/116127872
https://gitee.com/hua0123/qiankun-demo/tree/master
https://blog.csdn.net/weixin_48726650/article/details/106905193
1、修改 App.vue
我們要在app.vue中創建一個容器，負責把獲取到的子應用載入到這里容器裡面
2、新建 arc/qiankun.js文件，引用qiankun並且封裝好
3、修改 main.js
4、修改 src/views/Home.vue
5、修改 src/views/About.vue
6、新建 vue.config.js
1、新增 src/public-path.js
2、修改main.js
在main.js，引入public-path.js 並配合主項目導出single-spa需要的三個生命周期。
注意：路由實例化需要在main.js裡面完成，以便於路由的銷毀，所以路由文件只需要導出路由配置即可（原模板導出的是路由實例）
3、vue.config.js
4、修改 src/router/index.js
5、修改 src/views/Home.vue
6、修改 src/views/About.vue
7、修改 public/index.html
分別啟動 main-app 和 hello-app 項目，然後訪問main-app的
Ⅹ htmlcssjsvue可以找外包嗎
可以。
會這些軟體後可以找外包了，但是不一定能接到外包，因為需要找人外包的公司會看你的實力如何才會找你外包。
外包是指企業動態地配置自身和其他企業的功能和服務，並利用企業外部的資源為企業內部的生產和經營服務。外包是一個戰略管理模型，所謂外包，在講究專業分工的二十世紀末，企業為維持組織競爭核心能力，且因組織人力不足的困境，可將組織的非核心業務委託給外部的專業公司，以降低營運成本，提高品質，集中人力資源，提高顧客滿意度。外包業是新近興起的一個行業，它給企業帶來了新的活力。