Как дизайнеру оседлать четыре строчки кода и больше никогда не загружать картинки для интерфейса: гайд по Framer X

Очередной раз ищем неочевидные пути, как ускорить рутинные процессы для дизайнеров интерфейсов. Сегодня разберём знакомую для многих боль — подбор контента для нарисованных экранов и/или потеря контента при обновлении компонентов.

Как обычно это происходит?

Вот сделал ты главную онлайн-кинотеатра. Чтобы наполнить его контентом, тебе придётся сходить на «Кинопоиск» и отобрать фильмы, которые будут «достойны» красоваться в твоём приложении. Потратил время, всё красиво, но через пару дней ты решишь чуть-чуть изменить компонент и у тебя случайно послетали все картинки. Ладно один экран, не так обидно, но если их сотни?

Рубрика «Э-э-эксперименты»

Предлагаю другой путь. Что если не скачивать картинки для каждого отдельного фильма, а просто вставить ссылку на сайт, чтобы картинки сами позалетали в твои дизайны?

А что, так можно было?

Вообще да, но есть маленькое но... Figma сегодня мы открывать не будем. Прошу любить и жаловать, Framer X – наш сегодняшний конь, которого мы и будем седлать. Если ты ещё не в курсе, это такой инструмент для дизайнеров, в котором ещё можно немного поковырять код. В умелых руках это нереальная вещь, поэтому я пытаюсь её изучать :D

​Вот такого монстра мы сегодня напишем

Страшно, дизайнер? Не переживай, тут всё не так жёстко, как ты думаешь (даже если ты никогда не тыкался в коде). Вот всё что нам нужно:

Те самые четыре строчки​

Да, именно из-за этих строчек весь сыр-бор. Это описанный запрос к базе данных с фильмами, именно оттуда мы и будем получать картинки, тексты и другие штуки, чтобы наш дизайн сразу был законченным. Больше никаких заглушек!

Ну что, погнали дизай...кхм...кодить

Надеюсь, ты уже скачал Framer. Вот ещё мой файлик с проектом, можешь параллельно сверяться с ним.

Для начала нам нужен сам компонент карточки фильма. Framer похож на любой другой дизайн-инструмент, поэтому сложностей с отрисовкой карточки быть не должно.

Для удобочитаемости компонент сразу с контентом, но у тебя может быть обычный заглушенный серый квадрат :)

Самоё лёгкое позади. Теперь нужно взять откуда-то данные для карточек фильмов. Тут нужно познакомиться с API. Эта штука позволяет «стучаться» к базе данных и просить у неё всякое разное.

Обращение к базе: «Заткнись и дай мне постеры для фильмов​»

Я нашёл сайт с каталогом API на любой вкус и цвет, подойдёт для любого приложения. Для нас тут есть огромная база с фильмами от IMDb.

Тут всё сложновато, на первый взгляд, поэтому к этому сайту вернёмся в конце статьи, когда разберёмся с основами. А пока будем тренироваться на сайте от самого Framer. Тут можно один раз вручную создать JSON-файлик с данными, чтобы потом его переиспользовать. Я заранее создал набор фильмов для этой статейки, поэтому тебе заморачиваться не придётся.

Я упомянул 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 таким образом.

​Делаем запрос через апи IMDb из начала статьи

В параметре headers укажи то, что указано в сопровождающей информации к API, обычно все описывают, как работать с запросами к базе, так что просто внимательно читай документацию. Ключ, если что, находится здесь.

​Ключ покажется только у зарегистрированных пользователей

Готово, ковбой, Framer X осёдлан

Надеюсь, я всё понятно описал, но если будут вопросы, задавай их в комментариях или в личку telegram. Также не забывай про файл-исходник, потыкайся в нём, если не хочешь писать всё сам, но тебе интересно посмотреть.

@evgn_design – мой канал в телеграм для тех, кому мало хардкора. Там всякая подобная писанина про компоненты, дизайн-системы и процессы. Залетай!

0
47 комментариев
Написать комментарий...
Aleksandr Barantsev

Слишком длинная инструкция как оседлать 4 строчки кода )

Ответить
Развернуть ветку
Женя Иванов
Автор

Всего 4 строчки, но как брыкаются)
Я пытался сократить, но это оказалось импосибл. Всё хотел затронуть, чтобы максимум вопросов отсечь)

Ответить
Развернуть ветку
krakendesign

Вещь интересная, но зачем дизайн-макетам (которые созданы для того что-бы показать структуру компонентов) подтягивать какие-то данные с каких-то АПИ? Бесполезная игрушка получается, а так потыкаться можно да 👍

Ответить
Развернуть ветку
Женя Иванов
Автор

Согласен, у меня это пока эксперименты, но вообще у этого большой потенциал в двух моментах:
1) Исследования пользователей, там контентом обязательно нужно заполнить все макеты
2) Проверка дизайн макетов (частенько реальные фото и текста выглядят в сервисе не так читаемо, как в макетах из-за нерандомной выборки дизайнером)

Ответить
Развернуть ветку
Mark Rapida Gromov

сейчас дизайнеры должны работать с реальными данными. А ещё желательно показать, как приложение должно работать со всеми возможными сценариями.

Ответить
Развернуть ветку
Max Zarubin

А у меня у одного возникает вопрос что нужно сделать с компонентом в фигме что бы полетели все картинки? Первый раз такое слышу

Ответить
Развернуть ветку
Женя Иванов
Автор

Защита от дураков никогда не помешает :D
На практике, в больших китах часто что-то происходит, особенно, когда инструменты (фигма, скетч и другие) добавляют какие-то новые штуки, которые хочется добавить в кит, например авто лэйауты для множества компонентов.

Ответить
Развернуть ветку
Max Zarubin

Ну у меня бывает подлагивает фигма что все блоки съезжают или исчезают куда-то, но это пока не кликнешь по нему и это то это все если 100500 уровней автолейаутов в 5 слоев компонентов завернуть. А вот чтоб фотки пропадали

Ответить
Развернуть ветку
Женя Иванов
Автор

Подумал немного, наверное зря я написал это, ты прав, проблема достаточно сложновоспроизводимая, в следующий раз постараюсь не притягивать за уши что-то)

p.s. Перестал замечать «прыгающие» компоненты, может уже починили?

Ответить
Развернуть ветку
Vieux Nor

Все-таки кодеры народ усидчивый и терпеливый пздец, я даже до конца не осилил дочитать, дочитать, а Вы тут такое расписали..

Ответить
Развернуть ветку
Женя Иванов
Автор

Я не кодер, а продуктовый дизайнер. Мне тоже было сложно, поверь :D

Ответить
Развернуть ветку
Pixel Lens

Нехороший ты человек автор, я вот сознательно не лезу в код, чтобы не лишать разработчиков заработка; твои методы оббезработят половину айтишников, стыд!

Кроме шуток, я так заебался искать код для разработчиков что думаю когда уже сделают дизайн-макеты полностью на основе реального кода для разных систем (веб, мобилы), чтоб нахуй выкинуть всяких чсвшных бездарей из своей индустрии

Ответить
Развернуть ветку
Женя Иванов
Автор

Привет, Pixel, знакомые лица :)
Не думаю, что подобные инструменты заменят разрабов или дизайнеров. Как по мне эта штука наоборот приучает всех общаться на одном языке, и это круто!

Не совсем понял про код для разработчиков?)) А для кого он ещё?)

Ответить
Развернуть ветку
Pixel Lens

Напомни откуда знакомы?

Да в том-то и дело, что код - для разработчиков, а мне дизайнеру часто приходится самостоятельно в него лезть, когда разработчики ноют что чёт нельзя сделать.

Думаю за инструментами типа фреймера будущее, но таки надеюсь что верх возьмёт фигма и ее тотальная автоматизация) Типа задизайнил приложеньку, указал что и как себя ведёт, кликнул кнопарь "опубликовать в стор" и плотоядно потираешь ручки :)

Ответить
Развернуть ветку
Женя Иванов
Автор

Мне кажется, в сторону твоих мечт будет идти как раз фреймер. Фигма ближайшие 5-10 лет будет разрабатываться для больших компаний, чтобы заработать денег, а там нужна командная работа и вот это вот всё)

Мы с тобой не знакомы, но я помню тебя по комментам под другой моей статьёй «ячейки на auto layout в фигме», ты там тоже жаловался на разработчиков :D

Ответить
Развернуть ветку
Pixel Lens

Лол, да, похоже на меня! Как только разработчики станут грамотнее я прям статью запилю о том, как я стал счастлив)))

Ответить
Развернуть ветку
Yury

Разработчики грамотны (в том что касается дизайна) ровно настолько,  насколько хорошо с ними налажены отношения. Так то большинство актуальных новшеств в инструментах дизайна пришли как раз из области разработки (reusable components и overrides,  распределенный контроль версий,  тот же auto layout). Часто между дизайнерами и разработчиками пропасть — первые не имеют представления как устроена система для которой они проектируют интерфейсы, ограничения, возможности, best practices. 

Ответить
Развернуть ветку
Pixel Lens

Разработчики грамотны настолько, насколько им позволяет им ЧСВ. Часто оно ограничивает: "я технарь, я самый умный, это точно нельзя сделать". Я: "вот готовый код, не пизди, а делай!"

Ответить
Развернуть ветку
Женя Иванов
Автор

Если не секрет, где ты работаешь?)

Ответить
Развернуть ветку
Pixel Lens

Компанию не раскрою, а индустрия - интернет вещей: клиентская часть и админки операторов. 
+ шабашки, куда без них.
А ты?)

Ответить
Развернуть ветку
Женя Иванов
Автор

Я поработал в маленькой региональной студии, потом в небольшом стартапе и сейчас, в крупной компании, нигде не было такого, чтобы прям хейтили друг друга в команде

Ответить
Развернуть ветку
Yury

Тоже такое встречал, но видимо везло и такое было не часто. Обычно получалось совместно разобраться. Но по негативному опыту могу сказать, что он был не из за ЧСВ а скорее из за консервативности и возможно лени, когда проще натянуть дизайн на знакомый фрэймворк при помощи костылей, чем подумать сделать кастомное решение.

Ответить
Развернуть ветку
Pixel Lens
скорее из за консервативности и возможно лени

Я таки делаю вывод, что эти качества проистекают именно из ЧСВ. В это легко поверить после общения с человеком - такие ленивые консерваторы как правило знают всё лучше других по жизни. 

Ответить
Развернуть ветку
Женя Иванов
Автор

А ты со своей стороны как с ними общаешься? Выполняешь ли «дизайнерский долг»?

Ответить
Развернуть ветку
Женя Иванов
Автор

Согласен, видел только такую форму дисконекта с разработчиками, но чтобы они смотрели на дизайнеров, как на говно? Ну такое :)

Ответить
Развернуть ветку
Artem Milovanov

Не совсем понятно где и как применять фреймер, если мы не делаем очередное приложение с фильмами. Фигму он не заменяет. Ну разве что анимации какие-то попробовать реализовать? 

Ответить
Развернуть ветку
Yury

Прототипы делать для тестов, перед тем как отдавать в "реальную" разработку.  С другой стороны, если дизайнер понимает React настолько, чтобы делать достаточно сложные прототипы в Framer то тогда, сам Framer становится лишним лучше сразу делать все на реакте. 

Ответить
Развернуть ветку
Женя Иванов
Автор

Если проект уже на ходу и юзает реакт, можно импортировать компоненты, которые делали разработчики. Они занимаются своими вещами, а ты набрасываешь прототип на готовой дизайн-системе и идёшь в полевые исследования.
А так в продуктах много лишних прослоек, особенно это касается менеджмента, поэтому фреймер не кажется уж таким бесполезным)))

Ответить
Развернуть ветку
Yury

Не думаю, что он бесполезный.  Скорее кажется избыточным — фрэймворк для фрэймворка 

Ответить
Развернуть ветку
Женя Иванов
Автор

Возможно, посмотрим, что создатели будут делать с ним дальше. Пока я просто наблюдаю и экспериментирую, вещь-то интересная.

Ответить
Развернуть ветку
Женя Иванов
Автор

Ты работаешь в крупном продукте, задизайнил новую фичу и хочешь провести исследование: понятна ли эта функция, что можно улучшить? Затягиваешь данные из базы своей компании, отдаёшь прототип ресёчеру, и он идёт опрашивать пользователей.

Есть ещё несколько небольших применений, но этот момент мне больше всего понятен. Насчёт анимаций - сложно, насчёт дизайна - фигма бежит намного быстрее в плане разработки нового функционала, чем фреймер. Так что затягиваемся компоненты из фигмы и исследуем, юху!)

Ответить
Развернуть ветку
Artem Milovanov

А когда ты дизайнишь макеты в фигме, реальными данными их не заполняешь? Только вайрфреймы делаешь? В фигме вроде как достаточно инструментов прототипирования, чтобы что-то потестить. Не совсем понимаю просто, чем прототипы во фреймере лучше чем в фигме. Двойная работа получается. Ну, шрифты не искажаются так сильно может быть.

Ответить
Развернуть ветку
Женя Иванов
Автор

Вот я и говорю, что заполнять дизайн в фигме оооочень долго. Мы недавно коллеге помогали заполнять один раздел всей дизайн командой, потому что там было около 400-500 изображений, она бы просто там утонула в фотостоках)) Да, сейчас появляются плагины, тот же ансплэш, но мне было интересно попробовать сделать что-то самому «на плагины надейся, а сам не плошай»

Ответить
Развернуть ветку
Eugene Kovalenko

Как сказал один дизайнер: Framer - это инструмент о котором все говорят, но толком никто не знает что с ним делать.

Ответить
Развернуть ветку
Женя Иванов
Автор

Парни ищут себя просто)) А мы смотрим со стороны за этой движухой

Ответить
Развернуть ветку
Mark Rapida Gromov

Кто знает — тот пользуется и особо не афиширует. Зачем у себя же хлеб отбирать.

Ответить
Развернуть ветку
Артём Кокшаров

Блин, придётся поиграться. Люблю, когда можно сделать что-то новенькое и весь процесс уже разжеван — остаётся проглотить

Ответить
Развернуть ветку
Женя Иванов
Автор

Закидывай потом ссылку на проект, посмотрим, что получилось :D

Ответить
Развернуть ветку
niknikzoom

А зачем две строки импорта из реакта?

Ответить
Развернуть ветку
Женя Иванов
Автор

Ой, честно, в эту тему не сильно погружался, но как я понял: * as React from "react" – это полноценный модуль, а { some thing } from "react" – разворачивание его отдельных частей. А отдельные части модуля и модуль импортируются по разному, от того и запись в две строки.

Ответить
Развернуть ветку
Alex Tewpin

Сам Реакт нужен чтобы работал JSX (реакто-специфичная смесь JS и HTML) , ну а отдельные функции используются в коде.

Это записывается в одну строку: import React, { useState } from 'react';

Ответить
Развернуть ветку
Женя Иванов
Автор

Во, спасибо за разъяснение, в следующий раз так и буду писать)

Ответить
Развернуть ветку
Vieux Nor

Все-таки кодеры народ усидчивый и терпеливый жесть, я даже до конца не осилил дочитать, дочитать, а Вы тут такое расписали..

Ответить
Развернуть ветку
Сергей Юсупов

На анимации в превью код с ошибкой. Data масив, а из него вытаскивается картинка, рейтинг. А так, в будущем только такой дизайн через код и будет

Ответить
Развернуть ветку
Женя Иванов
Автор

В анимации я супер абстрактно показал код, просто для динамичной обложки) А так там распределение и рейтинга и имени есть тоже шагом ранее, присмотрись))

Ты уже готовишься к судному дню, когда без кода ты никто?))

Ответить
Развернуть ветку
Alex Tewpin

Круто, что дизайнеры осваивают код и пишут такие туториалы. Сам таким занимался (спойлер: стал разработчиком).

Но нужно понимать, что тут пропущено очень много промежуточных шагов и код используется скорее как волшебная палочка. Я понимаю почему это сделано, сложно в обзорной статье расписать что именно делает useEffect и почему вообще нужно выносить сайд-эффекты из рендера.

Читатель повторить туториал сможет, а сделать что-то свое (например, обновлять данные каждые 5 секунд) — уже нет.

Это не упрек автору, скорее пространное ворчание по поводу количества слоев абстракции и адской кривой обучения.

Ответить
Развернуть ветку
Женя Иванов
Автор

Дааа, многие вещи пришлось сильно так подсократить по многим причинам. На то подобные статьи и обзорные, чтобы лишь зацепить дизайнеров идеей {ideaName}, чтобы они потом шли дальше разбирались и ковырялись в исходниках. По сути так со мной и было: увидел официальный короткий туториал, из которого нифига не понятно, пошёл сам додумывать и пробовать. Надеюсь, мне удасться зацепить кого-то так же, как меня когда-то)

Ответить
Развернуть ветку
44 комментария
Раскрывать всегда