在如今這個 JS 大行其道的前端環境下,偏邏輯的前端在人數上是以壓倒性優點超過偏重構前端的。css
可是不知道你們有沒有想過,總共資源就那麼多,當咱們偏向邏輯和後端的同窗爭搶資源的時候,咱們偏向體驗和重構部分的資源,其實也正在被有工程化思惟的設計同窗分攤着。html
若是隻關注需求完成度,一個邏輯同窗寫的原型代碼,和一個重構同窗寫的原型代碼,幾乎看不出有太大的差異。一些可能會體現出重構同窗優點的佈局方案,邏輯同窗只須要 google 一下,基本也是一搜一大把。前端
在這樣的情況下,還有什麼地方能夠體現出重構同窗的優點呢?vue
本文會落點在一次比較小的重構優化方案上,嘗試粗略的回答這個問題。web
重構前 | 重構後 |
---|---|
這個是一個內部使用的站點地圖模塊,核心訴求是想要一行展現這四個連接。左邊是以前的視覺效果,右邊是優化以後的效果。後端
爲啥會提需求這個點呢?是由於對於細節和臨界狀態的把控,是重構同窗應該有的優點。瀏覽器
簡單的說,邏輯同窗能一眼就能看完和掌控到完整需求,而重構同窗要能看到更多需求以外,但很重要的細節。工具
由於是內部項目,左邊的設計已是找設計同窗優化過了。爲了避免進一步打擾設計的同窗,這邊就基於本身對需求和對設計同窗設計稿的理解本身處理了。實現4行變4列的需求,我能想到比較簡單的交互形式,就是相似網盤裏列表變圖標的方案。佈局
由於這三個圖標對於大部分同窗來講是有辨識度的,加上標題的字數有兩個有四個,若是放出來感受不是很統一,因此採用了 hover 的時候才顯示標題的方案。性能
這邊我經過添加了一個邊框,來增長有圖片和沒有圖片的圈圈之間的聯繫。Hover 的時候文字放大的邏輯也能增長圈圈之間的一致性,還能讓文字看得更清楚。
對於 UI 的理解度,和感知力也是重構同窗必備技能。只有真正理解了設計的重構稿,纔不會由於設計的一次小小的改動,而帶來總體代碼的修改。
<a target="_blank" href="https://juejin.im/user/5acb247951882555712ca8ee" title="讓前端更有價值">
<img src="assets/img/avatar/juejin.png" width="56" height="56" alt="掘金">
<strong>掘金</strong>
</a>
<a target="_blank" href="https://www.zhihu.com/org/yue-wen-ji-tuan-qian-duan-tuan-dui/activities" title="與世界分享你剛編的故事">
<img src="assets/img/avatar/zhihu.png" width="56" height="56" alt="知乎">
<strong>知乎主頁</strong>
</a>
<a target="_blank" href="https://www.getrevue.co/profile/yux-fe" title="每週前端資訊">
<img src="assets/img/avatar/zhoukan.png" width="56" height="56" alt="週刊">
<strong>前端週刊</strong>
</a>
<a target="_blank" href="#" title="每次分享 都是成長">
<strong>樂享</strong>
</a>
複製代碼
在寫重構代碼的時候,個人習慣會脫離視覺,先基於內容建立合理的 DOM 結構。這樣作有兩點緣由:
a
: title
屬性不能少 「 鼠標移入能看到更多信息 」;a
: 外站連接添加 target="_blank"
屬性「新頁面打開外站地址」;img
: width
,height
屬性不能少,並和你實際但願圖片顯示大小保持一致「 防止頁面抖動」;img
: alt
屬性不能少「圖片沒有加載的時候告訴別人這是啥圖片」;以上幾個點是特別容易被邏輯同窗遺忘的點。由於不寫好像也沒有什麼問題,但在我看來這就比如演員要背臺詞同樣,是重構同窗必要的基本素養。
另外對於圖片處理工具「 PS, sketch,figma... 」的基礎使用也是須要重構同窗掌握的。簡單的圖形處理若是也要等着設計同窗效率會大打折扣。
基礎樣式比較簡單,就是讓圖片 position:absolute;
在整個a
標籤中。
這樣當圖片資源加載失敗的時候,後面的文字會露出,能作到優雅的降級。
可是當圖片資源加載有問題的時候 alt 文案會顯示出來。處理辦法用font-size:0;
或者color:transparent;
。
這裏提到的降級是爲了說明漸進加強也是重構同窗須要額外注意到的點。
注:照理來講,是不該該隱藏圖片的
alt
信息的,只是由於這裏的標題能夠明確告訴用戶這是什麼,因此能夠這樣作。
對於強制不換行,我這邊採用的 white-space: nowrap;
的方案。
.wrap{
/* 去掉inline-block 元素之間的空隙 */
font-size: 0;
overflow-x: auto;
white-space: nowrap;
-webkit-overflow-scrolling: touch;
}
.item{
margin-left: 4px;
margin-right: 4px;
}
.item strong{
font-size: 12px;
white-space: normal;
}
複製代碼
Flex
.item{
vertical-align: middle;
display: inline-flex;
align-items: center;
justify-content: center;
}
.item strong{
max-width: 2em;
}
複製代碼
代碼量少,容易理解,有兼容性要求。
inline-block
.item strong{
line-height: 56px;
/*解決 vertical-align: middle; 不完美垂直居中問題*/
font-size: 0;
}
.item span{
max-width: 2em;
line-height: 1.2;
display: inline-block;
vertical-align: middle;
font-size: 12px;
}
複製代碼
兼容性不錯,可是繁瑣。
這兩種方式對於垂直居中仍是有不同的理解的,示例圖中能夠看到區別。還有一種能夠經過display:table;
實現,須要再額外添加一層標籤,就不在考慮範疇了。
前面有提到說,對於這種的佈局代碼,網上一搜一大把。那對於重構同窗來講,經驗和決策的速度就是優點。
一般來講對於編寫這類佈局技巧的頁面數量,重構的同窗應該是須要以壓倒性優點超過其它前端同窗的。這樣才能對於向vertical-align: middle;
並非完美的垂直居中的細節和如何處理這種細節的方式做出快速的反應。
對於這些臨界狀態是很容易被你們忽略的。重構的同窗對於這一點要格外的留意。由於設計同窗容易漏掉一些好比 hover, active, focus, loading... 等等的設計稿。這是咱們重構同窗應該幫設計同窗考慮到,或者 push 設計同窗考慮到的點。
對於動效來講,一般咱們但願由更敏感的設計同窗給到咱們動效的曲線和具體參數。對於「切圖仔」來講還須要額外考慮的是動效的性能和實現成本,甚至是動效傳達情感的一致性。
好比一樣是文字放大,你會選擇修改 font-size
仍是會選擇是用 transform
?
本文由於落點很小,因此只能簡短的列舉一些點。也沒有說重構和邏輯誰好誰壞,畢竟每一個同窗的時間有限,關注點也有傾向。
列舉的這些點是建議考慮但不是必定說要定死就必定要這樣作。畢竟仍是要以項目進度和開發成本爲主。
最後想說是不要由於本身是「切圖仔」就徹底拒絕去考慮邏輯的東西,你所堅持的很容易就成爲你的天花板。
不要放棄熱愛,但也不要拒絕新的挑戰。