現代化 Web 開發技術學習分享

0%

模組化一直以來都是網頁端一項很重要的處理,有效的模組化可讓程式碼進一步提升其閱讀性,以讓後續維護人員更快速的進入狀況,且利用模組可重用的特性,我們也不需要撰寫這麼多的重複代碼,載入即完成,可說是大幅提高了其開發效率。在 CSS 可使用 @import 來拆分模組,而 SCSS 同樣也是使用 @import 來拆分模組,兩者不同的地方在於 CSS 的 @import 會產生額外的 request,而 SCSS 主要利用其特殊的 partial 檔案形成模組化的效果,再不產生額外 request 下達到模組化目的。
閱讀全文 »

在前面我們有提到可使用 @mixin 將發生重用的樣式給包裝起來,進而減少重複撰寫樣式的時間,但在這邊有一個問題是,此做法會造成編譯後的 CSS 發生樣式大量重複的問題,搞得檔案異常肥大,在較為嚴苛的環境下,此問題是不被允許的,建議的作法是使用 @entend 並搭配 placeholder 選擇器將重用樣式給綑綁起來,@extend 就類似於 @mixin,不同的地方在於 @extend 會將目標對象進行合併而不是載入,而 placeholder 選擇器主要用來創建重用對象,在不被編譯的狀態下給予 @extend 繼承用。
閱讀全文 »

之前介紹 @mixin 時是以一般語言的函式做為參考進行操作,事實上 SCSS 有更符合函式定義的語法名為 @function,與 @mixin 不同的地方在於 @function 無法直接將 CSS 樣式加載至當前所在的 CSS 塊內,反而是透過 @return 將函式內處理的結果返回給呼叫的對象後續再進行相關處理,簡單來講就是 @mixin 負責包裝 CSS 樣式,而 @function 則是包裝需透過處理使之形成的有效對象,該如何透過 @function 進一步提升開發效率也就是本篇的重點。
閱讀全文 »

傳統在撰寫樣式表上很常發生重工的現象,雖然說作用的對象是不同的,這指 CSS 選擇器作用的目標,但無法否認確實降低了我們的開發效率,最理想的做法應該是將會重用的樣式包裝成一個物件,每當有相同樣式的撰寫需求時,只需要取用這一個物件即可達到目的,而 Sass / SCSS 正好有提供像是 @mixin 的語句,用法就類似於 Vue.js 的 mixin,只不過將其撰寫內容更改為樣式而已,最後使用 @include 載入 mixin 即可完成取用動作,藉此達到減少重工發生可能的目的。
閱讀全文 »

雖然說撰寫樣式表其複雜性遠遠低於一般的主流程式語言,但無法否認在某些時候我們確實需要更高效的做法來達到目的,迴圈處理就是個很好的例子,傳統 CSS 撰寫樣式必定是透過手動輸入的方式來完成,而 Sass / SCSS 提供了像是 @for、@each、@while 語句,讓我們透過迴圈的方式快速產出樣式,藉此達到高效開發的目的,其中也包含像是 @if、@else if 等條件判斷式,可根據其判斷輸出不同的樣式,讓我們在較複雜的情境依然能夠保持其樣式表的靈活度。
閱讀全文 »

先前我們就有提到 Sass / SCSS 真正意義上的將樣式表變為了一門程式語言,即 SassScript,而身為程式語言,想當然就會有所謂的變數可以使用,這也是我跳坑的其中一個原因,你能想像樣式表居然能夠使用變數做撰寫嗎?這指的變數與其他語言差不多,同樣有分為字串、陣列、物件等型態可做使用,大幅提高了代碼的重用性,以後如有更改的需求,也只需針對變數做處理即可,改善傳統樣式表不易維護問題。
閱讀全文 »

上一次我們已經將 SCSS 的編譯環境給建立好了,接下來讓我們正式進入到語法的章節,首先介紹的是 nesting 巢狀結構與父選擇器,巢狀結構是 Sass / SCSS 最具特色的功能之一,之前我們有提到傳統 CSS 可能會發生父對象重複撰寫的問題,為了避免汙染到其他樣式,我們必須明確地寫出父子對象的關係,搞到最後才發現浪費了許多時間,如果改使用 Sass / SCSS 中的巢狀結構語法並搭配父選擇器,不僅可解決此類問題,同時也能改善傳統樣式表可讀性低落的問題。
閱讀全文 »

在之前介紹的各種前端工具中,都是使用 SCSS 最為樣式表的開發對象,原因很簡單,那就是它大幅加強了 CSS 對各種操作的支持,以往我們會認為 CSS 語法很單調,但也因為太單調,導致存在許多操作上的不便,現在我們有了 Sass / SCSS 等 CSS 預處理器可以選擇,真正意義上的將樣式表變為一門程式語言,可使用變數、函式、迴圈等程式語言基本就具備的功能達到撰寫樣式表的目的。此篇將從何謂 CSS 預處理器開始介紹,接著說明 Sass / SCSS 該如何透過相關工具使之編譯成 CSS 跑在瀏覽器上。
閱讀全文 »

隨著專案越來越大,協作人員越來越多,衝突發生的機率也越來越高,訂定良好的團隊規範就顯得更為重要,Workflow 因此而誕生,常見的對象有 Git Flow、GitHub Flow 或 GitLab flow 等,主要都是被用來解決團隊間無規範可遵循造成衝突的問題,透過共同遵循的處理流程,達到有條理的進行團隊協作開發。此篇將介紹目前主流的 GitHub Flow 工作流程是如何運作,並透過實際演練說明它所能帶給團隊的好處。
閱讀全文 »

目前我們都是在自己的遠端數據庫做操作,由於是自己的並不會遇到所謂的權限問題,但假如我們也想操作其他開發者的遠端數據庫呢?比如你正在使用的套件存在 Bug,而你剛好有能力修復,將專案克隆並修復後,你想把最新提交推至原作的遠端數據庫,這時就會遇到權限不足的問題,你可能透過 Email 請作者開權限給你,但你覺得他會理你嗎?通常這個過程我們都會使用 Fork 與 Pull Request 來完成,先將原作的數據庫 Fork 至帳號底下,待我們克隆並修復完成後,再透過 Pull Request 請求作者合併更新。
閱讀全文 »