Sass: Tips and tools
Cũng giống như cách jQuery cách mạng hóa vanilla JavaScript, Sass cũng đã cách mạng hóa vanilla CSS. Đa số developers cho rằng, khi đã dùng qua Sass, họ không còn muốn quay lại công cụ cũ nữa. Nhiều người cũng đồng ý rằng vấn đề lớn nhất của các developers non trẻ là cách họ dùng Sass, chứ không phải ở bản thân công cụ này.
Bài viết sẽ tổng hợp những công cụ và thủ thuật tốt nhất để có được những đoạn code Sass có thể mở rộng và tái sử dụng được. Thông tin trong bài được lấy từ ý kiến cá nhân của tác giả và nhiều websites uy tín như Sass Guidelines.
Cấu trúc file
Tổ chức file là là nơi bắt đầu tốt nhất trong lập trình Sass. Nếu bạn có tìm hiểu về modular code, bạn có lẽ sẽ hiểu được tầm quan trọng của imports và partials.
Nhưng hiện giò, hãy nhìn vào ví dụ cấu trúc file từ DoCSSa trước. Tôi đã tái hiện lại cấu trúc file này như bạn thấy ở đây:
Đây chỉ một gợi ý cho bạn và một trong nhiều cách để tổ chức file. Còn có nhiều phương pháp khác sử dụng nhiều cấu trúc folder khác như “globals” cho site-wide SCSS và “pages” cho page-specific SCSS.
Hãy cùng xét thử mục đích của mỗi folder trong phong cách tổ chức đề nghị sau:
- /globals – Chứa files Sass áp dụng cho cả trang như typography, colors, và grids
- /components – Chứa file Sass với phong cách cho các yếu tố như buttons, tables, input fields
- /sections – Chứa files Sass dành cho từng page hoặc khu vực cụ thể trên page (có thể hoạt động tốt hơn khi kết hợp với /components/ folder)
- /utils – Chứa các tiện ích (bên thứ ba) như Normalize, có thể update dynamic với các công cụ như Bower.
- main.scss – file Sass chính trong root folder, imports tất cả các files khác.
Đây chỉ là những điểm cơ bản nhất, bạn có thể mở rộng thêm nhiều ý tưởng của bản thân.
Dù có lựa chọn tổ chức SCSS nào, vẫn nên nhớ rằng, bạn sẽ cần cập nhật một số tổ chức với một file (hoặc folder) độc lập cho các thư viện như Normalize, cùng với các thành tố trong Sass partials cho project.
Sass partials cực kỳ cốt yếu với nhiều phương pháp lập trình hàng đầu hiện nay. Sass partials rất được Zurb’s design team và nhiều developers frontend chuyên nghiệp khuyến khích.
Sau đây là một trích dẫn từ website Sass giải thích về partials;
“Bạn có thể tạo file partial Sass chứa nhiều snippet CSS để thêm vào các files Sass khác. Đây là một cách modularize CSS hay và giúp dễ bảo dưỡng hơn. Một partial đơn giản chỉ là một file Sas được đặt tên bắt đầu bằng dấu gạch dưới (_). Có thể đại loại như _partial.scss. Dấu gạch dưới sẽ giúp Sass biết được tằng file này chỉ là partial file và không nên được generate thành một CSS file. Sass partals được dùng với directive @import.”
Một số thông tin khác về cấu trúc file Sass:
- How I Structure My Sass Projects
- Aesthetic Sass: Architecture and Style Organization
- Directory Structures That Help You Maintain Your Code
Chiến thuật Import
Một lần nữa, tầm quan trọng của Sass import và Sass partials là cực kỳ to lớn. Tổ chức code là chìa khóa mở ra một cấu trúc import và workflow hiệu quả.
Nơi bắt đầu tốt nhất là với globals sheet có chứa imports, variables và mixins. Về mặt cú pháp, nhiều developers thích tách variables và mixins hơn.
Nên nhớ, mixins là phương pháp import, hay duplicate Sass code. Mixins cực kỳ mạnh mẽ nên không được sử dụng chúng chung với code “tĩnh”. Hơn nữa, mixins, extends, và placeholders đều có sự khác biệt riêng, và tất cả đều có hiệu dụng riêng trong lập trình Sass.
Mixins thể hiện tầm quan trọng của mình rõ rệt nhất khi kết hợp với dynamic values, được chuyển vào mixin để thay đổi code. Ví dụ như Sass mixin sau đây, giúp tạo background gradient giữa hai màu.
|
1
2
3
4
5
6
7
8
9
10
11
12
|
@ mixin linearGradient ( $ top , $ bottom ) {
background : $ top ; /* Old browsers */
background : - moz - linear - gradient ( top , $ top 0 % , $ bottom 100 % ) ; /* FF3.6+ */
background : - webkit - gradient ( linear , left top , left bottom , color - stop ( 0 % , $ top ) , color - stop ( 100 % , $ bottom ) ) ; /* Chrome,Safari4+ */
background : - webkit - linear - gradient ( top , $ top 0 % , $ bottom 100 % ) ; /* Chrome10+,Safari5.1+ */
background : - o - linear - gradient ( top , $ top 0 % , $ bottom 100 % ) ; /* Opera 11.10+ */
background : - ms - linear - gradient ( top , $ top 0 % , $ bottom 100 % ) ; /* IE10+ */
background : linear - gradient ( to bottom , $ top 0 % , $ bottom 100 % ) ; /* W3C */
filter : progid : DXImageTransform . Microsoft . gradient ( startColorstr = '#ffffff' , endColorstr = '#000000' , GradientType = 0 ) ; /* IE6-9 */
}
|
Mixin chiếm hai giá trị: màu trên và màu dưới. bạn có thể viết nhiều mixins cho nhiều kiểu gradients khác nhau, lên đến 3 hoặc thậm chi 4+ màu sắc khác nhau. Như vậy, bạn có thể import và clone mixin code, và đồng thời thay đổi tham số cho custom options.
Ví dụ từ Code Responsible trông như sau:
|
1
2
3
4
5
|
. button {
@ include linearGradient ( #cccccc, #666666);
}
|
Liên quan đến mixin là placeholder của Sass, thường được sử dụng với extend directive. Tuy có phức tạp hơn mixins, nhưng đây vẫn là công cụ hữu hiệu cho những ai muốn kết hợp selectors với nhau mà không cần viết thêm quá nhiều code.
Tuy Sass chỉ có một @import method duy nhất, nhưng tôi đã thêm mixins và placeholders để mô tả độ linh hoạt của code có thể được viết trong một file, nhưng được nhắc đến ở mọi nơi khác.
Khi xây dựng cấu trúc import, hãy nhớ tuân theo khái niệm DRY coding (Don’t Repeat Yourself).
Quy ước đặt tên
Quy luật chung cho quy ước đặt tên áp dụng cho variables, functions, và mixins. Mỗi khi đặt tên trong Sass, bạn nên sử dụng hoàn toàn chữ thường với dấu gạch nganh để phân tách.
Cú pháp code Sass trong thực tế dựa trên bộ quy tắc CSS guidelines. Đây là một số cấu trúc chuẩn đề nghị bạn có thể áp dụng:
- Thụt lề bằng hai (2) spaces indents, không tabs
- Lý tưởng, dòng rộng khoảng 80 ký tự hoặc thấp hơn
- Cẩn trọng với whitespace
- Dùng comments để giải thích CSS operations
Những quy luật trên không bắt buộc, nhưng đều là những đút kết quý báu từ nhiều tay lập trình kỳ cựu, nhằm tạo sự thống nhất trong quá trình code.
Về phần quy ước đặt trên, bạn có thể dùng hai cấu trúc sau: Một cho tên Sass và cái còn lại cho tên CSS class. Một số developers lại thích BEM hơn Sass. Chả có cài nào đúng hay sai hơn cái nào cả; chúng chỉ đơn giản khác nhau, với quá trình vận hành khác nhau thôi.
Vấn đề ở đây là BEM không chuyển hóa hoàn toàn được sang Sass variables hay mixing vì chúng thiếu cấu trúc block/element/modifier(BEM). Bản thân tôi ưa chuộng cách đặt trên Sass hơn, nhưng bạn cũng có thể dùng thử bất cứ thứ gì từ camelCase để hình thành cấu trúc riêng.
Khi tổ chức variables và mixins của riêng mình, bạn nên chia chúng theo từng loại, và liệt kê theo thức tự alphabet. Cách sắp xếp này giúp việc chính sửa dễ dàng hơn nhiều, vì bạn sẽ biết cần phải tìm thứ gì, ở đâu.
Ví dụ như, để thay đổi màu link, bạn sẽ phải mở file variables (có thể là _variables.scss) và xác định khu vực cho color variables. Sau đó tìm link theo tên (header link, text link,…) và cập nhật màu. Đơn giản!
Hãy xét Foundation’s settings file.
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
// Foundation for Sites Settings
// -----------------------------
//
// Table of Contents:
//
// 1. Global
// 2. Breakpoints
// 3. The Grid
// 4. Base Typography
// 5. Typography Helpers
. . .
// 1. Global
// ---------
$ global - font - size : 100 % ;
$ global - width : rem - calc ( 1200 ) ;
$ global - lineheight : 1.5 ;
// etc
|
Một cách đặt tên khác liên quan đến responsive breakpoints. Khi đặt trên Sass breakpoints, hãy cố tránh những tên quá cụ thể cho thiết bị. Những tên như small, med, lg, và xlg vẫn tốt hơn vì chúng có liên quan đến nhau.
Như thế này vẫn tốt hơn cho các liên kết nội bộ giữa breakpoints, và cũng phù hợp với những team có developers không biết các thiết bị nào liên quan đến nhau.
Khi thực sự bắt tay vào đặt tên, hãy cố càng cụ thể càng tốt, và không đụng đến các variables quá dài dòng. Bạn nên áp dụng cùng hệ quy tắc đặt tên lên cả site để dễ nhớ hơn khi code.
Gán những quy tắc đặt tên cụ thể cho mọi tiêu chí như màu sắc, margins, front stacks, và line-heights. Như vậy, ta không những có thể recall tên nhanh chóng, mà còn dễ dàng hơn trong việc viết tên variables mới khớp với cú pháp đã có.
Nesting và Looping
Hai kỹ thuật Sass này rất khó áp dụng trong thực tế. Tuy vậy, cả hai đều có nguy cơ bị lạm dụng nếu ta thiếu thận trọng.
Nesting là quá trình thêm selectors được lồng vào nhau thông qua indentation để tạo thêm specificity với ít code hơn. Sass có nesting guide, minh họa nhiều ví dụ về code nesting trong thực tế. Nhưng nên chú ý, rất dễ bị code nesting cám dỗ, và cho ra những đoạn code như sau:
|
1
2
3
4
5
|
body div . content div . container { . . . }
body div . content div . container div . articles { . . . }
body div . content div . container div . articles > div . post { . . . }
|
Cụ thể quá mức và gần như không thể overwrite được, kiểu code này hoàn toàn xóa đi mục đích của việc phân lớp stylesheets.
Nhìn qua bài hướng dẫn trên SitePoint này, bạn sẽ thấy được ba nguyên tắc vàng trong nesting (lồng ghép):
- Không bao giờ vượt quá độ sâu 3 lớp.
- Đảm bảo CSS output rõ ràng và tái sử dụng được.
- Dùng nesting cho hợp lý, không phải “mặc định” dùng mọi lúc mọi nơi.
Developer Josh Broton cho rằng quy luật cú pháp chung là chỉ nest khi cần thiết, còn lại thì indent.
Việc indent selectors sẽ không gây ra bất cứ hậu quả CSS phân tầng nào. Nhưng bạn sẽ “dễ thở” hơn khi phải lướt qua file Sass để xác định class nào liên quan đến nhau.
Vòng lặp cũng có thể bị lạm dụng nếu không được áp dụng đúng cách. Ba vòng lặp trong Sass là @for, @while, và @each. Tôi sẽ không đi quá chi tiết về nguyên lý hoạt động của chúng, nhưng nếu bạn thấy tò mò, có thể đọc thêm ở đây.
Thay vào đó, tôi sẽ bàn về mục đích của những vòng lặp này và chúng chạy trong Sass như thế nào. Những vòng lặp này sẽ giúp tiếp kiệm thời gian dành cho việc viết những code có thể tự động được. Ví dụ như, đây là một đoạn ví dụ từ Clubmate post, cho thấy vài đoạn code Sass, theo sau là output:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
/* Sass code */
@ for $ i from 1 through 8 {
$ width : percentage ( 1 / $ i )
. col - #{$i} {
width : $ width ;
}
}
/* output */
. col - 1 { width : 100 % ; }
. col - 2 { width : 50 % ; }
. col - 3 { width : 33.333 % ; }
. col - 4 { width : 25 % ; }
. col - 5 { width : 20 % ; }
. col - 6 { width : 16.666 % ; }
. col - 7 { width : 14.285 % ; }
. col - 8 { width : 12.5 % ; }
|
Những class column này có thể được sử dụng kết hợp với một grid system. Bạn thậm chí còn có thể thêm column hoặc hoặc bỏ bớt bằng cách chỉnh sửa loop code.
Vòng lặp không nên được sử dụng để nhân bản selectors hoặc properties cho một selector; đấy là nhiệm vụ của mixin.
Hơn nữa, khi lặp, ta có Sass maps lưu trữ key:value pairs của data. Người dùng nâng cao nên cố tận dụng những maps này hết sức có thể.
Đồng thời, bản thân vòng lặp Sass thông thường cũng đã là phương pháp cung cấp code output (không cần lặp lại) rất đơn giản và hiệu quả rồi. Lý do tốt nhất để sử dụng vòng lặp là với CSS properties giúp biến đổi data output.
Sau đây là một cách hay để kiểm tra xem vòng lặp có hiệu quả hay không: hãy xem thử liệu có cách nào khác để output CSS bạn cần (với ít code hơn) hay không. Nếu không, cấu trúc phòng lặp này đã tốt rồi.
Modularization (Module hóa)
Việc luyện tập viết modular Sass cực kỳ quan trọng trong hầu hết các project. Modularization là quá trình chia project thành nhiều module nhỏ hơn. Trong Sass, bạn có thể thực hiện modulization với partials.
Ý tưởng đằng sau modular Sass là để viết file SCSS độc lập, có mục đích cụ thể, nhằm vào global content (typography, grids) hoặc page element (tabs, forms).
Định nghĩa Sass module khá rõ ràng và nói lên một điều: import module không bao giờ có output code.
Ý tưởng output bắt buộc cho mọi module sẽ trờ thành cơn ác mộng khi tối ưu. Thay vào đó, bạn nên tạo modules đơn lẻ và chỉ call các modules nào bạn cần. Module có thể được xác định bằng mixin hoặc functions, nhưng bạn cũng hoàn toàn có thể tạo module chứa selectors.
Tìm hiểu thêm về Sass modules và kỹ thuật module hóa:
- CSS Modules: Welcome to the Future
- The Pros and Cons of Modular Sass
- Modular CSS Organization with SMACSS & SASS
Hãy tìm nhịp điệu của bản thân
Mỗi team hay developer cá nhân đều có cách thức làm việc riêng phù hợp với họ. Bạn thân bạn chũng nên tìm ra con đường của riêng mình.
Về vấn đề tự động hóa và giảm thiểu công việc Gulp và Grunt là hai công cụ nổi bật hiện nay bên cạnh nhiều công cụ tự động vô cùng tiện dụng khác.
Có thể bạn quan tâm:
10 người Việt sẽ có 8 người dùng điện thoại di động
Quảng cáo trên thiết bị di động
Marketing, tiếp thị, chăm sóc khách hàng, bán hàng trên mobile và ...
DVMS chuyên:
- Tư vấn, xây dựng, chuyển giao công nghệ Blockchain, mạng xã hội,...
- Tư vấn ứng dụng cho smartphone và máy tính bảng, tư vấn ứng dụng vận tải thông minh, thực tế ảo, game mobile,...
- Tư vấn các hệ thống theo mô hình kinh tế chia sẻ như Uber, Grab, ứng dụng giúp việc,...
- Xây dựng các giải pháp quản lý vận tải, quản lý xe công vụ, quản lý xe doanh nghiệp, phần mềm và ứng dụng logistics, kho vận, vé xe điện tử,...
- Tư vấn và xây dựng mạng xã hội, tư vấn giải pháp CNTT cho doanh nghiệp, startup,...
Vì sao chọn DVMS?
- DVMS nắm vững nhiều công nghệ phần mềm, mạng và viễn thông. Như Payment gateway, SMS gateway, GIS, VOIP, iOS, Android, Blackberry, Windows Phone, cloud computing,…
- DVMS có kinh nghiệm triển khai các hệ thống trên các nền tảng điện toán đám mây nổi tiếng như Google, Amazon, Microsoft,…
- DVMS có kinh nghiệm thực tế tư vấn, xây dựng, triển khai, chuyển giao, gia công các giải pháp phần mềm cho khách hàng Việt Nam, USA, Singapore, Germany, France, các tập đoàn của nước ngoài tại Việt Nam,…
Quý khách xem Hồ sơ năng lực của DVMS tại đây >>
Quý khách gửi yêu cầu tư vấn và báo giá tại đây >>
