Перш за все я хочу пояснити, що цю статтю написав Ліро Кранкка, і я роблю лише авторизований переклад, в кінці статті будуть посилання на використану оригінальну статтю.

побудови

Флаттер - це круто - розгойдуйся.

У нас є сучасні та свіжі API для побудови складних інтерфейсів користувача (UI) у невеликій кількості коду. Гаряче перезавантаження - це чудово - ми можемо бути на 5 екранів глибоко в нашій ієрархії навігації, внести кілька змін до інтерфейсу, натиснути crtl + S і інтерфейс користувача зміниться менш ніж за секунду, не втрачаючи стан. Але коли справа доходить до створення складних додатків, ми отримуємо тону UI-коду.

З більшою кількістю коду з’являється більше відповідальності за збереження його читабельності. Забезпечення читання коду полегшує підтримку в довгостроковій перспективі. Давайте розглянемо кілька коротких порад про те, як зробити наш код інтерфейсу більш читабельним.

Більшість дизайнів наших додатків базуються на вмісті, розміщеному горизонтально або вертикально. Це означає, що ми кілька разів будемо використовувати віджети Стовпець або Рядок.

Оскільки розміщення віджетів безпосередньо під або поруч один з одним не завжди виглядає добре, ми хочемо мати поля між ними. Одним з найбільш очевидних способів розміщення поля між двома віджетами є загортання одного з них у віджет Padding.

Розглянемо наступний приклад:

У нас є три текстові віджети всередині стовпця, вони мають 8,0 полів між ними.

Проблема: "Приховані віджети"

Проблема використання віджетів Padding скрізь полягає в тому, що вони починають закривати "ділову логіку" нашого коду інтерфейсу. Збільште візуальний шум, додавши рівні відступу та кількість рядків.

Ми хочемо зробити так, щоб основні віджети максимально виділялись. Кожен додатковий рівень відступу враховується. Якщо ми зможемо одночасно зменшити кількість рядків, це теж було б чудово.

Рішення: використовуйте SizedBoxes

Для боротьби з проблемою прихованих віджетів, ми можемо замінити всі відступи віджетами SizedBoxes. Використання SizedBoxes замість Paddings дозволяє зменшити рівень відступу та кількість рядків:

Тут віджети SizedBox виконують ту саму функцію відокремлення тексту з запасом 8,0.

Той самий підхід можна використовувати з віджетами рядків, оскільки рядки розташовують свої дочірні віджети горизонтально, ми можемо використовувати властивість width SizedBox для горизонтальних полів замість висоти.

Регулярні крани або крани - це найпоширеніший спосіб взаємодії користувача з нашими додатками.

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

Розглянемо наступний приклад, взятий із програми (Створеної оригінальним автором) у програмі KKino:

Додаток inKino має сітку плакатів з фільмами. коли користувач торкається одного з них, його слід перевести на сторінку з деталями фільму.

Проблема: змішування коду інтерфейсу користувача з логікою

Наш метод побудови повинен містити лише мінімальний мінімум, пов’язаний із побудовою інтерфейсу нашого додатку. Логіка, що міститься в onTap, не пов'язана зі створенням інтерфейсу, це додає непотрібний шум методу побудови.

У цьому випадку ми можемо швидко визначити, що Navigator.push вводить новий маршрут, а це EventDetailsPage, тому натискання на елемент у сітці відкриває сторінку з деталями. Однак, якщо задіяний виклик onTap, для розуміння методу побудови може знадобитися трохи більше читання.

Рішення: Витягніть логіку до приватного методу

Цю проблему можна вирішити, витягнувши виклик з onTap у добре названу приватний метод. У цьому випадку ми створюємо метод _openEventDetails:

Це краще.

Оскільки виклик onTap було вилучено до добре названого методу, нам не потрібно читати весь код. тепер легко зрозуміти, що відбувається, коли викликається виклик onTap, просто прочитавши назву методу.

Тепер ми зменшуємо кількість рядків у нашому дорогоцінному методі побудови і концентруємось на простому читанні коду інтерфейсу користувача.

Іноді віджети дітей із нашої колонки або рядка не повинні бути видимими. Наприклад, після використання inKino як прикладу, якщо у фільмі з якихось причин немає деталей сюжету, немає сенсу відображати порожній текст у нашому інтерфейсі.

Поширений спосіб кондиціонування дітей зі стовпців або рядків виглядає так:

Суть додавання елементів умовно до Стовпця досить проста: ми ініціалізуємо локальний список віджетів, і якщо той відповідає його умовам, ми додаємо його до списку. Нарешті ми передаємо цей список дочірньому параметру Стовпця.

У цьому випадку API Finnkino (API, що використовується в додатку inKino) не завжди повертає деталі сюжету або акторів фільму.

Проблема: якщо скрізь

Хоча це працює, ці випадки дуже швидко старіють.

Хоча їх легко зрозуміти, вони займають зайвий простір у нашому методі побудови. Особливо, якщо їх у нас три і більше.

Рішення: глобальний метод всередині утилів.

Для боротьби з проблемою ми можемо створити глобальний корисний метод, який обумовлює додавання віджетів. Далі наведено шаблон, що використовується в основному коді Flutter Framework.

Замість повторення умовної логіки додавання віджетів до дочірнього списку ми створюємо корисний глобальний метод, який його містить.

Після того, як ми визначимо метод, просто імпортуємо файл і використовуємо глобальний метод.

Що ми зробили тут, так це те, що тепер наш метод _buildMywidget () повертає віджет або null, залежно від того, чи є умова істинною чи ні. Це дозволяє нам економити місце в нашому методі побудови, особливо якщо у нас багато умовних віджетів.

Збережіть найкраще для останнього.

Це, мабуть, одна з найбільш поширених проблем у нашому дизайнерському коді. Поширена скарга в коді інтерфейсу користувача з Flutter полягає в тому, що рівні відступу збільшуються як божевільні, що призводить до багатьох дужок.

Розглянемо наступний приклад:

Наведений вище приклад подано із програми inKino і містить код для створення списку фільмів з їх розкладом. Я навмисне зробив це негарним (оригінальний автор). Багато чого було зменшено, повірте мені, коли я кажу, що повний приклад був би чимось чудовим.

По суті, це код для відображення цих поганих хлопців:

Якщо ви читаєте це на мобільному пристрої, вибачте. Топ-код не красиво бачити навіть на великих екранах. Чому? Я майже впевнений, що більшість з вас це вже знають.

Проблема: Ви коли-небудь використовували Lisp?

Ця стара мова програмування, що називається Lisp, має синтаксис, який використовує багато дужок. Я бачив, як інтерфейси Flutter порівнювали з Lisp, не раз, і, чесно кажучи, я бачу подібність.

Вражаюче, як ніхто цього раніше не робив, от і ми йдемо.

"Як врятувати принцесу Флаттером"

Незважаючи на те, що наведений вище код працює, на нього досить потворно дивитись. Рівні відступу заходять досить далеко, тут багато вертикальної метушні, дужок, і важко відстежувати все, що відбувається і де це відбувається.

Просто подивіться на дужки в кінці:

Завдяки такому глибокому вкладенню, навіть із хорошою IDE, важко додати нові елементи до нашого дизайну. Не кажучи вже про читання коду інтерфейсу користувача.

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

Примітка перекладача: Оригінальна версія статті згадувала про використання методів замість класів, але оскільки користувач Wm Leler зазначив у коментарях до оригінальної статті, що використання методів є анти-шаблоном У виконанні додатків Flutter оригінальний автор оновив свою статтю та створив іншу, присвячену цій темі (я працюю над перекладом). Далі подано переклад статті, яка вже оновлена.

У нашому списку є дві різні частини: ліва та права.

Ліва частина містить інформацію про фільми, які зараз починаються та закінчуються. Права сторона містить таку інформацію, як заголовок, і якщо вона у 2D або 3D форматі. Щоб зробити код більш читабельним, почнемо з того, що розділимо його на два віджети, які називаються _LeftPart та _RightPart.

Оскільки віджет, який показує тип презентації, всередині правої сторони, збирається внести багато вертикальної метушні та глибокого вкладання, ми розділимо його в іншому віджеті, який називається _PresentationMethod. Оригінальна авторська примітка: не розділяйте свій метод побудови на різні методи, які є шаблоном проти ефективності та заслуговують на власну статтю.

З цими змінами рівень відступу зменшився наполовину. Тепер легко сканувати UI-код і подивитися, що відбувається.

Я не розглядаю це як проблему, подібну до начальства, але це все одно щось досить важливе. Чому? ми побачимо.

Щоб проілюструвати цю проблему, давайте розглянемо такий код:

Це якось дивно, чи не так? Звичайно, це не те, що ви бачите в хорошому коді.

Проблема: не використовувати dartfmt

Вищезазначений код не дотримується жодних загальноприйнятих умов форматування в Dart - здається, автор цього коду винайшов свій власний стиль. Це погано, оскільки читання цього коду приділяє додаткову увагу - воно не відповідає звичним звичаям.

Наявність загальноприйнятого стилю коду є дуже важливим. Це дозволяє нам уникнути розумової гімнастики звикання до дивного стилю.

Рішення: просто використовуйте dartfmt

На щастя, у нас є офіційний “форматор”, який називається dartfmt, який опікується форматуванням для нас. Крім того, оскільки існує "монополія формату", ми можемо уникати суперечок щодо того, який формат кращий, і натомість зосередитись на нашому коді.

Як головне правило, завжди ставити коми після всіх дужок і запускати dartfmt.

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

Краще. Форматування нашого коду завжди потрібно пам’ятати про ваші коми і форматувати код за допомогою dartfmt.

Дуже дякую оригінальному автору за те, що він дозволив мені перекласти його статтю, і я сподіваюся, що ця інформація послужить іспаномовній спільноті.

Посилання на оригінальну статтю, Twitter-профіль автора та його сторінку.