第十一期 · 邁向全棧：優化前端展現和進一步了解element-ui （下）

本篇概述

在上一期中，我們對之前的程序向前後端分離的方向邁進了一大步，並對程序作出了很多改變，這點我相信大家在刪除廢棄代碼時會很感同身受。由於上一期限於篇幅的原因，我們還有一些前端界面上的問題沒有得到解決，這次我將和大家一起解決這些問題，並在此過程中帶領大家一起更多的領略現代前端技術架構的風光。

先變得好看

在上一期實現的程序中，我們在前端界面的展現上還留了一些遺憾，因為經過改造的程序，其用戶界面的展現看起來效果非常不盡如人意。

首先是表單，看起來太長，然後按鈕靠左對齊不是一個好的用戶體驗。

表單之所以成了這樣，是因為我們更換了新的模板框架，但是在前端頁面中並沒有相應的更新為新框架所支持的樣式，因此頁面會沒了布局樣式。但又因為我們在上一期中編寫表單部分的HTML代碼時，直接採用了框架提供的組件（以el-開頭的標籤），而這些組件是經過框架預置好了樣式的，所以我們的按鈕和輸入框才單獨看起來是各自正常的。

要修正表單這部分的展現問題並不難，我們只需要理清楚具體的需求點，之後逐一滿足。

第一個問題整體頁面布局的問題。我們在應用老模板框架的時候，當時我們對錶單的處理是讓其居中的，所以第一個需求就是頁面內容居中。

第二個問題是輸入框寬度的問題。一般而言，人眼的可視區域相對於平常的屏幕距離，大約是每行650px左右，超過這個寬度後，如果是一篇文章，人很容易在換行時看錯行，為此，我們的輸入框也應該定寬在650px，這是第二個需求。

第三個問題是按鈕居中問題。這個問題看起來和第一個問題很類似，但是在前端展現上，頁面布局的居中其本質是「容器（<div>）」的居中，類似按鈕、文字、圖片的居中屬於非容器的居中問題，在CSS的樣式控制上有另外的方式，所以我們應該把這點當作獨立的需求看。我們馬上會看到兩者的區別。

針對第一個需求，我們了解到CSS的控制方式是寫一個margin屬性，按照之前老程序的實現，我們改寫後的屬性定義如下：

margin: 300px auto 100px;n

這句話的含義是，讓容器距離頁面頂部300px；底部100px的距離；左右兩側自動適應。當選擇距離兩側是自動適應時，系統的實現是讓容器到左側的距離等於到右側的距離，這樣其實就是居中了。

接著是第二個需求，對應的CSS實現方式是：

max-width: 650px; n

這不難理解，我們要求容器的最大寬度是650px，不能再寬了。

最後是第三個需求，對應的CSS實現方式是：

text-align: center; n

這句話的含義是讓（文字）內容居中。大家可以看見，和第一個需求實現的居中，其對應的CSS代碼完全不一樣。有關兩者的區別，大家可以搜索了解一下更多的相關知識，這裡不多贅述。

我們將準備好的代碼寫到index.html的相應位置，然後刪除之前的柵格系統代碼。

我們還注意到一個細節，當前的頁面輸入框距離瀏覽器的左右距離是不一致的，簡單來說，我們觀察到輸入框距離瀏覽器左側有一段空白間隙，而右側沒有間隙，這個間隙我們隨手用截圖軟體測量一下大概在80px左右。檢查代碼我們發現，我們之前直接複製模板框架的表單代碼時，多餘複製了一個我們並不需要的「label-width_="80px」」屬性，我們把它刪掉。

再將準備好的樣式代碼寫入到頁面中，最終的表單部分代碼如下：

刷新下頁面，我們看到最終的效果已經正常。

這裡大家如果已經學習過一些前端知識，特別是CSS樣式表的相關知識，會對上面這種寫法產生些疑問，因為上面這種寫法屬於CSS教程中提及的「硬編碼」方式，是一種非常不好的編程習慣，如果你有這樣的疑問說明你學習的還不錯，非常棒！

那麼這裡為什麼要這樣做呢？原因是我們利用前端框架實現時，也用了並不正常的實現方式，這裡如果採用正常的CSS編寫習慣（獨立樣式表），會引出更多的問題需要解決。所以這裡這樣做的目的只是為了讓大家學習和入門時更加容易，很快我們在後續的教程中將學習如何搭建前端開發環境，屆時我們將逐漸學習和採用正統的編碼方式。

表單的樣式問題解決了，我們接下來要處理的就是搜索結果展現時的樣式問題。眼下的情況是搜索結果完全沒有樣式，看起來有些亂糟糟。

我們在之前對搜索結果的呈現，利用了當時模板框架中提供的「柵格系統」。我們當時是在第六期教程中學習到的有關柵格系統的知識，並且知道柵格系統是現代前端模板框架中的標配組件，所以下意識的，我們也想看看element-ui 中是否也有提供。

結論是當然提供。

我們發現element-ui 的柵格系統與之前的稍許不同，比如之前的是12柵格，這裡是24柵格。不過這些區別對於我們來說都不是問題，只要之前理解了柵格系統的本質，這裡稍微看下element-ui 的有關柵格的說明，很快就能上手。

一般而言，每一行給用戶展示3～4部影視劇信息比較合理，太多的信息一樣會引起前面說的錯行的問題，其次就是行寬兼容性會很差，因為總要考慮瀏覽器寬度稍小的情況（一行信息過多而寬度不夠會造成難以控制的信息折行錯位現象），而且我們也希望在沒做自適應功能前，我們做的網站能在各種設備上獲得比較好的瀏覽體驗。

有了一行展示多少影視劇的結論，我們很容易推算出來一部影視劇信息佔用四分之一柵格比較合理，即每行顯示4部影視劇信息，每部影視劇信息佔用6柵格。

根據文檔說明，我們照葫蘆畫瓢，把文檔的示例代碼直接複製過來，然後結合之前的代碼稍作修改，刪除已經沒用的class樣式屬性，最後的代碼如下：

我們來一起看一下上面的代碼。

首先我們應用了模板提供的柵格系統，靠一組<el-row>標籤激活柵格系統。隨後根據我們剛才的需求，按照文檔說明編寫了一個6列柵格<el-col :span=「6」> 去展示一部影視劇信息，另外為了更加美觀，我們根據文檔說明提供的功能，指定了柵格彼此的間距是20px，這是 :gutter="20" 的含義。其餘的部分都是之前已經熟悉的，沒什麼好講的了。我們測試一下剛才的變動：

看起來初步的布局已經有了，雖然整體而言仍然不夠美觀，但我們只要解決了布局問題，剩下的這些細節的調整都不在話下。

不知道大家還有印象沒，之前我們對每部影視劇應用了一個box的樣式，提高了頁面整體的美觀程度。現在我們發現新的模板框架中，也有類似的容器，稱為「卡片」。

根據文檔說明，我們只需要應用一組<el-card>，就能用上這個小玩意。卡片組件的示例中，剛好最後一個例子的實現非常接近我們的需求，我們可以據此繼續施展照葫蘆畫瓢的功夫。不過有一點需要清楚，就是我們之前已經知道豆瓣返回的影視劇海報是尺寸不一的，為此我們需要針對這點特殊情況做一些額外的工作。

這次我們先直接看一下修改後的效果：

看起來已經比剛才的好了實在太多，甚至都有圓角圖片的效果了。我們再來看一下對應的代碼：

首先，我們不希望展現搜索結果是無限制寬度的呈現，原因還是之前已經說過的那幾點，為此我們限定了最大寬度為1200px，並且設置了居中。這些都是前面已經用過的手法了，只需要注意我們是把樣式綁定到了<el-row>上，因為這是柵格系統的最外層，應該綁定到這裡。

然後，我們發現行與行之間是沒有間隙的，柵格系統也沒有提供對應的控制辦法，所以我們又對<el-col>增加了一個間隔樣式，即要求從第一行開始，每行底部間隔40px。

為了有一個高大上的類似模板示例中圖片在卡片上的效果，我們在原有的圖片外層加了一層<div>容器，並且寫了一個定高為250px的樣式，並且用overflow控制如果超過了這個高度時的情況。overflow: hidden 是指如果容器中的內容超過了指定的高度時，則隱藏（hidden是隱藏的意思）。這裡稍加力氣的處理就是為了應對剛才說的海報尺寸大小不一的問題。

最後，我們讓卡片中的文字內容居中展示，這個手法之前也已經見過了，因此不多贅述。

到這裡為止，我們的程序已經煥然一新，從可用性和用戶體驗層面來看已經沒有什麼大問題了。不過我們怎麼能就此滿足呢？既然這次費了這麼大力氣用全新的模板框架，豈能不物盡其用？

再變得更加好看

在測試前端頁面時，我們有一個小技巧就是調整瀏覽器的寬度並觀察頁面布局和內容的變化，更為專業的方式當然是用響應式調試工具。不過我們這次不用這麼複雜，僅需要通過調整瀏覽器寬度的大小稍加測試一下頁面的變化情況即可。

通過觀察，我們首先會意識到一個問題，就是隨著頁面的拉伸，柵格也是隨著變化的，柵格里的內容 —— 特別是圖片會隨著柵格的變化而拉伸。我們會看到即使我們限定了1200px的最大寬度，但隨著頁面拉伸，某些圖片會變得模糊起來。這個現象我們能想到是圖片本身的問題，即解析度問題。說得通俗點，就是豆瓣給的圖片太小，我們要展示的圖片比較大，所以小圖片拉大了展示就會模糊，就是這個道理。

我們應該還有些許印象，記得之前調試豆瓣API時，豆瓣對影視劇海報圖片提供了三種尺寸，當時選擇的是中間尺寸，那麼這裡我們改成最大尺寸不就解決這個問題了？！

看下前後的對比效果，的確十分明顯的提升：

處理完模糊問題，我們現在對圖片下方的文字加以美化。

我們的原則當然是少自己處理樣式問題，多利用框架現成的資源，因為我們還沒有系統的學習過頁面設計與CSS樣式表的知識。

這裡是我依據自己的審美做的一些改變，大家也可以按照自己的口味靈活選擇。我們還是先看一下最終的效果：

對應的代碼如下：

首先，我們把影視劇的標題、年份等文字明確了一下字型大小（字體大小），並對年份信息這種不重要的信息，不僅採用小號字體，而且顏色用了灰色。

其次我們對豆瓣評分應用了模板提供的標籤組件（Tag 標籤）進行展示，為了配合豆瓣的綠色主色調，我們這裡也用了綠色。

最後對跳轉鏈接應用了模板提供的按鈕組件（Button 按鈕），為了不與豆瓣評分產生視覺衝突，我們選用了文字按鈕（type="text」），並且用了默認藍色。

以上這些改變真的是稍加修訂，但我們看到實際的視覺效果也是不小的提升，真是「有點不好意思，只是做了一點微小的工作」呢。

至此，我們這一次的實踐告一段落。回顧一下，我們一起通過第十期、第十一期的學習，完成了將之前的程序由純後端向前後端分離目標的轉變，在此過程中，我們不僅了解了什麼是前後端分離，還學習到了如何簡單應用現代前端技術框架，並初步接觸和認識了前端當紅的Vue技術和element—ui前端模板框架。

到現在為止，我們已經談到過好幾次的一個問題是，我們應用了新的前端技術後，並沒有使用一般的編程作業方式，特別的，對於Vue這種技術，我們現在的編程方式完全是背離其技術宗旨的，所以接下來，我們將學習如何更加正統的進行前端編程，然後再照舊將所學應用到我們的這個項目中。

最後還要多說幾句，我們並不是「為了前後端分離而前後端分離」，我們之所以這樣做，是因為迫不得已的豆瓣對於API單IP請求的限制。我們通過問題，找到解決這個問題的這樣一個辦法，而不是本末倒置為了得到答案去製造問題。這是一種做事情的非常重要的思路，僅此，和大家共勉。

下期再見！

PS：本期代碼已經更新到Github：

duzhipeng/ZhihuJianMingJiaoChenggithub.com
推薦閱讀：