На първо място искам да поясня, че тази статия е написана от Liro Krankka и правя само оторизиран превод, в края на статията ще бъдат връзките към използваната оригинална статия.

съвети

Трептенето е готино - разтърси го.

Разполагаме с модерни и свежи приложни програмни интерфейси (API) за изграждане на сложни потребителски интерфейси (UI) в малко количество код. Горещото презареждане е страхотно - можем да бъдем 5 екрана дълбоко в нашата йерархия за навигация, да направим няколко промени в потребителския интерфейс, да натиснем crtl + S и потребителският интерфейс ще се промени за по-малко от секунда, без да загуби състоянието. Но що се отнася до изграждането на сложни приложения, в крайна сметка получаваме много UI код.

С повече код идва и повече отговорност за поддържането му четливост. Поддържането на кода четлив улеснява поддръжката в дългосрочен план. Нека да видим няколко бързи съвета как да поддържаме нашия потребителски интерфейс по-четлив.

Повечето дизайни в нашите приложения се основават на съдържание, поставено хоризонтално или вертикално. Това означава, че няколко пъти ще използваме джаджи Column или Row.

Тъй като поставянето на приспособления точно под или едно до друго не винаги изглежда добре, искаме да имаме полета между тях. Един от най-очевидните начини за поставяне на марж между две приспособления е да увиете един от тях в приспособление Padding.

Помислете за следния пример:

Имаме три текстови джаджи в колона, които имат 8,0 полета между тях.

Проблемът: „Скрити джаджи“

Проблемът с използването на приспособления за подплата навсякъде е, че те започват да закриват "бизнес логиката" на нашия потребителски интерфейс код. Увеличете визуалния шум, като добавите нива на отстъп и брой редове.

Това, което искаме да направим, е да накараме основните джаджи да се открояват възможно най-много. Всяко допълнително ниво на отстъпа се брои. Ако можем да намалим броя на редовете едновременно, това също би било чудесно.

Решението: Използвайте SizedBoxes

За да се преборим с проблема със скритите приспособления, можем да заменим всички подложки с приспособления SizedBoxes, като използването на SizedBoxes вместо Paddings ни позволява да намалим нивото на отстъп и броя на редовете:

Тук приспособленията SizedBox изпълняват същата функция за разделяне на текста с марж от 8.0.

Същият подход може да се използва с приспособленията за редове, тъй като редовете подреждат своите приспособления за деца хоризонтално, можем да използваме свойството width на SizedBox за хоризонтални полета вместо за височина.

Крановете или крановете редовно са най-често срещаният начин за взаимодействие на потребителя с нашите приложения.

За да позволим на потребителя да „докосне“ някъде в нашето приложение, можем да използваме приспособление GestureDetector. за да го използвате, трябва да обгърнете оригиналната джаджа и да посочите обратното обаждане в свойството onTap в конструктора GestureDetector.

Помислете за следния пример, взет от приложението (Създадено от оригиналния писател) в приложението KKino:

Приложението inKino има мрежа от филмови плакати. когато потребителят докосне един от тях, той трябва да бъде отведен на страницата с подробности за филма.

Проблемът: Смесване на UI кода с Logic

Нашият метод за изграждане трябва да съдържа само минималния минимум, свързан с изграждането на потребителския интерфейс на нашето приложение. Логиката, съдържаща се в onTap, не е свързана с изграждането на потребителския интерфейс, това добавя ненужен шум към метода на изграждане.

В този случай можем бързо да определим, че Navigator.push въвежда нов маршрут и това е EventDetailsPage, така че докосването на елемент в мрежата отваря страницата с подробности. Ако обаче е включено повикването onTap, това може да изисква малко повече четене, за да се разбере методът на изграждане.

Решението: Извлечете логиката към частен метод

Този проблем може да бъде решен чрез извличане на повикването от onTap в добре наречен частен метод. В този случай създаваме метод, наречен _openEventDetails:

Това е по-добре.

Тъй като повикването onTap беше извлечено към добре именуван метод, не трябва да четем целия код. сега е лесно да разберете какво се случва, когато се извика повикването onTap, само като прочетете името на метода.

Сега намаляваме броя на редовете в нашия ценен метод за изграждане и се концентрираме само върху четенето на UI кода.

Понякога приспособленията за деца на нашата колона или ред не трябва да се виждат. Например, след като се използва inKino като пример, ако филмът няма подробности за сюжета по някаква причина, няма смисъл да се показва празен текст в нашия потребителски интерфейс.

Често срещан начин за кондициониране на деца от колона или ред изглежда така:

Същността на добавянето на елементи условно към колона е съвсем проста: инициализираме локален списък с приспособления и ако някой отговаря на неговите условия, го добавяме към списъка. Накрая предаваме този списък на параметъра за деца на колоната.

В този случай API на Finnkino (API, използван в приложението inKino) не винаги връща подробности за сюжета или актьорите на филма.

Проблемът: ако навсякъде

Въпреки че това работи, тези ако стареят много бързо.

Въпреки че са лесни за разбиране, те заемат ненужно място в нашия метод за изграждане. Особено ако имаме три или повече.

Решението: глобален метод в рамките на утили.

За да се преборим с проблема, можем да създадем глобален полезен метод, който обуславя добавянето на джаджи. По-долу е даден модел, използван в основния код на Flutter Framework.

Вместо да повтаряме условната логика за добавяне на приспособления към детския списък, ние създаваме полезен глобален метод, който го съдържа.

След като дефинираме метода, просто импортирайте файла и използвайте глобалния метод.

Това, което направихме тук, е, че сега нашият метод _buildMywidget () връща приспособление или null, в зависимост от това дали условието е вярно или не. Това ни позволява да спестим място в нашия метод за изграждане, особено ако имаме много условни джаджи.

Запазете най-доброто за последно.

Това е може би един от най-разпространените проблеми в нашия дизайнерски код. Често срещано оплакване в потребителския интерфейс с Flutter е, че нивата на отстъпите се увеличават като луди, което води до много скоби.

Обмислете следния пример:

Горният пример е от приложението inKino и съдържа кода за съставяне на списък с филми с техните графици. Нарочно го направих грозен (оригиналният писател). Много са намалени, повярвайте ми, когато казвам, че пълният пример би бил нещо страхотно.

По същество това е кодът за показване на тези лоши момчета:

Ако четете това на мобилно устройство, извинете. Най-добрият код не е красив за гледане дори на големи екрани. Защо? Сигурен съм, че повечето от вас вече знаят.

Проблемът: Използвали ли сте някога Lisp?

Този стар език за програмиране, наречен Lisp, има синтаксис, който използва много скоби. Виждал съм интерфейси на Flutter да се сравняват с Lisp доста пъти и, честно казано, виждам сходството.

Удивително е как никой не е правил това досега, така че започваме.

"Как да спасим принцесата с Flutter"

Въпреки че горният код работи, той е доста грозен за гледане. Нивата на вдлъбнатините стигат доста далеч, има много вертикални бъркотии, скоби и е трудно да се проследи всичко, което се случва и къде се случва.

Просто погледнете скобите в края:

Поради такова дълбоко влагане, дори и с добра IDE, е трудно да добавим нови елементи към нашия дизайн. Да не говорим, прочетете UI кода.

Поправка: рефакторирайте различни части на потребителския интерфейс в отделни джаджи

Бележка на преводача: Оригиналната версия на статията споменава използването на методи вместо класове, но тъй като потребителят Wm Leler споменава в коментарите на оригиналната статия, че използването на методи е анти-шаблон В изпълнението на приложенията на Flutter оригиналният автор актуализира статията си и създаде друга, посветена на тази тема (работя върху превода). По-долу е преводът на вече актуализираната статия.

В нашия списък има две различни части: лявата и дясната.

В лявата част се съдържа информация за сега започващите и завършващите филми. От дясната страна има информация като заглавието и дали е в 2D или 3D формат. За да направим кода по-четлив, нека започнем, като го разделим на две джаджи, наречени _LeftPart и _RightPart.

Тъй като приспособлението, което показва типа на презентацията, от дясната страна, ще въведе много вертикално претрупване и дълбоко влагане, ще го отделим в друго приспособление, наречено _PresentationMethod. Оригинална бележка на автора: не разделяйте метода си за изграждане на различни методи, който е модел срещу ефективност и заслужава собствена статия.

С тези промени нивото на отстъп беше намалено наполовина. Сега е лесно да сканирате UI кода и да видите какво става.

Не смятам това за проблем, подобен на началниците, но все пак е нещо доста важно. Защо? ще видим.

За да илюстрираме този проблем, нека разгледаме следния код:

Странно е, нали? Със сигурност не е нещо, което виждате в добър код.

Проблемът: не се използва dartfmt

Горният код не се придържа към никакви общи конвенции за форматиране в Dart - изглежда авторът на този код е измислил свой собствен стил. Това не е добре, тъй като четенето на този код отнема допълнително внимание - не се справя с конвенциите, с които сме свикнали.

Наличието на общоприет стил на кода е от съществено значение. Това ни позволява да избегнем умствената гимнастика да свикваме със странен стил.

Решението: просто използвайте dartfmt

За щастие имаме официален „форматиращ инструмент“, наречен dartfmt, който се грижи за форматирането вместо нас. Освен това, тъй като съществува „монопол върху форматите“, можем да избегнем спора кой формат е по-добър и вместо това да се съсредоточим върху нашия код.

Като основно правило, винаги поставяйте запетаи след всички скоби и пуснете dartfmt.

Вече форматираният предишен код е много по-четлив.

По-добре. Форматирането на нашия код е задължително винаги да помните запетаите и да форматирате кода си с помощта на dartfmt.

Много благодаря на оригиналния автор, че ми позволи да преведа статията му и се надявам тази информация да послужи на испаноезичната общност.

Връзка към оригиналната статия, Twitter профила на автора и неговата страница.