Как дизайнеру оседлать четыре строчки кода и больше никогда не загружать картинки для интерфейса: гайд по Framer X
Очередной раз ищем неочевидные пути, как ускорить рутинные процессы для дизайнеров интерфейсов. Сегодня разберём знакомую для многих боль — подбор контента для нарисованных экранов и/или потеря контента при обновлении компонентов.
Как обычно это происходит?
Вот сделал ты главную онлайн-кинотеатра. Чтобы наполнить его контентом, тебе придётся сходить на «Кинопоиск» и отобрать фильмы, которые будут «достойны» красоваться в твоём приложении. Потратил время, всё красиво, но через пару дней ты решишь чуть-чуть изменить компонент и у тебя случайно послетали все картинки. Ладно один экран, не так обидно, но если их сотни?
Рубрика «Э-э-эксперименты»
Предлагаю другой путь. Что если не скачивать картинки для каждого отдельного фильма, а просто вставить ссылку на сайт, чтобы картинки сами позалетали в твои дизайны?
А что, так можно было?
Вообще да, но есть маленькое но... Figma сегодня мы открывать не будем. Прошу любить и жаловать, Framer X – наш сегодняшний конь, которого мы и будем седлать. Если ты ещё не в курсе, это такой инструмент для дизайнеров, в котором ещё можно немного поковырять код. В умелых руках это нереальная вещь, поэтому я пытаюсь её изучать :D
Страшно, дизайнер? Не переживай, тут всё не так жёстко, как ты думаешь (даже если ты никогда не тыкался в коде). Вот всё что нам нужно:
Да, именно из-за этих строчек весь сыр-бор. Это описанный запрос к базе данных с фильмами, именно оттуда мы и будем получать картинки, тексты и другие штуки, чтобы наш дизайн сразу был законченным. Больше никаких заглушек!
Ну что, погнали дизай...кхм...кодить
Для начала нам нужен сам компонент карточки фильма. Framer похож на любой другой дизайн-инструмент, поэтому сложностей с отрисовкой карточки быть не должно.
Самоё лёгкое позади. Теперь нужно взять откуда-то данные для карточек фильмов. Тут нужно познакомиться с API. Эта штука позволяет «стучаться» к базе данных и просить у неё всякое разное.
Я нашёл сайт с каталогом API на любой вкус и цвет, подойдёт для любого приложения. Для нас тут есть огромная база с фильмами от IMDb.
Тут всё сложновато, на первый взгляд, поэтому к этому сайту вернёмся в конце статьи, когда разберёмся с основами. А пока будем тренироваться на сайте от самого Framer. Тут можно один раз вручную создать JSON-файлик с данными, чтобы потом его переиспользовать. Я заранее создал набор фильмов для этой статейки, поэтому тебе заморачиваться не придётся.
Я упомянул JSON – это такой универсальный формат хранения данных, туда можно записать, например, ссылочки на постеры и текст с названием фильма, удобненько в общем.
Теория позади, открывай редактор кода, дизайнер
Переходи на четвёртую вкладку на панели слева и создавай новый сode component. У тебя откроется пустой проект, и первое, что нужно сделать, сказать Framer, что мы будем использовать в коде:
В первой строчке говорим, что будем использовать библиотеку React js. Она у фреймера под капотом, поэтому обязательно указываем её. В последней говорим об использовании нашего дизайн-компонента. К остальным вернёмся позже, можешь пока их не указывать, чтобы не путаться.
Ну что, вот и твоя первая осознанная строчка кода. Fetch — это метод запроса, с помощью него мы и будем получать данные по ссылке внутри скобок. Потом сможем сюда вставлять ссылки на любые API, а пока тренируемся на этой. Допустим, данные ты получил, что теперь с ними делать? Надо бы их обработать, коронавирус же...нет... и без него надо было бы:
Я сейчас не расскажу про асинхронность всего этого дела и другие мелочи запросов к API, давай мы договоримся, что тут мы преобразуем запрос в нужный нам формат. Как я говорил ранее, мы будем использовать JSON. Да-да, мы преобразуем JSON в JSON, Framer-то не знает, что мы ему уже скармливаем нужный формат, поэтому говорим ему, чтоб тот сделал свою работу :)
После преобразования данных нам нужно их куда-то сохранить, чтобы потом мы могли их использовать в различных местах.
Скорее всего, у тебя возникла ошибка, потому что сохранять нам пока что некуда. Чтобы хранить данные, нужно создать переменную, в которую мы и будем закидывать эти данные. Кстати, тут мы используем useState, эта та штука из середины статьи, обязательно подключи его сверху проекта, чтобы всё работало.
Ну как бы всё
Мы написали запрос к API и сохранили его данные в переменную, теперь можешь делать с этими данными всякое разное. Пока...
Шучу, осталось ещё много чего непонятного. Сейчас расскажу, для чего нужен остальной код и как в итоге засунуть данные внутрь дизайн-компонента.
Эта штука для экспорта компонента FilmList из кода, чтобы можно было использовать { всё, что внутри скобок } в дизайне, а там и запрос к API и другие интересные штуки.
А вот и вторая импортнутая штука из начала проекта. useEffect сделает ваш запрос к API стабильным, потому что отрисует данные один раз и больше трогать их не будет. Если интересно, попробуй сделать запрос без useEffect и посмотри, что будет (спойлер: забавные глюки).
Вот и добрались до внедрения API в наш компонент. Дословно эта строчка переводится как «если данных нет, то и не выводи ничего», а по факту она даёт возможность работать следующему куску кода.
Тут мы говорим переменной data, в которой у нас лежат данные о фильмах, чтобы она распределилась по компоненту FilmComponent, который мы рисовали в дизайне. Отдельно выделяем это дело в переменную (const List), чуть позже нам это пригодится.
По сути, всё, компонент должен получать данные через API, а ты радоваться проделанной работе, но ничего подобного :)
Ты ещё не вывел свой код компонент FlimList на дизайн область. Чтобы это сделать, заверстаем Stack из всех фильмов, что мы получили через API. Stack — это функция Framer, которая работает как Auto Layout, растягивается до размера контента внутри.
Сейчас внутри стака указана та переменная, в которой хранятся распределенные данные по карточке в количестве семи штук (именно столько фильмов я сохранил в заготовленном JSON). Поэтому стак у нас будет размером с семь рядом стоящих карточек. Также мы указали, что фильмы будут располагаться горизонтально друг за другом с отступами 20pt.
Теперь обернём стак в Scroll, чтобы можно было проскроллить карточки фильмов до конца.
Вот теперь точно всё
Должно получится такое превью, которое можно открыть на телефоне. Оно кстати, делает запросы к API отдельно от ПК. А ещё Framer может собрать демку в веб-превью, очередная крутотень!
Ну что, теперь ты готов к взрослым API
Заготовленная API была простенькой закуской. Самое интересное начинается, когда мы используем данные, которые обновляются в реальном времени. Например, можно сделать прототип с прогнозом погоды, который будет показывать реальный прогноз погоды, круто!
Но крутые API требуют крутого подхода, один из таких — API-ключ. Он позволяет базе данных понимать, кто конкретно запрашивает данные, это сделано для безопасности и для всяких бизнес-штук. Чтобы использовать API-ключ, нужно дополнить наш fetch запрос к API таким образом.
В параметре headers укажи то, что указано в сопровождающей информации к API, обычно все описывают, как работать с запросами к базе, так что просто внимательно читай документацию. Ключ, если что, находится здесь.
Готово, ковбой, Framer X осёдлан
Надеюсь, я всё понятно описал, но если будут вопросы, задавай их в комментариях или в личку telegram. Также не забывай про файл-исходник, потыкайся в нём, если не хочешь писать всё сам, но тебе интересно посмотреть.
Слишком длинная инструкция как оседлать 4 строчки кода )
Всего 4 строчки, но как брыкаются)
Я пытался сократить, но это оказалось импосибл. Всё хотел затронуть, чтобы максимум вопросов отсечь)
Вещь интересная, но зачем дизайн-макетам (которые созданы для того что-бы показать структуру компонентов) подтягивать какие-то данные с каких-то АПИ? Бесполезная игрушка получается, а так потыкаться можно да 👍
Согласен, у меня это пока эксперименты, но вообще у этого большой потенциал в двух моментах:
1) Исследования пользователей, там контентом обязательно нужно заполнить все макеты
2) Проверка дизайн макетов (частенько реальные фото и текста выглядят в сервисе не так читаемо, как в макетах из-за нерандомной выборки дизайнером)
сейчас дизайнеры должны работать с реальными данными. А ещё желательно показать, как приложение должно работать со всеми возможными сценариями.
А у меня у одного возникает вопрос что нужно сделать с компонентом в фигме что бы полетели все картинки? Первый раз такое слышу
Защита от дураков никогда не помешает :D
На практике, в больших китах часто что-то происходит, особенно, когда инструменты (фигма, скетч и другие) добавляют какие-то новые штуки, которые хочется добавить в кит, например авто лэйауты для множества компонентов.
Ну у меня бывает подлагивает фигма что все блоки съезжают или исчезают куда-то, но это пока не кликнешь по нему и это то это все если 100500 уровней автолейаутов в 5 слоев компонентов завернуть. А вот чтоб фотки пропадали
Подумал немного, наверное зря я написал это, ты прав, проблема достаточно сложновоспроизводимая, в следующий раз постараюсь не притягивать за уши что-то)
p.s. Перестал замечать «прыгающие» компоненты, может уже починили?
Все-таки кодеры народ усидчивый и терпеливый пздец, я даже до конца не осилил дочитать, дочитать, а Вы тут такое расписали..
Я не кодер, а продуктовый дизайнер. Мне тоже было сложно, поверь :D
Нехороший ты человек автор, я вот сознательно не лезу в код, чтобы не лишать разработчиков заработка; твои методы оббезработят половину айтишников, стыд!
Кроме шуток, я так заебался искать код для разработчиков что думаю когда уже сделают дизайн-макеты полностью на основе реального кода для разных систем (веб, мобилы), чтоб нахуй выкинуть всяких чсвшных бездарей из своей индустрии
Привет, Pixel, знакомые лица :)
Не думаю, что подобные инструменты заменят разрабов или дизайнеров. Как по мне эта штука наоборот приучает всех общаться на одном языке, и это круто!
Не совсем понял про код для разработчиков?)) А для кого он ещё?)
Напомни откуда знакомы?
Да в том-то и дело, что код - для разработчиков, а мне дизайнеру часто приходится самостоятельно в него лезть, когда разработчики ноют что чёт нельзя сделать.
Думаю за инструментами типа фреймера будущее, но таки надеюсь что верх возьмёт фигма и ее тотальная автоматизация) Типа задизайнил приложеньку, указал что и как себя ведёт, кликнул кнопарь "опубликовать в стор" и плотоядно потираешь ручки :)
Мне кажется, в сторону твоих мечт будет идти как раз фреймер. Фигма ближайшие 5-10 лет будет разрабатываться для больших компаний, чтобы заработать денег, а там нужна командная работа и вот это вот всё)
Мы с тобой не знакомы, но я помню тебя по комментам под другой моей статьёй «ячейки на auto layout в фигме», ты там тоже жаловался на разработчиков :D
Лол, да, похоже на меня! Как только разработчики станут грамотнее я прям статью запилю о том, как я стал счастлив)))
Разработчики грамотны (в том что касается дизайна) ровно настолько, насколько хорошо с ними налажены отношения. Так то большинство актуальных новшеств в инструментах дизайна пришли как раз из области разработки (reusable components и overrides, распределенный контроль версий, тот же auto layout). Часто между дизайнерами и разработчиками пропасть — первые не имеют представления как устроена система для которой они проектируют интерфейсы, ограничения, возможности, best practices.
Разработчики грамотны настолько, насколько им позволяет им ЧСВ. Часто оно ограничивает: "я технарь, я самый умный, это точно нельзя сделать". Я: "вот готовый код, не пизди, а делай!"
Если не секрет, где ты работаешь?)
Компанию не раскрою, а индустрия - интернет вещей: клиентская часть и админки операторов.
+ шабашки, куда без них.
А ты?)
Я поработал в маленькой региональной студии, потом в небольшом стартапе и сейчас, в крупной компании, нигде не было такого, чтобы прям хейтили друг друга в команде
Тоже такое встречал, но видимо везло и такое было не часто. Обычно получалось совместно разобраться. Но по негативному опыту могу сказать, что он был не из за ЧСВ а скорее из за консервативности и возможно лени, когда проще натянуть дизайн на знакомый фрэймворк при помощи костылей, чем подумать сделать кастомное решение.
Я таки делаю вывод, что эти качества проистекают именно из ЧСВ. В это легко поверить после общения с человеком - такие ленивые консерваторы как правило знают всё лучше других по жизни.
А ты со своей стороны как с ними общаешься? Выполняешь ли «дизайнерский долг»?
Согласен, видел только такую форму дисконекта с разработчиками, но чтобы они смотрели на дизайнеров, как на говно? Ну такое :)
Не совсем понятно где и как применять фреймер, если мы не делаем очередное приложение с фильмами. Фигму он не заменяет. Ну разве что анимации какие-то попробовать реализовать?
Прототипы делать для тестов, перед тем как отдавать в "реальную" разработку. С другой стороны, если дизайнер понимает React настолько, чтобы делать достаточно сложные прототипы в Framer то тогда, сам Framer становится лишним лучше сразу делать все на реакте.
Если проект уже на ходу и юзает реакт, можно импортировать компоненты, которые делали разработчики. Они занимаются своими вещами, а ты набрасываешь прототип на готовой дизайн-системе и идёшь в полевые исследования.
А так в продуктах много лишних прослоек, особенно это касается менеджмента, поэтому фреймер не кажется уж таким бесполезным)))
Не думаю, что он бесполезный. Скорее кажется избыточным — фрэймворк для фрэймворка
Возможно, посмотрим, что создатели будут делать с ним дальше. Пока я просто наблюдаю и экспериментирую, вещь-то интересная.
Ты работаешь в крупном продукте, задизайнил новую фичу и хочешь провести исследование: понятна ли эта функция, что можно улучшить? Затягиваешь данные из базы своей компании, отдаёшь прототип ресёчеру, и он идёт опрашивать пользователей.
Есть ещё несколько небольших применений, но этот момент мне больше всего понятен. Насчёт анимаций - сложно, насчёт дизайна - фигма бежит намного быстрее в плане разработки нового функционала, чем фреймер. Так что затягиваемся компоненты из фигмы и исследуем, юху!)
А когда ты дизайнишь макеты в фигме, реальными данными их не заполняешь? Только вайрфреймы делаешь? В фигме вроде как достаточно инструментов прототипирования, чтобы что-то потестить. Не совсем понимаю просто, чем прототипы во фреймере лучше чем в фигме. Двойная работа получается. Ну, шрифты не искажаются так сильно может быть.
Вот я и говорю, что заполнять дизайн в фигме оооочень долго. Мы недавно коллеге помогали заполнять один раздел всей дизайн командой, потому что там было около 400-500 изображений, она бы просто там утонула в фотостоках)) Да, сейчас появляются плагины, тот же ансплэш, но мне было интересно попробовать сделать что-то самому «на плагины надейся, а сам не плошай»
Как сказал один дизайнер: Framer - это инструмент о котором все говорят, но толком никто не знает что с ним делать.
Парни ищут себя просто)) А мы смотрим со стороны за этой движухой
Кто знает — тот пользуется и особо не афиширует. Зачем у себя же хлеб отбирать.
Блин, придётся поиграться. Люблю, когда можно сделать что-то новенькое и весь процесс уже разжеван — остаётся проглотить
Закидывай потом ссылку на проект, посмотрим, что получилось :D
А зачем две строки импорта из реакта?
Ой, честно, в эту тему не сильно погружался, но как я понял: * as React from "react" – это полноценный модуль, а { some thing } from "react" – разворачивание его отдельных частей. А отдельные части модуля и модуль импортируются по разному, от того и запись в две строки.
Сам Реакт нужен чтобы работал JSX (реакто-специфичная смесь JS и HTML) , ну а отдельные функции используются в коде.
Это записывается в одну строку: import React, { useState } from 'react';
Во, спасибо за разъяснение, в следующий раз так и буду писать)
Все-таки кодеры народ усидчивый и терпеливый жесть, я даже до конца не осилил дочитать, дочитать, а Вы тут такое расписали..
На анимации в превью код с ошибкой. Data масив, а из него вытаскивается картинка, рейтинг. А так, в будущем только такой дизайн через код и будет
В анимации я супер абстрактно показал код, просто для динамичной обложки) А так там распределение и рейтинга и имени есть тоже шагом ранее, присмотрись))
Ты уже готовишься к судному дню, когда без кода ты никто?))
Круто, что дизайнеры осваивают код и пишут такие туториалы. Сам таким занимался (спойлер: стал разработчиком).
Но нужно понимать, что тут пропущено очень много промежуточных шагов и код используется скорее как волшебная палочка. Я понимаю почему это сделано, сложно в обзорной статье расписать что именно делает useEffect и почему вообще нужно выносить сайд-эффекты из рендера.
Читатель повторить туториал сможет, а сделать что-то свое (например, обновлять данные каждые 5 секунд) — уже нет.
Это не упрек автору, скорее пространное ворчание по поводу количества слоев абстракции и адской кривой обучения.
Дааа, многие вещи пришлось сильно так подсократить по многим причинам. На то подобные статьи и обзорные, чтобы лишь зацепить дизайнеров идеей {ideaName}, чтобы они потом шли дальше разбирались и ковырялись в исходниках. По сути так со мной и было: увидел официальный короткий туториал, из которого нифига не понятно, пошёл сам додумывать и пробовать. Надеюсь, мне удасться зацепить кого-то так же, как меня когда-то)