整合營銷服務商

          電腦端+手機端+微信端=數據同步管理

          免費咨詢熱線:

          Pelican 入門:一個 Python 靜態網站生

          Pelican 入門:一個 Python 靜態網站生成器

          elican 是那些想要自我托管簡單網站或博客的 Python 用戶的絕佳選擇。

          如果你想創建一個自定義網站或博客,有很多選擇。許多提供商可以托管你的網站并為你完成大部分工作。(WordPress 是一個非常受歡迎的選項。)但是使用托管方式,你會失去一些靈活性。作為一名軟件開發人員,我更喜歡管理我自己的服務器,并在我的網站如何運行方面保持更多的自由。

          然而,管理 Web 服務器需要大量的工作。安裝它并獲得一個簡單的應用程序來提供內容是非常容易的。但是,維護安全補丁和更新是非常耗時得。如果你只想提供靜態網頁,那么擁有一個 Web 服務器和一系列應用程序可能會得不償失。手動創建 HTML 頁面也不是一個好選擇。

          這是靜態網站生成器的用武之地。這些應用程序使用模板來創建所需的靜態頁面,并將它們與關聯的元數據交叉鏈接。(例如,所有顯示的頁面都帶有公共標簽或關鍵詞。)靜態網站生成器可以幫助你使用導航區域、頁眉和頁腳等元素創建一個具有公共外觀的網站。

          我使用 Pyhton 已經很多年了,所以,當我第一次開始尋找生成靜態 HTML 頁面的東西時,我想要用 Python 編寫的東西。主要原因是我經常想要了解應用程序如何工作的內部細節,而使用一種我已經了解的語言使這一點更容易。(如果這對你不重要或者你不使用 Python,那么還有一些其他很棒的 靜態網站生成器 ,它們使用 Ruby、JavaScript 和其它語言。)

          我決定試試 Pelican 。它是一個用 Python 編寫的常用靜態網站生成器。它支持 reStructuredText (LCTT 譯注:這是一種用于文本數據的文件格式,主要用于 Python 社區的技術文檔),并且也支持 Markdown ,這需要通過安裝必需的包來完成。所有任務都是通過命令行界面(CLI)工具執行的,這使得熟悉命令行的任何人都可以輕松完成。它簡單的 quickstart CLI 工具使得創建一個網站非常容易。

          在本文中,我將介紹如何安裝 Pelican 4,添加一篇文章以及更改默認主題。(注意:我是在 MacOS 上開發的,使用其它 Unix/Linux 實驗結果都將相同,但我沒有 Windows 主機可以測試。)

          安裝和配置

          第一步是創建一個 虛擬環境 ,在虛擬環境中安裝 Pelican。

          $ mkdir test-site

          $ cd test-site

          $ python3 -m venv venv

          $ ./venv/bin/pip install --upgrade pip

          ...

          Successfully installed pip-18.1

          $ ./venv/bin/pip install pelican

          Collecting pelican

          ...

          Successfully installed MarkupSafe-1.1.0 blinker-1.4 docutils-0.14 feedgenerator-1.9 jinja2-2.10 pelican-4.0.1 pygments-2.3.1 python-dateutil-2.7.5 pytz-2018.7 six-1.12.0 unidecode-1.0.23

          Pelican 的 quickstart CLI 工具將創建基本布局和一些文件來幫助你開始,運行 pelican-quickstart 命令。為了簡單起見,我輸入了網站標題和作者的名字,并對 URL 前綴和文章分頁選擇了 “N”。(對于其它選項,我使用了默認值。)稍后在配置文件中更改這些設置非常容易。

          $ ./venv/bin/pelicanquickstart

          Welcome to pelicanquickstart v4.0.1.

          This script will help you create a new Pelican-based website.

          Please answer the following questions so this script can generate the files needed by Pelican.

          > Where do you want to create your new web site? [.]

          > What will be the title of this web site? My Test Blog

          > Who will be the author of this web site? Craig

          > What will be the default language of this web site? [en]

          > Do you want to specify a URL prefix? e.g., https://example.com (Y/n) n

          > Do you want to enable article pagination? (Y/n) n

          > What is your time zone? [Europe/Paris]

          > Do you want to generate a tasks.py/Makefile to automate generation and publishing? (Y/n)

          > Do you want to upload your website using FTP? (y/N)

          > Do you want to upload your website using SSH? (y/N)

          > Do you want to upload your website using Dropbox? (y/N)

          > Do you want to upload your website using S3? (y/N)

          > Do you want to upload your website using Rackspace Cloud Files? (y/N)

          > Do you want to upload your website using GitHub Pages? (y/N)

          Done. Your new project is available at /Users/craig/tmp/pelican/test-site

          你需要啟動的所有文件都準備好了。

          quickstart 默認為歐洲/巴黎時區,所以在繼續之前更改一下。在你喜歡的文本編輯器中打開 pelicanconf.py 文件,尋找 TIMEZONE 變量。

          TIMEZONE='Europe/Paris'

          將其改為 UTC。

          TIMEZONE='UTC'

          要更新公共設置,在 pelicanconf.py 中查找 SOCIAL 變量。

          SOCIAL=(('You can add links in your config file', '#'),

          ('Another social link', '#'),)

          我將添加一個我的 Twitter 賬戶鏈接。

          SOCIAL=(('Twitter (#craigs55)', 'https://twitter.com/craigs55'),)

          注意末尾的逗號,它很重要。這個逗號將幫助 Python 識別變量實際上是一個集合。確保你沒有刪除這個逗號。

          現在你已經有了網站的基本知識。quickstart 創建了一個包含許多目標的 Makefile。將 devserver 傳給 make 命令將在你的計算機上啟動一個開發服務器,以便你可以預覽所有內容。Makefile 中使用的 CLI 命令假定放在 PATH 搜索路徑中,因此你需要首先激活該虛擬環境。

          $ source ./venv/bin/activate

          $ make devserver

          pelican -lr /Users/craig/tmp/pelican/test-site/content o

          /Users/craig/tmp/pelican/test-site/output -s /Users/craig/tmp/pelican/test-site/pelicanconf.py

          -> Modified: theme, settings. regenerating...

          WARNING: No valid files found in content for the active readers:

          | BaseReader (static)

          | HTMLReader (htm, html)

          | RstReader (rst)

          Done: Processed 0 articles, 0 drafts, 0 pages, 0 hidden pages and 0 draft pages in 0.18 seconds.

          在你最喜歡的瀏覽器中打開 http://localhost:8000 來查看你的簡單測試博客。



          你可以在右側看到 Twitter 鏈接,左側有 Pelican、Python 和 Jinja 的一些鏈接。(Jinja 是 Pelican 可以使用的一種很棒的模板語言。你可以在 Jinja 的文檔 中了解更多相關信息。)

          添加內容

          現在你又了一個基本的網站,試著添加一些內容。首先,將名為 welcome.rst 的文件添加到網站的 content 目錄中。在你喜歡的文本編輯器中,使用以下文本創建一個文件:

          $ pwd

          /Users/craig/tmp/pelican/test-site

          $ cat content/welcome.rst

          Welcome to my blog!

          ###################

          :date: 20181216 08:30

          :tags: welcome

          :category: Intro

          :slug: welcome

          :author: Craig

          :summary: Welcome document

          Welcome to my blog.

          This is a short page just to show how to put up a static page.

          Pelican 會自動解析元數據行,包括日期、標簽等。

          編寫完文件后,開發服務器應該輸出以下內容:

          -> Modified: content. regenerating...

          Done: Processed 1 article, 0 drafts, 0 pages, 0 hidden pages and 0 draft pages in 0.10 seconds.

          在瀏覽器中刷新你的測試網站來查看更改。



          元數據(例如日期和標簽)會自動添加到頁面中。此外,Pelican 會自動檢測到 intro 欄目,并將該部分添加到頂部導航中。

          更改主題

          使用像 Pelican 這樣流行的開源軟件的好處之一是,非常多的用戶會做出更改并將其貢獻給項目。許多都是以主題形式貢獻的。

          網站的主題會設置顏色、布局選項等。嘗試一個新主題非常容易,你可以在 Pelican 主題 中預覽其中的許多內容。

          首先,克隆 GitHub 倉庫:

          $ cd ..

          $ git clone --recursive https://github.com/getpelican/pelicanthemes

          Cloning into 'pelicanthemes'...

          我喜歡藍色,那么試試 blueidea 。

          編輯 pelicanconf.py,添加以下行:

          THEME='/Users/craig/tmp/pelican/pelican-themes/blueidea/'

          開發服務器將重新生成你的輸出。在瀏覽器中刷新網頁來查看新主題。



          主題控制布局的方方面面。例如,在默認主題中,你可以看到文章旁邊帶有元標記的欄目(Intro),但這個欄目并未顯示在 blueidea 主題中。

          其他考慮因素

          本文是對 Pelican 的快速介紹,所以我并沒有涉及一些重要的主題。

          首先,我對遷移到靜態站點猶豫不決的一個原因是它無法對文章評論。幸運的是,有一些第三方服務商將為你提供評論功能。我目前正在關注的是 Disqus 。

          接下來,上面的所有內容都是在我的本地機器上完成的。如果我希望其他人查看我的網站,我將不得不將預先生成的 HTML 文件上傳到某個地方。如果你查看 pelican-quickstart 輸出,你將看到使用 FTP、 SSH、S3 甚至 GitHub 頁面的選項,每個選項都有其優點和缺點。但是,如果我必須選擇一個,那么我可能會選擇發布到 GitHub 頁面。

          Pelican 還有許多其他功能,我每天都在學習它。如果你想自托管一個網站或博客,內容簡單并且是靜態內容,同時你想使用 Python,那么 Pelican 是一個很好的選擇。它有一個活躍的用戶社區,可以修復 bug,添加特性,而且還會創建新的和有趣的主題。試試看吧!


          via: https://opensource.com/article/19/1/getting-started-pelican

          作者: Craig Sebenik 選題: lujun9972 譯者: MjSeven 校對: wxy

          本文由 LCTT 原創編譯, Linux中國 榮譽推出

          點擊“了解更多”可訪問文內鏈接

          網頁展現的更快,官方說法叫做首屏繪制,First Paint 或者簡稱 FP,直白的說法叫做白屏時間,就是從輸入 URL 到真的看到內容(不必可交互,那個叫 TTI, Time to Interactive)之間經歷的時間。當然這個時間越短越好。

          但這里要注意,和首屏相關的除了 FP 還有兩個指標,分別稱為 FCP (First Contentful Paint,頁面有效內容的繪制) 和 FMP (First Meaningful Paint,頁面有意義的內容繪制)。雖然這幾個概念可能會讓我們繞暈,但我們只需要了解一點:首屏時間 FP 并不要求內容是真實的,有效的,有意義的,可交互的。換言之,隨便 給用戶看點啥都行。


          這就是本文標題的玄機了:“看起來”。是的,只是看起來更快,實際上還是那樣。所以本文并不討論性能優化,討論的是一個投機取巧的小伎倆,但的確能夠實實在在的提升體驗。打個比方,性能優化是修煉內功,提升你本身的各項機能;而本文接下來要討論的是一些招式,能讓你在第一時間就唬住對手。

          這所謂的招式就是我接下來要談的內容,學名骨架屏,也叫 Skeleton。你可能沒聽過這個名字,但你不可能沒見過它。

          骨架屏長什么樣


          這種應該是最常見的形式,使用各種形狀的灰色矩形來模擬圖片和文字。有些 APP 也會使用圓形,但重點都是和實際內容結構近似,不能差距太大。

          如果追求效果,還可以在色塊表面添加動畫(如波紋),顯示出一種動態的效果,算是致敬 Loading 了。


          在圖片居多的站點,這將會是一個很好的體驗,因為圖片通常加載較慢。如上圖演示中的占位圖片采用了低像素的圖片,即大體配色和變化是和實際內容一致的。

          如果無法生成這樣的低像素圖片,稍微降級的方案是通過算法獲取圖片的主體顏色,使用純色塊占位。

          再退一級,還可以使用全站相同的站位圖片,或者直接一個統一顏色的色塊。雖說效果肯定不如上面兩種,但也聊勝于無。

          骨架屏完全是自定義的,想做成什么樣全憑你的想象。你想做圓形的,三角形的,立體的都可以,但“占位”決定了它的特性:它不能太復雜,必須第一時間,最快展現出來。

          骨架屏有哪些優勢

          大體來說,骨架屏的優勢在于:

          1、在頁面加載初期預先渲染內容,提升感官上的體驗。

          2、一般情況骨架屏和實際內容的結構是類似的,因此之后的切換不會過于突兀。這點和傳統的 Loading 動圖不同,可以認為是其升級版。

          3、只需要簡單的 CSS 支持 (涉及圖片懶加載可能還需要 JS ),不要求 HTTPS 協議,沒有額外的學習和維護成本。

          4、如果頁面采用組件化開發,每個組件可以根據自身狀態定義自身的骨架屏及其切換時機,同時維持了組件之間的獨立性。

          骨架屏能用在哪里

          現在的 WEB 站點,大致有兩種渲染模式:

          前端渲染

          由于最近幾年 Angular/React/Vue 的相繼推出和流行,前端渲染開始占據主導。這種模式的應用也叫單頁應用(SPA, Single Page Application)。

          前端渲染的模式是服務器(多為靜態服務器)返回一個固定的 HTML。通常這個 HTML 包含一個空的容器節點,沒有其他內容。之后內部包含的 JS 包含路由管理,頁面渲染,頁面切換,綁定事件等等邏輯,所以稱之為前端渲染。

          因為前端要管理的事情很多,所以 JS 通常很大很復雜,執行起來也要花較多的時間。在 JS 渲染出實際內容之前,骨架屏就是一個很好的替補隊員

          后端渲染

          在這波前端渲染流行之前,早期的傳統網站采用的模式叫做后端渲染,即服務器直接返回網站的 HTML 頁面,已經包含首頁的全部(或絕大部分) DOM 元素。其中包含的 JS 的作用大多是綁定事件,定義用戶交互后的行為等。少量會額外添加/修改一些 DOM,但無礙大局。

          此外,前端渲染的模式存在 SEO 不友好的問題,因為它返回的 HTML 是一個空的容器。如果搜索引擎沒有執行 JS 的能力(稱為 Deep Render),那它就不知道你的站點究竟是什么內容,自然也就無法把站點排到搜索結果中去。這對于絕大部分站點來說是不可接受的,于是前端框架又相繼推出了服務端渲染(簡稱 SSR, Server Side Rendering)模式。這個模式和傳統網站很接近,在于返回的 HTML 也是包含所有的 DOM,而非前端渲染。而前端 JS 除了綁定事件之外,還會多做一個事情叫做“激活”(hydration),這里就不再贅述了。

          不論是傳統模式還是 SSR,只要是后端渲染,就不需要骨架屏。因為頁面的內容直接存在于 HTML,所以并沒有骨架屏出場的余地。

          骨架屏怎么用

          討論了一波背景,我們來看如何使用。首先先無視具體的實現細節,先看思路。

          實現思路

          大體分為幾個步驟:

          • 往本應為空的容器節點內部注入骨架屏的 HTML。
          • 骨架屏為了盡快展現,要求快速和簡單,所以骨架屏多數使用靜態的圖片。而且把圖片編譯成 base64 編碼格式可以節省網絡請求,使得骨架屏更快展現,更加有效。


          <html>
           <head>
           <style>
           .skeleton-wrapper {
           // styles
           }
           </style>
           <!-- 聲明 meta 或者引入其他 CSS -->
           </head>
           <body>
           <div id="app">
           <div class="skeleton-wrapper">
           <img src="data:image/svg+xml;base64,XXXXXX">
           </div>
           </div>
           <!-- 引用 JS -->
           </body>
          </html>
          


          • 在執行 JS 開始真正內容的渲染之前,清空骨架屏 HTML
          • 以 Vue 為例,即在 mount 之前清空內容即可。


          let app=new Vue({...})
          let container=document.querySelector('#app')
          if (container) {
           container.innerHTML=''
          }
          app.$mount(container)
          


          僅此兩步,并不牽涉多么復雜的機制和高端的 API,因此非常容易應用,趕快用起來!

          示例

          我編寫了一個示例,用于快速展現骨架屏的效果,代碼在此。

          • index.html
          • 默認包含了骨架屏,并且內聯了樣式(以 <style> 標簽添加在頭部)。
          • render.js
          • 它負責創建 DOM 元素并添加到 <body> 上,渲染頁面實際的內容,用來模擬常見的前端渲染模式。
          • index.css
          • 頁面實際內容的樣式表,不包含骨架屏的樣式。


          代碼的三個文件各司其職,配合上面的實現思路,應該還是很好理解的。可以在 這里 查看效果。

          因為這個示例的邏輯太過簡單,而實際的前端渲染框架復雜得多,包含的功能也不單純是渲染,還有狀態管理,路由管理,虛擬 DOM 等等,所以文件大小和執行時間都更大更長。我們在查看例子的時候,把網絡調成 "Fast 3G" 或者 "Slow 3G" 能夠稍微真實一些。

          但匪夷所思的是,對著這個地址刷新試幾次,我也基本看不到骨架屏(骨架屏的內容是一個居中的藍色方形圖片,外加一條白色橫線反復側滑的高亮動畫)。是我們的實現思路有問題嗎?

          瀏覽器的奧秘:減少重排

          為了排除肉眼的遺漏和干擾,我們用 Chrome Dev Tools 的 Performance 工具來記錄剛才發生了什么,截圖如下:(截圖時的網絡設置為 "Fast 3G")


          我們可以很明顯地看到 3 個時間點:

          1、HTML 加載完成了。瀏覽器在解析 HTML 的同時,發現了它需要引用的 2 個外部資源 index.js 和 index.css,于是發送網絡請求去獲取。

          2、獲取成功后,執行 JS 并注冊 CSS 的規則。

          3、JS 一執行,很自然的渲染出了實際的內容,并應用了樣式規則(隨機顏色的橫條)。

          我們的骨架屏呢?按照預想,骨架屏應該出現在 1 和 2 之間,也就是在獲取 JS 和 CSS 的同時,就應該渲染骨架屏了。這也是我們當時把骨架屏的 HTML 注入到 index.html, 還把 CSS 從 index.css 中分離出來的良苦用心,然而瀏覽器并不買賬。

          這其實和瀏覽器的渲染順序有關。

          相信大家都整理過行李箱。我們在整理行李箱時,會根據每個行李的大小合理安排,大的和小的配合,填滿一層再放上面一層。現在突然有人跑來跟你說,你的電腦不用帶了,你要多帶兩件衣服,你不能帶那么多瓶礦泉水。除了想打他之外,為了重新整理行李箱,必然需要把整理好的行李拿出來再重新放。在瀏覽器中這個過程叫做重排 (reflow),而那個餿主意就是新加載的 CSS。顯而易見,重排的開銷是很大的。

          熟能生巧,箱子理多了,就能想出解決辦法。既然每個 CSS 文件加載都可能觸發重繪,那我能不能等所有 CSS 加載完了一起渲染呢?正是基于這一點,瀏覽器會等 HTML 中所有的 CSS 都加載完,注冊完,一起應用樣式,力求一次排列完成工作,不要反復重排??雌饋頌g覽器的設計者經常出差,因為這是一個很正確的優化思路,但應用在骨架屏上就出了問題。

          我們為了盡早展現骨架屏,把骨架屏的樣式從 index.css 分離出來。但瀏覽器不知道,它以為骨架屏的 HTML 還依賴 index.css,所以必須等它加載完。而它加載完之后,render.js 也差不多加載完開始執行了,于是骨架屏的 HTML 又被替換了,自然就看不到了。而且在等待 JS, CSS 加載的時候依然是個白屏,骨架屏的效果大打折扣。

          所以我們要做的是告訴瀏覽器,你放心大膽的先畫骨架屏,它和后面的 index.css 是無關的。那怎么告訴它呢?

          告訴瀏覽器先渲染骨架屏

          我們在引用 CSS 時,會使用 <link rel="stylesheet" href="xxxx> 這樣的語法。但實際上,瀏覽器還提供了其他一些機制確保(后續)頁面的性能,我們稱之為 preload,中文叫預加載。具體來說,使用 <link rel="preload" href="xxxx">,提前把后續要使用的資源先聲明一下。在瀏覽器空閑的時候會提前加載并放入緩存。之后再使用就可以節省一個網絡請求。

          這看似無關的技術,在這里將起到很大的作用,因為 預加載的資源是不會影響當前頁面的。

          我們可以通過這種方式,告訴瀏覽器:先不要管 index.css,直接畫骨架屏。之后 index.css加載回來之后,再應用這個樣式。具體來說代碼如下:

          <link rel="preload" href="index.css" as="style" onload="this.rel='stylesheet'">
          


          方法的核心是通過改變 rel 可以讓瀏覽器重新界定 <link> 標簽的角色,從預加載變成當頁樣式。(另外也有文章采用修改 media 的方法,但瀏覽器支持度較低,這里不作展開了。我把文章列在最后了)這樣的話,瀏覽器在 CSS 尚未獲取完成時,會先渲染骨架屏(因為此時的 CSS 還是 preload,也就是后續使用的,并不妨礙當前頁面)。而當 CSS 加載完成并修改了自己的 rel之后,瀏覽器重新應用樣式,目的達成。

          不得不考慮的注意點

          事實上,并不是把 rel="stylesheet" 改成 rel="preload" 就完事兒了。在真正應用到生產環境之前,我們還有很多事情要考慮。

          兼容性考慮

          首先,在 <link> 內部我們使用了 onload,也就是使用了 JS。為了應對用戶的瀏覽器沒有開啟腳本功能的情況,我們需要添加一個 fallback。(不過這點對于單頁應用來說可能也無所謂,因為如果沒有腳本,那頁面實際內容也渲染不出來的)

          <noscript><link rel="stylesheet" href="index.css"></noscript>
          


          其次,rel="preload" 并不是沒有兼容性問題。對于不支持 preload 的瀏覽器,我們可以添加一些 polyfill 代碼(來使所有瀏覽器獲得一致的效果。

          <script>
          /*! loadCSS rel=preload polyfill. [c]2017 Filament Group, Inc. MIT License */
          (function(){ ... }());
          </script>
          


          polyfill 的壓縮代碼可以參見 Lavas 的 SPA 模板第 29 行。

          加載順序

          不同于傳統頁面,我們的實際 DOM 是通過 render.js 生成的。所以如果 JS 先于 CSS 執行,那將會發生跳動。(因為先渲染了實際內容卻沒有樣式,而后樣式加載,頁面出現很明顯的變化)所以這里我們需要嚴格控制 CSS 早于渲染。

          <link rel="preload" href="index.css" as="style" onload="this.rel='stylesheet';window.STYLE_READY=true;window.mountApp && window.mountApp()">
          


          JS 對外暴露一個 mountApp 方法用于渲染頁面(其實是模擬 Vue 的 mount)

          // render.js
          function mountApp() {
           // 方法內部就是把實際內容添加到 <body> 上面
          }
          // 本來直接調用方法完成渲染
          // mountApp()
          // 改成掛到 window 由 CSS 來調用
          window.mountApp=mountApp()
          // 如果 JS 晚于 CSS 加載完成,那直接執行渲染。
          if (window.STYLE_READY) {
           mountApp()
          }
          


          如果 CSS 更快加載完成,那么通過設置 window.STYLE_READY 允許 JS 加載完成后直接執行;而如果 JS 更快,則先不自己執行,而是把機會留給 CSS 的 onload。

          清空 onload

          loadCSS 的開發者提出,某些瀏覽器會在 rel 改變時重新出發 onload,導致后面的邏輯走了兩次。為了消除這個影響,我們再在 onload 里面添加一句 this.onload=null。

          最終的 CSS 引用方式

          <link rel="preload" href="index.css" as="style" onload="this.onload=null;this.rel='stylesheet';window.STYLE_READY=true;window.mountApp && window.mountApp()">
          <!-- 為了方便閱讀,折行重復一遍 -->
          <!-- this.onload=null -->
          <!-- this.rel='stylesheet' -->
          <!-- window.STYLE_READY=true -->
          <!-- window.mountApp && window.mountApp() -->
          

          修改后的效果

          修改后的代碼在 這里,訪問地址在 這里。(為了簡便,我省去了處理兼容性的代碼,即 <noscript> 和 preload polyfill)

          Performance 截圖如下:(依然采用了 "Fast 3G" 的網絡設置)


          這次在 render.js 和 index.css 還在加載的時候頁面已經呈現出骨架屏的內容,實際肉眼也可以觀測到。在截圖的情況下,骨架屏的展現大約持續了 300ms,占據整個網絡請求的大約一半時間。

          至于說為什么不是 HTML 加載完成立馬展現骨架屏,而是還要等大約 300ms 才展現,從圖上看是瀏覽器 ParseHTML 所花費的時間,可能在 Dev Tools 打開的情況下計算資源有限,不過可優化空間已經不大。(可能簡化骨架屏的結構能起一些作用吧)

          多骨架屏的支持

          一般來說一個站點的所有頁面不太可能是同一種展示類型。例如說首頁和內部頁面就展示風格而言會很有區別,另外例如列表頁和搜索頁比較接近(可能都有列表展示),但和詳情頁(可能是商品,服務,個人信息,博客文章等等)就會很不相同。但單頁應用的 index.html 只有一個,所有的變化都源自前端渲染框架在容器節點內部進行改變。所以直接將骨架屏注入到 index.html中會導致所有的頁面都用同一個骨架屏,那就很難達成“和實際內容結構類似”的目標了,骨架屏就退化為 Loading 了。

          為了要支持多種骨架屏,我們需要在 index.html 里面進行判斷邏輯(獨立于主體 JS 之外),具體來說:

          1、把所有種類的骨架屏的 HTML 和樣式全部寫入 index.html

          2、在 index.html 底下新增內聯的腳本 <script>,根據當前路由判斷應該展示哪一個骨架屏

          這樣會導致 index.html 體積變大一點,但整體感覺依然是收益大于付出,我認為是值得的。

          后記

          這個優化點最早由我的前同事 xiaop 同學 在開發 Lavas 的 SPA 模板中發現并完成的,Issue 記錄在此。我在他的基礎上,做了一個分離 Lavas 和 Vue 環境并且更直白的例子,讓截圖也盡可能易于理解,方便閱讀。在此非常感謝他的工作!

          另外骨架屏的編寫我全部采用的是純粹的手寫 HTML 和 CSS,不止展現邏輯,包括開發流程也是獨立于單頁應用其他常規頁面的。當然這可能給開發者帶來一點不便,所以這時候需要推出 xiaop 同學的利器:vue-skeleton-webpack-plugin https://github.com/lavas-project/vue-skeleton-webpack-plugin。它的作用是把骨架屏本身也當成一個 Vue 組件,配上單獨的路由規則來統一在 Vue 項目中的開發體驗,最后使用 webpack 在打包構建的時候加以區分并注入,對于使用 Vue + webpack 開發的同學來說可以一試。

          參考文章

          • 讓骨架屏更快渲染 https://zhuanlan.zhihu.com/p/34550387- xiaop 同學原作
          • Loading CSS without blocking render https://keithclark.co.uk/articles/loading-css-without-blocking-render/- 使用修改 media 的方式達成目的。
          • filamentgroup/loadCSS https://github.com/filamentgroup/loadCSS - 同樣使用修改 rel 的方式,并提供了 preload polyfill

          、跳轉的方式

          轉發: forward

          重定向: redirect

          2、轉發和重定向代碼怎么完成

          1、轉發
          //請求轉發到/b對應的Servlet
          request.getRequestDispatcher("/b").forward(request,response);
          
          2、重定向
          response.sendRedirect(request.getContextPath() + "/b");

          3、轉發和重定向的區別?

          相同點:都可以完成資源的跳轉

          不同點:

          轉發是request對象觸發的,服務器內部進行轉發

          重定向是response對象觸發的,要將重定向的路徑相應給瀏覽器

          轉發是一次請求,瀏覽器地址欄上地址不變

          重定向是兩次請求,瀏覽器地址欄上的地址發生變化

          重定向路徑需要加項目名(webapp跟路徑web目錄)

          轉發是在本項目內部完成資源的跳轉

          重定向可以完成跨app跳轉,例如可以跳轉到https://www.baidu.com

          4、什么時候采用轉發,什么時候采用重定向

          1、大部分情況下都使用重定向

          2、若想完成跨app跳轉,必須采用重定向

          若在上一個資源中向request范圍中存儲了數據,希望在下一個資源中從request范圍中取出,必須使用轉發

          3、重定向可以解決瀏覽器的刷新問題

          5、重定向解決頁面刷新問題


          主站蜘蛛池模板: 国产伦精品一区二区三区不卡 | 91视频一区二区三区| 精品一区二区三区免费观看| 在线观看中文字幕一区| 天堂va在线高清一区| 一区二区三区福利视频免费观看| 无码一区二区三区在线观看| 制服中文字幕一区二区| 亚洲线精品一区二区三区影音先锋 | 国产精品久久久久一区二区三区 | 亚洲爆乳无码一区二区三区| 国产成人av一区二区三区在线| 亚洲av日韩综合一区二区三区| 国模大胆一区二区三区| 在线播放精品一区二区啪视频| 三上悠亚国产精品一区| 国产萌白酱在线一区二区| 中文字幕视频一区| 中文字幕一区二区三区日韩精品| 波多野结衣AV一区二区三区中文 | 久99精品视频在线观看婷亚洲片国产一区一级在线 | 精品福利一区二区三区| 无码视频免费一区二三区| 精品福利视频一区二区三区 | 日本免费一区二区三区最新vr| 亚洲综合一区二区精品久久| 亚洲国产成人一区二区三区| 中文字幕国产一区| 久久精品国产第一区二区三区| 精品人妻一区二区三区四区| 美女福利视频一区二区| 精品一区精品二区| 国产免费无码一区二区| 亚洲av午夜福利精品一区人妖| 51视频国产精品一区二区| 日韩十八禁一区二区久久| 亚洲AV综合色一区二区三区| 日韩免费视频一区| 亚洲va乱码一区二区三区| 国产成人无码一区二区在线播放| 少妇一晚三次一区二区三区|