სანდო დიზაინ სისტემის კომპონენტები

Shota Ioramashvili
TBC Engineering

--

დღეს მინდა გესაუბროთ დიზაინ სისტემაზე და მისი საბაზო კომპონენტების კონკრეტულ გადაწყვეტაზე. პირველ რიგში განვმარტოთ თუ რა არის დიზაინ სისტემა.

დიზაინ სისტემა არის პროექტის ყოვლისმომცველი სახელმძღვანელო, რომელიც აერთიანებს გარკვეულ წესებს, პრინციპებსა და საუკეთესო მიდგომებს. დიზაინ სისტემის საბაზო კომპონენტებს ძირითადად წარმოადგენს UI ელემენტები. დიზაინ სისტემას ხშირად უწოდებენ single source of truth, რომელიც მთელ გუნდს ეხმარება განავითაროს პროდუქტი და შეინარჩუნოს მაღალი ხარისხი. დიზაინ სისტემა შეიძლება გავაიგივოთ ლეგოსთან.

მეორე მნიშვნელოვანი კითხვა დიზაინ სისტემასთან მიმართებაში არის ის თუ რა სარგებლობა მოაქვს მას?

პირველ რიგში ეს არის თანმიმდევრულობა, სადაც თითოეული დიზაინის გვერდი აღქმულია როგორც გარკვეული საბაზო კომპონენტების ერთობლიობა. ასევე მარტივი ხდება ტესტირება და გარკვეული ანომალიების გამოვლენა. ასევე დიზაინ სისტემა აადვილებს კომუნიკაციას დიზაინისა და დეველოპმენტის გუნდებს შორის, და რაც ყველაზე მთავარია, საშუალება გვეძლევა სწრაფი იტერაციების.

დიზაინ სისტემის სრულყოფილ მაგალითად შეგიძლიათ წარმოიდგინოთ human interface guidelines. ჩვენი დღევანდელი მიზანი არის iOS-ის პროექტის მაგალითზე, დიზაინ სისტემის საბაზო ინფრასტრუქტურის მოწყობა და Unit ტესტებით განმტკიცება.

რომელ ფუნდამენტურ კომპონენტებზე გავამახვილებთ ყურადღებას?

  1. ფერები
  2. ტიპოგრაფია
  3. ღილაკები

დავიწყოთ ფერებით.

სანამ უშუალოდ გადაწყვეტაზე გადავალთ, ორი სიტყვა ვთქვათ ფერებზე. დიზაინ სისტემის ფარგლებში, ყველა ის ფერი, რომელსაც პროდუქტის ფარგლებში გამოვიყენებთ იქნება სასრული. თითოეულ ფერს ექნება კონკრეტული სახელი. ეს სახელი აუცილებლად არ გადმოსცემს ფერის მნიშვნელობას. მაგალითად თუ #FFFFFF სახელად დავარქმევთ white-ს და რამდენიმე თემის მხარდაჭერას ვგეგმავთ, ამ სახელის უკან #FFFFFF-გან განსხვავებული კოდის წარმოდგენა გამოიწვევს სემანტიკურ დაბნეულობას. ამიტომ ფერების სახელები სასურველია უფრო ზოგადი გვქონდეს. მაგალითად primary, secondary, error და ა.შ.

დავუშვათ ჩვენ წარმოსახვით დიზაინ სისტემაში ვიყენებთ მხოლოდ 3 ფერს. თითოეული სახელის უკან დგას კონკრეტული ფერის კოდი. მოდით აღნიშნული ფერები დავამატოთ Asset კატალოგში.

Aasset კატალოგი

როგორც სურათიდან ჩანს, გვაქვს სამი ფერი შესაბამისი სახელებით.

სანამ დავიწყებთ ფერების აღწერას, გავაკეთოთ DesignSystem ენამი, რომელსაც პრაქტიკულად ნეიმსფეისის ფუნქციას შეასრულებს.

DesignSystem გამოვიყენებთ ნეიმსფეისად

შევქმნათ Color ენამი, რომელიც Asset კატალოგში აღწერილ ფერებთან სტატიკური ქეისებით მუშაობის საშუალებას მოგვცემს.

ენამები სვიფტში საკმაოდ დაიხვეწა, ამიტომ ელეგანტურად ერგება ფერებთან მუშაობის ამოცანის გადაჭრას. ძირითად მოქნილობას ქმნის ის ფაქტი რომ ენამის ქეისის პარამეტრს შეიძელბა ჰქონდეს დიფოლტ მნიშვნელობა(apha: CGFloat = 1).

შემდეგში ფერების დასეტვა კონკრეტულ UI ელემენტებზე მოხდება მხოლოდ ზემოთ შექმინილი Color ენამის კონკრეტული ქეისებით. შეგვიძლია დავივიწყოთ UIColor-ის არსებობა. ამისთვის კი დაგვჭირდება დამხმარე ინფრასტრუქტურა. დავამატოთ extension მეთოდები UIView, UILabel და UIButton კლასებს, რომელიც საშუალებას მოგცემს Color-ის კონკრეტული ქეისი, მოქნილი API-ის საშუალებით დავსეტოთ.

ვიუს backgroundColor, tintColor and borderColor კონფიგურაცია
ლეიბლის ტექსტის ფერის კონფიგურაცია
ღილაკის ტექსტის ფერის კონფიგურაცია

UIView, UILabel და UIButton ვიღებთ როგორც საბაზო და ყველაზე ხშირად გამოყენებადი UI კლასებს. იგივე ლოგიკა შეგვიძლია გავავრცელოთ UIKit-ის სხვა კომპონენტებზეც.

მოდით ვნახოთ ზემოთ დამატებული თითოეული ექსთენშენ მეთოდის გამოყენების მაგალითი განმტკიცებული კონკრეტული Unit ტესტებით.

ტესტები დოკუმენტაციის კარგ წყაროს წარმოადგენს. ცხადად ჩანს ინფრასტრუქტურის თითოეული კომპონენტის გამოყენების მაგალითი და ვერიფიკაცია.

მოდით გადავიდეთ ტიპოგრაფიის აღწერაზე. დავუშვათ დიზაინ სისტემის ფარგლებში მოგვეწოდა ფერების მსგავსი სია. Color-ის მსგავსად დავამტოთ Typography ენამი და აღვწეროთ შესაბამისი რეალობა.

ფერების მსგავსად, ტიპოგრაფიაშიც გვაქვს ზოგადი სახელები, რომლის უკან ერთიანდება ფონტი, ზომა და ხაზებს შორის დაშორება. უნდა აღინიშნოს, რომ Typography.Description შეიძლება მოიცავდეს სხვა პარამეტრებსაც, როგორიც არის მაგალითად lineHeight და ა.შ. ეს ყველაფერი დამოკიდებულია დიზაინ სისტემის დეტალიზაციაზე.

ტიპოგრაფიის მოქნილი გამოყენებისთვის დავამატოთ ექსთენშენ მეთოდები UILabel და UIButton კლასებისთვის:

ლეიბლის font-ის კონფიგურაცია
ღილაკის font-ის კონფიგურაცია

მსგავსი ექსთენშენ მეთოდები შეგვიძლია დავამაოთ ყველა სხვა UI კომპონენტს რომელსაც ფონტის ცნება გააჩნია. მაგალითად UITextField, UITextView და ა.შ.

ამ შემთხვევაშიც ვნახოთ ზემოთ დამატებული თითოეული ექსთენშენ მეთოდის გამოყენების მაგალითი განმტკიცებული კონკრეტული Unit ტესტებით.

უკვე გვაქვს ორი მნიშვნელოვანი საშენი კომპონენტი, რომელიც კარგ ფუნდამენტს წარმოადგენს დიზაინ სისტემის მომავალი გაფართოებისთვის.

მოდით გადავიდეთ ღილაკის აღწერაზე, რომელიც ჩვენ მიერ შექმნილ Color და Typography კომპონენტებს დაეყრდრობა.

ღილაკი შედარების კომპლექსური კომპონენტია. ის ხასიათდება Style-ით, რომელიც თავის მხრივ შედგება Size-სა და State-სგან. თითოელი მათგანი ახდენს გავლენას ღილაკის საბოლოო პრეზენტაციაზე. როგორც ხედავთ აღნიშნული ტიპები აქტიურად იყენებენ Color და Typography კომპონენტებს.

ღილაკის სტილების გამოყენებისთვის დავამატოთ ახალი ექსთენშენ მეთოდი UIButton კლასს:

როგორც ხედავთ setStyle მეთოდი ძირთადად აგებულია ჩვენ მიერ უკვე დამატებული ექსთენშენ მეთოდებისგან.

ვნახოთ გამოყენების მაგალითი კონკრეტული ტესტის მიხედვით.

ამით დავასრულეთ წარმოსახვითი დიზაინ სისტემის სამი ძირითადი კომპონენტის შექმნა. ამ ეტაპზე ინფრასტრუქტურა მზად არის მომავალი განვრცობისთვის, სადაც შესაძლებელია შემოვიტანოთ Dimension-ები, სადაც მაგალითად თავმოყრილი იქნება Spacing, Insets და CornerRadius. ასევე ღილაკის მსგავსად შეიძლება აიგოს სხვა პატარა ან დიდი მრავალჯერ გამოყენებადი კომპონენტი, რომელიც უკვე არსებულ კომპონენტებს დაეყრდნობა.

აღნიშნული მიდგომით ძალიან მარტივი ხდება აპლიკაციაში მრავალი თემის მხარდაჭერა, ხშირი იტერაცია და კონკრეტული გვერდების სწრაფი აწყობა. ასევე რედიზაინიც არ იქნება მტკივნეული.

ზემოთ მოყვანილი მაგალითი ეყრდნობოდა ჩვენთვის მოწოდებულ დიზაინ სისტემას, რომელზეც პროფესიონალი დიზაინერები მუშაობენ. არის შემთხვევები, როდესაც ასე არ ხდება და დიზაინში ჩვენ თვითონ გვიწევს გარკვეული წესების გამოვლენა. ამ შემთხვევაშიც არის შესაძლებელი ზემოთ მოყვანილი იმპლემენტაციით დავიწყოთ, ოღონდ გზადაგზა დავამატოთ ამა თუ იმ კომპოენენტს შესაბამისის ქეისები.

მაგალითად Typography enum-ს შეგვიძლია გავუკეოთოთ custom case, რომელსაც გამოყენებისას კონკრეტულ მნიშვნელობებს გადავაწვდით. ხოლო რაღაც დროის შემდეგ თუ გამოიკვეთება ხშირად განმეორებადი პარამეტრები, შეგვიძლია რაიმე კონკრეტული case-ის სახით აღვწეროთ და ჩვენთვის მისაღები სახელი დავარქვათ. ჩავთვალოთ ამ შემთხვევაში, გზადაგზა გამოვავლენთ დიზაინ სისტემის ძირითად მნიშვნელობებს.

დაემატა case custom(description: Description)

custom case-ის იდეა შეგვიძლია სხვა ენამების შემთხვევაშიც განვავრცოთ.

ზემოთ მოყვანილი იმპლემენტაციის მიზანი არის იდეების გადმოცემა და პრაქტიკული დემონსტრაცია, თუ რამდენად მოქნილი და მძლავრი შეიძლება იყოს მარტივი კომპონენტებით რაიმე მოზრდილის შექმნა.

--

--