者 | 六小登登
責(zé)編 | 屠敏
從 2013 年專科畢業(yè)開始,一路跌跌撞撞走了很多彎路,做過餐廳服務(wù)員,進過工廠干過流水線,做過客服,干過電話銷售可以說經(jīng)歷相當(dāng)?shù)摹柏S富”。
最后的機緣巧合下,走上了前端開發(fā)之路,作為一個非計算機專業(yè)且低學(xué)歷的人來說,自學(xué)編程其實不是件容易的事情,不過慶幸的是自己堅持下來了。
目前工作還算不錯,收入在目前所在的城市不算高,不算低,生活也還過得去,繼續(xù)加油努力,也希望自己在今后更上一層。
從 2016 年下半年開始,我真正接觸前端,到現(xiàn)在 2 年多的時間。開始之初,我沒有任何的語言基礎(chǔ),完全從零的小白開始,就連「對象」我都弄不明白,更別說那些高深莫測的什么封裝、繼承、多態(tài)等。
當(dāng)時自己也不知從何入手,怎么辦呢?于是每當(dāng)自己遇到困難時,就厚著臉皮去請教前輩大牛,然后就是去查閱資料,很多時候自己也很覺得不好意思,現(xiàn)在才發(fā)現(xiàn)人很多時候都恥于相別人請教,怕自己丟面子。
但作為一個過來人,我要告訴你請教前輩大牛真的很重要,可以讓你少走很多的彎路,不要怕丟人,沒面子,面子值幾個錢?學(xué)到真本事才最重要。沒有技能才叫真的沒有面子。當(dāng)然了我們在請教別人時,一定要掌握「度」,不要打擾到了別人的工作。
我現(xiàn)在非常感謝前輩們的賜教,也感謝那些在網(wǎng)上寫博客、文章分享的大牛們,給了我們這些自學(xué)的小白很多的資料,經(jīng)驗,心得。從中受益很多。
向優(yōu)秀的前輩們學(xué)習(xí),我開始寫博客,希望也能幫到和我一樣,學(xué)渣、從零開始、喜歡技術(shù)的一群志同道合的人。
我深知自己的技術(shù)并不高,還處在繼續(xù)學(xué)習(xí)的路上,離大牛還差的很遠(yuǎn),我本身也非常敬畏技術(shù),也知道自己的渺小,只希望這篇文章的「學(xué)習(xí)之路」對于那些「從零開始」學(xué)習(xí)前端的同學(xué)有一些指引作用,不像自己一開始那樣的那么盲目,哪怕對你有一點點的幫助,就足夠了。
說了這么多,下面我們直接進入正題,都是我平時學(xué)習(xí)和收集的一些資料希望能夠幫到你。
前言
工具篇
工欲善其事,必先利其器,所以在開始之前選擇一個合適好用的編輯器是很重要的,工具不再多,在于好用就行,除了編輯器,我們也要掌握其他的一些工具,才能夠讓我們在學(xué)習(xí)的道路上更加的順暢。
1. WebStorm
不必多說,前端最強大的編輯器,特別是那無敵的智能提示,但是它的缺點在于如果項目多于大時,出現(xiàn)的卡頓讓很多人苦惱。
2. Visual Studio Code
微軟開源免費產(chǎn)品,受到非常多技術(shù)人員的喜愛,基本上成為前端開發(fā)者的必備編輯器,強大的插件擴展,可以靈活的打造自己喜歡的風(fēng)格。給你們送上常用插件列表拿走不謝。
3. atom
也是一款免費開源的編輯器,受到很多人的喜愛,但是我本人用的較少,所以插件方面就不推薦了,大家可以按照自己的愛好去尋找。
4. 科學(xué)上網(wǎng)
每個程序員都應(yīng)該具備的工具和能力,否則很多事情都無法辦到,至于怎么做,你可以自己查閱資料,這里不就不在多說了。而且下面推薦的很多資源都是需要科學(xué)上網(wǎng)之后才能訪問,所以一定要學(xué)會。
5. Google
在使用「Google」之前必須學(xué)會科學(xué)上網(wǎng),不然無法訪問,學(xué)會使用搜索可以幫助我們解決很多問題,一個人的知識是有限的,掌握了搜索的技巧才能以不變應(yīng)萬變,很多時候百度出來的東西重復(fù)性很大,最重要的是垃圾信息很多,在百度找不到的答案,在這里很容易找到,Google 是我的必備搜索。
6. Github
全球最大的「同性」開源交流社區(qū),沒有賬號的趕緊注冊,在這有很多優(yōu)秀的資源項目,各種大神。觀摩優(yōu)秀代碼是我們學(xué)習(xí)的很好路徑。另外在開發(fā)過程中,很多時候任務(wù)重、時間緊,應(yīng)該避免重復(fù)造輪子,這里能夠找到你需要的工具或代碼。
7. Stack Overflow
國外著名的技術(shù)問答交流社區(qū),開發(fā)時碰到的很多問題在這里都能找到答案。
8. SegmentFault
對應(yīng)的國內(nèi)版的技術(shù)問答交流社區(qū),如果你英文不好,也可以在這里找找答案。
9. Markdown
Markdown 輕量級標(biāo)記語言,簡潔的語法,讓作者專注內(nèi)容而非復(fù)雜的格式要求,我認(rèn)為人人都應(yīng)該掌握,特別是經(jīng)常寫博客的人。想想你在用 world 時的場景,每次寫完文章之后,不得不話費很多時間進行格式的排版,使用它你就可以避免這些煩惱。
HTML 篇
一些準(zhǔn)備就緒之后,開始我們的學(xué)習(xí)之旅,首先我們先從 HTML 開始。
HTML名為「超文本標(biāo)記語言」,是整個頁面的結(jié)構(gòu)基礎(chǔ),它承載了我們的頁面內(nèi)容。
1. 基礎(chǔ)
2. 進階
CSS 篇
HTML 承載了頁面的內(nèi)容,但是有時候會略顯單調(diào)與「丑陋」,CSS 的作用就是為這些內(nèi)容加上樣式,就像一個美女也要有漂亮的外衣去修飾才會更加漂亮,「人靠衣裝馬靠鞍」,網(wǎng)頁的內(nèi)容也是需要穿上一件漂亮的外衣去吸引用戶。而 CSS 則完成了這個裝飾。
1. 基礎(chǔ)
2. 進階
書籍:
《CSS揭秘》(https://book.douban.com/subject/26745943/):非常推薦的一本 CSS 書籍,可以學(xué)到很多鮮為人知的技巧。
在線系列:
知識點:
JavaScript 篇
有了 HTML 與 CSS,網(wǎng)頁也就有了內(nèi)容和樣式,但是會缺少與用戶的互動,所有的內(nèi)容都靜靜的躺在那里死氣沉沉。就好比一個美女穿著漂亮的衣服在你面前一動不動好像也沒有什么吸引力,但如果又唱歌,又跳舞,還向你拋媚眼,那可真就把持不住了。JavaScript 就是給網(wǎng)頁添加這樣的「行為」。
Javascript 簡史(https://blog.csdn.net/qq_32135281/article/details/81667714):可以簡單了解下,JavaScript 發(fā)展由來。
1. 基礎(chǔ)
書籍
在線系列
除了書籍之外,也有很多優(yōu)秀的在線教程,可以幫助我們更好的學(xué)習(xí)。
2. 進階
TypeScript篇
ES6 的超集擴展,嚴(yán)格的數(shù)據(jù)類型,帶來更好的維護,適合大型項目的開發(fā)工作,有人說它是未來的發(fā)展趨勢,你說要不要了解?
Jquery篇
雖說現(xiàn)在已經(jīng)是單頁面應(yīng)用時代,有React,Vue 這種強大的框架可以使用,但也不缺乏一些老的項目需要維護,而且在學(xué)習(xí)之初,可以用它做兩個簡單的應(yīng)用還是不錯的,可以相對了解下基本用法,它可以讓你更好,更方便的操作DOM。但不建議再深度學(xué)習(xí)。
Ajax篇
掌握了的HTML、CSS、JavaScript時,這時候可以嘗試自己做一些項目了,而項目中肯定會有數(shù)據(jù)的交互,這時候就是 Ajax 的用武之地了。
NodeJS與模塊化
NodeJs 的出現(xiàn)讓前端發(fā)展進入了一個新的領(lǐng)域,并且滋生出專業(yè)的 Node 工程師,不僅如此 Node 在前端模塊化,工程化起到很重要的作用,所以了解是必須的,如果感興趣的可以深入學(xué)習(xí),可以向全棧工程師發(fā)展。
框架篇
隨著日益復(fù)雜的用戶需求,與系統(tǒng)的復(fù)雜度上升,傳統(tǒng)的開發(fā)模式日漸的很難滿足,此時的三大框架孕育而生,讓開發(fā)者更加高效,可復(fù)用,把關(guān)注點都放在數(shù)據(jù)層的操作,免去那些繁瑣而又重復(fù)的視圖操作。
現(xiàn)在框架的能力已經(jīng)是前端開發(fā)人員必備的技能之一也是趨勢,三大框架的「最終目的」都是一致的,我認(rèn)為開發(fā)者不必糾結(jié)于到底應(yīng)該選擇哪一個學(xué)習(xí),可以選擇其中的兩個是最好的。對于剛?cè)腴T的人來說,建議選擇 Vue 入手,比較簡單,靈活。
1. Angular
2. Vue
3. React
React我了解不多,所以就沒什么好推薦的了,大家可自行學(xué)習(xí)。
圖形可視化
隨著日益增長的數(shù)據(jù),如何利用高效的利用數(shù)據(jù),是每個企業(yè)都考慮的問題,而人的眼睛看到的東西要勝過閱讀的問題,俗話說「一圖勝千言」就是這個道理,所以數(shù)據(jù)的可視化就會格外的重要,以下都是我常看的一些技術(shù),書籍,和關(guān)注的可視化開源庫。
工程化與版本控制篇
1. Git
版本控制工具,很多新手往往把 git 與 github 傻傻分不清楚,二者是不同的東西,一定要去區(qū)分清楚。
2. Gulp
自動化構(gòu)建工具,項目打包部署前的壓縮合并,節(jié)省時間,提高開發(fā)效率。
3. Webpack
Webpack 是當(dāng)下最熱門的前端資源模塊化管理和打包工具。它可以將許多松散的模塊按照依賴和規(guī)則打包成符合生產(chǎn)環(huán)境部署的前端資源。
4. Babel
JavaScript代碼編譯器,可以讓ES6及以上語法轉(zhuǎn)換成瀏覽器支持的語法,一般會在框架的腳手架中自行配置。
5. 代碼質(zhì)量
瀏覽器與HTTP
性能優(yōu)化
SEO
博客系列
1. 個人
現(xiàn)在是一個信息爆炸的時代,網(wǎng)上有很多優(yōu)秀的博客文章,每個人的精力都是有限的,不可能關(guān)注到所有的博客,每個人關(guān)注點可能不太一樣,所以關(guān)注的個人博客也會不同,這些推薦幾個我比較常看的幾個高質(zhì)量博客。而且是持續(xù)更新的。
2. 團隊
項目資源
常用工具
最后
以上是我這兩年多一路走來收藏的一些資料,整理這份資料也花了我好幾天的時間,希望能夠在自學(xué)的道路上幫到你。
再次聲明,我并不是什么大神,我自認(rèn)為技術(shù)也沒有到達這個層級,但是我會一直堅持學(xué)下去,另外一定不要誤會這里面的知識我全部都會,這些都是我學(xué)習(xí)的一些資料想整理出來,免去小白的一些不知道如何查閱資料。
這里的資源可能并不適合每一個人,你也不一定全部都需要,只需要挑選自己想要的部分就行,任何事情并不是越多越好。
作者:六小登登,個人公眾號:六小登登(ID:liuxiaodengdeng)。目前在某創(chuàng)業(yè)公司任職前端開發(fā)工作,近 3 年前端開發(fā)經(jīng)驗,愛技術(shù)、愛寫作、愛分享。
聲明:本文為作者投稿,版權(quán)歸其個人所有。
一個非專業(yè)人士看3D圖紙有多難?比如打開一個30M的3D圖紙:
但是如果換做用網(wǎng)頁看三維,不管你手機多老舊,不論你電腦配置多平常,也不論你是否專業(yè)人員,一個鏈接或者一個超鏈接、二維碼就能解決這些問題。選擇SView 網(wǎng)頁端,讓3D圖紙躍然網(wǎng)上,以一個鏈接的形式,自由適配你的手機和電腦,會有這幾種形式:
鏈接
https://sview.sv3d.cn/model/preview/0a7e37de-1c33-4b32-aed8-72c36584799b
超鏈接
點擊圖片跳轉(zhuǎn)預(yù)覽
二維碼
長按識別二維碼
網(wǎng)站嵌入
<script src="https://lf6-cdn-tos.bytescm.com/obj/cdn-static-resource/tt_player/tt.player.js?v=20160723"></script>
為什么3D圖紙在SView網(wǎng)站上會這么流暢呢?
因為SView在生成3D圖紙的鏈接之前會先對3D圖紙做高性能輕量化轉(zhuǎn)換,讓圖紙的大小能夠適配手機,以H5的形式在網(wǎng)頁上瀏覽。這種形式擴大了圖紙的復(fù)用性以及應(yīng)用范圍的廣度,出現(xiàn)了多樣化的應(yīng)用場景。比如:
在電商平臺、產(chǎn)品官網(wǎng),用產(chǎn)品的3D圖紙代替?zhèn)鹘y(tǒng)的文字、圖片、視頻、動畫介紹講解。通過網(wǎng)頁嵌入或者超鏈接跳轉(zhuǎn)到產(chǎn)品的三維結(jié)構(gòu)圖,讓瀏覽者更清晰更全面了解產(chǎn)品的特質(zhì)、結(jié)構(gòu)、屬性。用科技感十足的宣傳手段,提升客戶對企業(yè)實力的認(rèn)可。
可以擺脫圖文表達在直觀性和互動性上的不足,銷售人員在拜訪客戶時直接打開手機或者網(wǎng)頁,就能立體生動的向客戶進行產(chǎn)品介紹,讓銷售工作事半功倍;介紹產(chǎn)品只提供二維碼、鏈接就可以讓客戶全面了解產(chǎn)品。
3D產(chǎn)品手冊,操作簡單,使用方便,360°全三維展示、不同視圖展示、結(jié)構(gòu)爆炸圖展示、裝配樹展示、零部件拖拽和旋轉(zhuǎn)。
把傳統(tǒng)機械制圖教材中的平面三維教學(xué)內(nèi)容,用SView展示出來。拿起移動設(shè)備掃一掃,在移動設(shè)備中呈現(xiàn)三維圖紙的3D立體化效果。學(xué)生可對設(shè)備中的3D模型做剖切、放大、縮小、爆炸、裝配等等自由操作,全方位立體化識得每一個模型結(jié)構(gòu)和特質(zhì)。
SView利用HTML5技術(shù)及三維大數(shù)模的輕量化技術(shù),實現(xiàn)在網(wǎng)頁端的三維模型預(yù)覽,同時適配手機及網(wǎng)頁瀏覽,想了解更多SView三維產(chǎn)品知識或者想應(yīng)用到更廣泛的場景中,請聯(lián)系我們。
更多SView產(chǎn)品體驗下載地址:
https://sview.sv3d.cn/tool
SView產(chǎn)品激活地址:
https://service.sv3d.cn/web/licence/applypage
使用由Angular,React,Vue等應(yīng)用程序框架構(gòu)建的客戶端應(yīng)用程序時,您總是會處理HTML5客戶端路由,它將完全在瀏覽器中處理到頁面和組件的客戶端路由。幾乎完全在瀏覽器中...
HTML5客戶端路由在客戶端上工作的很好,但是當(dāng)深入鏈接到一個站點或在瀏覽器中按刷新時,客戶端路由有一個惡習(xí),變成服務(wù)器HTTP請求。請求可能未配置服務(wù)器的路由。
在這篇文章中,我將討論如何使ASP.NET Core(或間接ASP.NET應(yīng)用程序)通過有效地將客戶端應(yīng)用程序重新連接到其路由來處理這些“假”請求。
Html 5客戶端路由?
如果您不知道HTML5客戶端路由是什么,請快速回顧一下。
客戶端框架實現(xiàn)他們自己的客戶端路由機制,以便他們可以 - 就像服務(wù)器應(yīng)用程序 - 在頁面或組件之間進行導(dǎo)航。
Angular支持幾種路由類型:
哈希路線(http:// localhost:4200 /#!/ albums或http:// localhost:4200 /#/ albums)
HTML 5路線(http:// localhost:4200 / albums)
#!/
哈希邦德路線
前者是一種較早的方法,它直接與HTTP語義一起工作,指定任何具有a的URL #
在客戶端被觸發(fā)并跳轉(zhuǎn)到頁面內(nèi)的“本地”URL。框架可以攔截導(dǎo)航并檢查跟隨的URL內(nèi)容#
以確定路線。散列爆炸#!\
用于區(qū)分應(yīng)用程序URL和普通#
錨鏈接。
散列爆炸路線的好處是,他們只是工作。沒有服務(wù)器端出血的路線,如果您書簽或刷新客戶端頁面,它只是如預(yù)期的那樣工作,因為散列邏輯是作為瀏覽器中本地URL解析的一部分執(zhí)行的。很簡單,對吧?它只是工作。
但缺點是,如果您必須手動輸入網(wǎng)址,則這些網(wǎng)址非常難看且不直觀。對于散列爆炸路線來說,這并不是一個很好的論據(jù),但是不管它們是否對HTML5路由不利。
哈希在Angular中的Bang路由
Angular使用默認(rèn)的HTML5客戶端路由,但它是一個簡單的開關(guān)來啟用Hashbang路由,而不是HTML5路由::
// in app.module.tsproviders : [ .. // make sure you use this for Hash Urls rather than HTML 5 routing { provide: LocationStrategy, useClass: HashLocationStrategy },]
只要您routerLink
在HTML模板中使用鏈接網(wǎng)址,并router.navigate()
在代碼鏈接中使用,Angular交換機就會自動在兩種模式之間進行切換。
在HTML中使用<a routerLink="/albums" />
鏈接
在代碼中使用: router.navigate(["/album",album.id])
HTML5路由
HTML5路由使用更復(fù)雜的方法 - 它使用HTML5的Pushstate API來控制客戶端的路由并管理地址欄顯示。
這種方法的優(yōu)點是,使用HTML5 API相對容易操作,并且使用標(biāo)準(zhǔn)的無延伸路由約定,使用Web應(yīng)用程序和API時,URL更加簡潔,易于控制。
但是HTML5路由需要服務(wù)器的明確支持來正確理解哪些路由是服務(wù)器路由,哪些是客戶路由。
沒有服務(wù)器處理的HTML5路由問題
問題在于HTML5客戶端路由與服務(wù)器路由無法區(qū)分。
http://localhost:4200/albums
可以很容易地將客戶端URL作為服務(wù)器端URL。在完全在客戶端上導(dǎo)航時,HTML5路線工作正常 - 應(yīng)用程序可以攔截導(dǎo)航并在激活特定路線時路由到相應(yīng)的客戶端頁面。
如果您使用深層鏈接導(dǎo)航到客戶端驅(qū)動的應(yīng)用程序,然后您將該頁面書簽為書簽,然后使用該URL導(dǎo)航回到該頁面,或者刷新當(dāng)前活動頁面,則會彈出問題。在這兩種情況下,當(dāng)瀏覽器請求路由時,客戶端應(yīng)用程序不運行,因此瀏覽器向服務(wù)器請求路由URL。但是,默認(rèn)情況下不設(shè)置處理說/albums
路線,所以你會得到一個錯誤。
如果您在ASP.NET Core應(yīng)用程序中沒有對HTML5路由設(shè)置進行任何特殊處理,您將在應(yīng)用程序中打開錯誤頁面,或者從Kestrel中選擇此默認(rèn)顯示:
圖1 - 未處理的客戶端路由產(chǎn)生服務(wù)器錯誤
修復(fù)服務(wù)器上的客戶端路由
那么你如何解決這個問題呢?
客戶端SPA應(yīng)用程序通常有一個或幾個啟動應(yīng)用程序的靜態(tài)頁面。對于一個典型的Angular應(yīng)用程序,該頁面是index.html
啟動應(yīng)用程序并啟動客戶端路由。大多數(shù)框架都足夠聰明,可以在啟動時檢查當(dāng)前路由,并移至首次訪問請求的路由。
如果客戶端路由從書簽,鏈接或完全刷新被觸發(fā)到服務(wù)器,則需要提供index.html
并保持原始URL不變。
然后,客戶端應(yīng)用程序?qū)⒆孕幸龑?dǎo),并且內(nèi)部路由啟動,以希望將您甩回書簽/刷新位置。
從服務(wù)器提供Index.html
為了這個工作,你需要確保服務(wù)器只提供服務(wù)器負(fù)責(zé)的內(nèi)容。
有幾種方法可以做到這一點:
主機服務(wù)器URL重寫
處理ASP.NET Core應(yīng)用程序中的客戶端路由
主機Web服務(wù)器上的URL重寫
如果您在主流Web服務(wù)器上運行ASP.NET Core(或ASP.NET)應(yīng)用程序,最簡單且最有效的解決方案是重寫客戶端URL并為index.html
給定的URL 提供內(nèi)容。
在IIS上,您可以使用IIS重寫模塊來執(zhí)行此操作。我最近在一篇博文中更詳細(xì)地介紹了這一點:
ASP.NET核心應(yīng)用程序的IIS重寫規(guī)則
但是這里是相關(guān)的IIS重寫規(guī)則:
<rewrite> <rules> <!-- Make sure you have a <base href="/" /> tag to fix the root path or all relative links will break on rewrite --> <rule name="AngularJS-Html5-Routes" stopProcessing="true"> <match url=".*" /> <conditions logicalGrouping="MatchAll"> <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" /> <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" /> <add input="{REQUEST_URI}" pattern="api/" negate="true" /> </conditions> <action type="Rewrite" url="wwwroot/index.html" /> </rule> </rules></rewrite>
您可以從以下任何位置安裝UrlRewrite模塊:
Microsoft下載網(wǎng)站
choco install urlrewrite
Web平臺安裝程序
如果你在Linux上運行Docker和nginX或者Apache,那么類似的Rewrite選項就可以在那里使用。
讓ASP.NET Core處理客戶端路由
如前所述,我通常使用像IIS或nginX這樣的前端Web服務(wù)器來處理重定向,但是通常在測試或內(nèi)部應(yīng)用程序時,只需要Kestrel直接為應(yīng)用程序提供服務(wù)即可。如果您直接讓Kestrel處理HTTP流量,那么您需要在ASP.NET Core代碼中處理客戶端路由。
捕獲所有app.Run()
處理程序
有很多方法可用,但是我發(fā)現(xiàn)了在Startup
類的Configure()
方法中使用一個非常簡單的后備處理程序來處理客戶端路由的最簡單的方法:
// set up whatever routes you use with UseMvc()// you may not need to set up any routes here// if you only use attribute routes!app.UseMvc(routes =>{ routes.MapRoute( name: "default", template: "{controller=Home}/{action=Index}/{id?}");});//handle client side routesapp.Run( async (context) =>{ context.Response.ContentType = "text/html"; await context.Response.SendFileAsync(Path.Combine(env.WebRootPath,"index.html"));});
關(guān)鍵是app.Run()
位于路由后的管道末端的中間件處理程序。如果服務(wù)器端路由不能找到匹配的路由,這個通用處理程序就會啟動。
上面的代碼是你可以做的最簡單的事情,只是把內(nèi)容發(fā)送index.html
到客戶端。如果您有多個靜態(tài)頁面和SPA筒倉,您可以在其中添加額外的邏輯來嘗試確定需要加載哪個頁面。
請注意,內(nèi)容不會重定向到,而是作為內(nèi)嵌流發(fā)送到現(xiàn)有的URL請求,以便用戶請求的URL保持不變。這確保了當(dāng)用戶請求http://localhost:4200/albums
你回到那個客戶端頁面而不是index.html
。
捕獲所有路由處理程序
另一種方法是在路由定義中使用最后定義的全部捕獲的 MVC路由處理程序。這基本上拿起你的MVC路由配置無法處理的任何URL,然后路由到你指定的路線。
使用catch-all處理程序設(shè)置您的MVC路線,將此代碼放在您的Startup
類的Configure()
方法中:
app.UseMvc(routes =>{ // default routes plus any other custom routes routes.MapRoute( name: "default", template: "{controller=Home}/{action=Index}/{id?}"); // Catch all Route - catches anything not caught be other routes routes.MapRoute( name: "catch-all", template: "{*url}", defaults: new {controller = "AlbumViewerApi", action = "RedirectIndex"} );});
然后執(zhí)行完全相同的事情中間件處理程序使用:index.html
使用以下代碼將內(nèi)容流式傳輸?shù)娇蛻舳耍?/p>
// we need hosting environment for base pathpublic IHostingEnvironment HostingEnv { get; }public AlbumViewerApiController(IHostingEnvironment env){ HostingEnv = env;}[HttpGet]public IActionResult RedirectIndex(){ return new PhysicalFileResult( Path.Combine(HostingEnv.WebRootPath,"index.html"), new MediaTypeHeaderValue("text/html") );}
Catch-All Route不使用屬性路由
確保您為回退路線指定的路線不具有分配給它的屬性路線。當(dāng)我昨天檢查出來的時候,我無法得到一條全面的路線,直到我
[Route("api/RedirectIndex")]
從控制器的操作中移除 了這個全部工作。
SpaServices
SpaServices提供了另一個選項,routes.MapSpaFallbackRoute()
盡管我自己也沒有嘗試過,但是如果您已經(jīng)在ASP.NET Core應(yīng)用程序中使用了Spa服務(wù),那么這可能是一個簡單的方法來實現(xiàn)這個功能,包括潛在的支持服務(wù)器預(yù)渲染。
概要
HTML5路由為客戶端應(yīng)用程序提供了干凈的URL,但它的價格必須有服務(wù)器支持才能使其工作。使用主機Web服務(wù)器中的重寫規(guī)則或直接在Kestrel的中間件管道或自定義路由處理程序中進行設(shè)置并不困難,但是您必須確保將此功能顯式添加到您創(chuàng)建的每個ASP.NET應(yīng)用程序中。
盡管舊的Hash Bang路線看起來不那么干凈,但它們工作正常,不需要任何服務(wù)器端支持。對于需要支持古代瀏覽器的非公眾應(yīng)用程序或應(yīng)用程序,在沒有服務(wù)器支持的情況下,散列邦線路仍然是提供路由的可行方式。
最后,如果您正在使用完整的Web服務(wù)器,UrlRewriting是處理非ASP.NET內(nèi)核后端直接處理的非API內(nèi)容的最干凈和最有效的方式。
選擇是好的,你有幾個選擇提供方便,干凈的網(wǎng)址或簡單的只是把它放在功能。你的選擇...
*請認(rèn)真填寫需求信息,我們會在24小時內(nèi)與您取得聯(lián)系。