Responsive что это за программа

Адаптивный движок Bubble

В конце июня 2022 года Bubble официально анонсировал свой новый Responsive Engine — движок для быстрого и простого создания качественной адаптации веб-приложений на всех устройствах. Разберёмся, как его использовать.

Разработчик создаёт элементы (кнопки, текстовые блоки, формы) и помещает их в контейнеры. Для контейнеров устанавливаются настройки, и все элементы внутри них ведут себя согласно этим настройкам.

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

Полное руководство по Adaptive/Responsive верстке

Четыре типа контейнеров

Настройка макета-контейнера в бабле называется Container layout. Её можно найти в отдельной вкладке по клику на элемент в настройках. Эта вкладка и появилась с нововведением.

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

Есть четыре типа Container layout — Row, Column, Fixed, Allign to parent.

• Row — строка. Дочерние элементы в контейнере выстраиваются горизонтально при растягивании экрана.

• Column — колонка. Элементы будут растягиваться или сдвигать вниз другие элементы при изменении размеров экрана.

• Fixed — элемент внутри такого контейнера останется фиксированного размера при изменении размеров экрана.

• Allign to parent — элементы будут выравниваться внутри контейнера относительно выбранного края. Доступно позиционирование по 9 позициям внутри контейнера.

Выбор типа контейнера — лишь часть настроек. Второй важный этап — работа с отступами, полями и расстояниями между элементами. Чтобы добавить воздуха между элементами и дать возможность интерфейсу дышать, важно поработать с расстояниями между объектами.

Где настраивать и как подключить адаптив в свой проект

Все новые проекты в бабле с релиза Responsive Engine автоматически создаются на новом движке. А вот если у вас есть старые проекты, то надо произвести некоторые манипуляции.

Responsive design: Отзывчивый макет

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

Подключить движок можно по кнопке «Upgrade responsive» во вкладке «Responsive». Программа создаст копию страницы-экрана — эдакий бекап, чтобы можно было откатиться к первой версии, если что-то поломается.

А сама настройка контейнеров происходит во вкладке «UI Builder», а смотреть, что получается надо во вкладке «Responsive».

Где попробовать и изучить Responsive Engine Bubble

Чтобы лучше понять, как работает новый движок, полезно изучить теорию — и затем скорей переходить к практике, чтобы «набить руку» и уверенно чувствовать себя в работе с адаптивом.

• Для начала стоит прочитать документацию по теме респонсива. Соответсвующая глава появиласьв мануале Bubble.
• Следом можно посмотреть краткие видеоинструкции на YouTube. Есть мини-ролик по настройке каждого типа контейнераRow,Column,Align to Parent.
• Попрактиковаться в настройках адаптивности в проекте можно на специальном темплейтеBubble Responsive Game. Тут нужно настроить каждый контейнер с элементами по прописанному заданию и посмотреть, как работает новый движок.

Источник: codebreakers.tech

Как продлить автономность Android, отключив только одну функцию

Наверное, каждый из нас, независимо от смартфона и ёмкости аккумулятора, пытается сберечь его ресурс и растянуть зарядку как можно дольше. Даже если у вас Galaxy S20 Ultra с батарейкой на 5000 мА*ч и высочайшей энергоэффективностью, скорее всего, для вас является вопросом чести вытянуть из него хотя бы лишние 20-30 минут. Добиться этого можно разными способами – от перевода смартфона в режим энергосбережения до отключения беспроводных интерфейсов и понижения частоты обновления экрана. Но почти всегда это компромисс, с которым приходится мириться. Однако есть такой способ, который и зарядку сэкономит, и вас не ограничит.

Увеличить автономность смартфона можно отключением одной незначительной функции

Я говорю о функции адаптивных уведомлений, которая впервые появилась в четвёртой бета-версии Android 10 около года назад. Эта функция позволяла смартфону самому анализировать важность входящих уведомлений и задавать им приоритет для последующей выдачи пользователю.

Как отключить адаптивные уведомления

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

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

• Перейдите в «Настройки» и откройте раздел «Приложения»;
• Нажмите на три вертикальные точки в правом верхнем углу;

Отключите адаптивные уведомления, и автономность возрастёт

• В выпадающем окне выберите «Особые права доступа»;
• Выберите «Адаптивные уведомления» и отключите этот пункт.

По умолчанию в Android функция адаптивных уведомлений появилась с выходом Android 11. Но это касается только тех смартфонов, у которых этой фишки раньше не было. Дело в том, что многие производители не стали дожидаться Google и внедрили адаптивные уведомления в свои прошивки сами.

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

Увеличение автономности Android

Прирост автономности будет зависеть от вашего сценария использования

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

Насколько сильно изменится автономность вашего смартфона после отключения функции адаптивных уведомлений, однозначно сказать сложно. Это зависит от множества индивидуальных показателей, характерных для одних пользователей и не характерных для других – от ёмкости аккумулятора до количества уведомлений, которые вы получаете в течение дня.

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

Как бы там ни было, рассчитывать на кардинальный прирост во времени работы смартфона без подзарядки не стоит. Максимум, что можно ожидать, — это дополнительные 3-5% от предыдущих показателей автономности. Но, учитывая, что некоторые аппараты в режиме повышенного энергосбережения могут протянуть на таком остатке энергии даже целый день, отключение адаптивных уведомлений может иметь смысл.

• Android 11
• Новичкам в Android

Источник: androidinsider.ru

Респонсивный Vs адаптивный дизайн: что лучше для пользователя?

Современные веб-разработчики и маркетологи все чаще отдают предпочтение респонсивному дизайну (responsive design), позволяющему создать страницу, доступную для просмотра на любом устройстве. И хотя такой подход достаточно хорош с точки зрения Google, который «любит» респонсивные сайты — это далеко не единственный вариант, способный приспосабливаться под нужды пользователя.

Так называемый адаптивный дизайн (adaptive design) появился отнюдь не вчера, но всерьез о нем заговорили лишь недавно, благодаря тем усовершенствованиям, которые он способен привнести в пользовательский опыт.

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

Респонсивный веб-дизайн

Респонсивный веб-дизайн — это масштабирование интерфейса под устройство пользователя за счет media-queries, или модуля CSS3, позволяющего задавать разные стили (или даже таблицы стилей) в зависимости от разрешения экрана, его размеров и прочих характеристик.

Применение данного метода лучше подходит для сайтов с гибкой, или «резиновой» структурой. В противном случае разработчики потратят кучу времени и ресурсов на переделывание сайта под планшет и мобильный телефон, чтобы компенсировать имеющийся недостаток гибкости.

Помимо своей изменяющейся структуры, у респонсивного дизайна есть несколько других преимуществ:

1. Одинаковый внешний вид ресурса в разных браузерах и на различных платформах
2. Наличие у сайта одинакового URL, что способствует SEO-оптимизации
3. Разработчикам необходимо обслуживать лишь один сайт, что позволяет сократить время, затрачиваемое на дизайн и контент

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

Если вы делаете выбор в пользу респонсивного подхода, ваши дизайнеры всегда будут ограничены этим фактором, так как сложные визуальные элементы могут «тормозить» загрузку на мобильных устройствах.

Адаптивный веб-дизайн

Адаптивный дизайн функционирует немного иначе. Он сегментирует пользователей на категории в зависимости от того, с какого устройства они просматривают сайт.

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

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

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

Иными словами, сервер берет на себя всю «тяжелую» работу, вместо того, чтобы заставлять сайт оптимизировать самого себя. Среди достоинств адаптивного дизайна можно выделить следующие:

1. Изображения загружаются намного быстрее, так как они сжимаются и адаптируются под устройство пользователя
2. Загрузка сайта происходит быстрее, так как сервер определяет тип устройства пользователя и загружает соответствующий ему программный код
3. Разработчики пользуются свободой творчества, ведь они могут создавать различные версии сайтов и подгонять их под соответствующие типы устройств, чтобы сделать их более удобными для мобильных пользователей.

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

Какой вариант и для чего подходит?

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

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

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

Для простых лендингов или сайтов, которые прекрасно загружаются на мобильных устройствах, респонсивный дизайн станет оптимальным решением. Их владельцам стоит рассматривать создание адаптивного ресурса как вариант на будущее.

Источник: lpgenerator.ru

Адаптивный или отзывчивый? Разбираем структуру React-компонентов

В этой статье мы разберёмся, в чем сложность написания адаптивных компонентов, поговорим о code-splitting-е, рассмотрим несколько способов организации структуры кода, оценим их достоинства и недостатки и попытаемся выбрать лучший из них (но это не точно).

Сначала давайте разберемся с терминологией. Мы часто слышим термины adaptive и responsive. Что они означают? Чем отличаются? Как это относится к нашим компонентам?

Adaptive (адаптивный) — это комплекс визуальных интерфейсов, созданных под конкретные размеры экрана. Responsive (отзывчивый) — это единый интерфейс, который подстраивается под любой размер экрана.

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

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

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

Я сосредоточусь на двух сферах отображения интерфейсов — мобильной и десктопной. Под мобильным отображением мы будем подразумевать ширину, например, ≤ 991 пикселей (само число не принципиально, это просто константа, которая зависит от вашей дизайн-системы и вашего приложения), а под десктопным отображением — ширину больше выбранного порога. Я намеренно пропущу отображения для планшетов и широкоформатных мониторов, потому что, во-первых, не всем они нужны, а во-вторых, так будет проще излагать. Но паттерны, про которые мы будем говорить, расширяются одинаково для любого количества «отображений».

Также я почти не буду говорить про CSS, в основном речь пойдет о компонентной логике.

Коротко расскажу о нашем стеке в Юле, чтобы понятно было, в каких условиях мы создаем наши компоненты. Мы используем React/Redux, работаем в монорепе, используем Typescript и пишем CSS на styled-components. В качестве примера давайте рассмотрим три наших пакета (пакеты в концепции монорепы — это связанные между собой NPM-пакеты, которые могут представлять собой отдельные приложения, библиотеки, утилиты или компоненты — степень декомпозиции вы выбираете сами). Мы рассмотрим два приложения и одну UI-библиотеку.

Далее мы рассмотрим написание адаптивных компонентов на примере этих пакетов. Но сначала нужно разобраться с isMobile .

Определение мобильности isMobile

import React from ‘react’ const App = (props) => < const < isMobile >= props return ( > ) >

Прежде чем начинать писать адаптивные компоненты, нужно научиться определять «мобильность». Eсть множество способов реализации определения мобильности. Я хочу остановиться на некоторых ключевых моментах.

Определение мобильности по ширине экрана и по user-agent

Большинство из вас хорошо знает, как реализовать оба варианта, но давайте коротко пробежимся по основным моментам еще раз.

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

1. Создаем константы с граничными точками и сохраняем их в теме (если ваше CSS-решение позволяет). Сами значения могут быть такими, какие ваши дизайнеры посчитают наиболее подходящими для вашей UI-системы.
2. Сохраняем текущий размер экрана в redux/mobx/context/any-источнике данных. Где угодно, лишь бы у компонентов и, желательно, у прикладной логики был доступ к этим данным.
3. Подписываемся на событие изменения размера и обновляем значение ширины экрана на то, которое будет вызывать цепочку обновлений дерева компонентов.
4. Создаем простые вспомогательные функции, которые с помощь ширины экрана и констант вычисляют текущее состояние ( isMobile , isDesktop ).

const breakpoints = < mobile: 991 >export const state = < ui: < width: null >> const handleSubscribe = () => < state.ui.width = window.innerWidth >export const onSubscribe = () => < window.addEventListener(‘resize’, handleSubscribe) >export const offSubscribe = () => window.removeEventListener(‘resize’, handleSubscribe) export const getIsMobile = (state: any) => < if (state.ui.width return false > export const getIsDesktop = (state) => !getIsMobile(state) export const App = () => < React.useEffect(() => < onSubscribe() return () =>offSubscribe() >, []) return > const MyComponent = (props) => < const < isMobile >= props return isMobile ? : > export const MyComponentMounted = anyHocToConnectComponentWithState( (state) => (< isMobile: getIsMobile(state) >) )(MyComponent)

При изменении экрана значения в props для компонента будут обновляться, и он станет корректно перерисовываться. Есть множество библиотек, которые реализуют эту функциональность. Кому-то будет удобнее использовать готовое решение, например, react-media, react-responsive и т.д., а кому-то проще написать своё.

В отличие от размера экрана, user-agent не может динамически меняться во время работы приложения (строго говоря, может, через инструменты разработчика, но это не пользовательский сценарий). В этом случае нам не нужно использовать сложную логику с хранением значения и пересчётом, достаточно единожды распарсить строку window.navigator.userAgent, сохранить значение, и готово. Есть куча библиотек, которые помогут вам в этом, например, mobile-detect, react-device-detect и т.д.

Подход с user-agent проще, но использовать только его недостаточно. Любой, кто серьезно разрабатывал адаптивные интерфейсы, знает про «магический поворот» iPad-ов и подобных ему девайсов, которые в вертикальном положении попадают под определение мобильных, а в горизонтальном — десктопных, но при этом имеют user-agent мобильного устройства. Также стоит отметить, что в рамках полностью адаптивно/отзывчивого приложения по одной лишь информации о user-agent невозможно определить мобильность, если пользователь использует, например, десктопный браузер, но сжал окно до «мобильного»размера.

Также не стоит пренебрегать информацией о user-agent . Очень часто в коде можно встретить такие константы, как isSafari , isIE и т.д., которые обрабатывают «особенности» этих устройств и браузеров. Лучше всего комбинировать оба подхода.

В нашей кодовой базе мы используем константу isCheesySafari , которая, как следует из названия, определяет принадлежность user-agent к семейству браузеров Safari. Но помимо этого у нас есть константа isSuperCheesySafari , которая подразумевает под собой мобильный Safari, соответствующий iOS версии 11, который прославился множество багов вроде такого: https://hackernoon.com/how-to-fix-the-ios-11-input-element-in-fixed-modals-bug-aaf66c7ba3f8.

export const isMobileUA = (() => magicParser(window.navigator.userAgent))() import isMobileUA from ‘./isMobileUA’ const MyComponent = (props) => < const < isMobile >= props return (isMobile || isMobileUA) ? : >

А что с media-запросами? Да, действительно, в CSS есть встроенные инструменты для работы с адаптивностью: медиа-запросы и их аналог, метод window.matchMedia . Их можно использовать, но логику «обновления» компонентов при изменении размера всё равно придется реализовывать. Хотя лично для меня использование синтаксиса media-запросов вместо привычных операций сравнения в JS для прикладной логики и компонентов — это сомнительное преимущество.

Организация структуры компонента

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

import < Panel, Cell, Content, afterBorder >from ‘./styled’ import Group from ‘./Group’ import Button, < IMobileListButtonProps >from ‘./Button’ import ContentOrButton, < IMobileListContentOrButton >from ‘./ContentOrButton’ import Action, < IMobileListActionProps >from ‘./Action’ export default < Panel, Group, Cell, Content, Button, ContentOrButton, Action >export

Этот компонент, помимо очень вербозного экспорта, представляет из себя список с данными, разделителями, группировками по блокам и т.д. Наши дизайнеры очень любят этот компонент и повсеместно используют его в интерфейсах «Юлы». Например, в описании на страничке товара или в нашей новой функциональности тарифов:

И еще в N мест по всему сайту. Также у нас есть похожий компонент , который реализует эту функциональность списков для десктопного разрешения.

Мы для себя нашли очень удобным выносить все styled-component-ы для компонента в отдельный файл и импортировать их под неймспейсом S, чтобы отделить в коде от других компонентов: import * as S from ‘./styled’ . Соответственно, «S» представляет собой объект, ключи которого — это названия styled-component-ов, а значения — сами компоненты.

return ( > > /> > > /> /> : > : > )

Здесь isMobile — это зависимость компонента, на основании которой сам компонент внутри себя решит, какой интерфейс нужно отрендерить.

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

Давайте теперь немного абстрагируемся от «юловских» компонентов и рассмотрим подробнее такие два компонента:

vs

Структура папки и корневой файл index.ts:

./ComponentA — ComponentA.tsx — ComponentADesktop.tsx — ComponentAMobile.tsx — index.ts — styled.desktop.ts — styled.mobile.ts
import ComponentA from ‘./ComponentA’ import ComponentAMobile from ‘./ComponentAMobile’ import ComponentADesktop from ‘./ComponentADesktop’ export default

Благодаря уже не новой технологии tree-shaking webpack (или с помощью любого другого сборщика) можно отбросить неиспользуемые модули ( ComponentADesktop , ComponentACombined ), даже при таком реэкспортировании через корневой файл:

В финальный bundle попадет только код файла ./ComponentAMobile.

Компонент содержит в себе асинхронные импорты при помощи React.Lazy конкретной версии компонента || для конкретной ситуации.

Мы в «Юле» стараемся придерживаться паттерна единой точки входа в компонент через индексный файл. Это упрощает поиск и рефакторинг компонентов. Если содержимое компонента не реэкспортируется через корневой файл, то его можно смело редактировать, поскольку мы знаем, что он не используется вне контекста этого компонента. Ну и Typescript подстрахует в крайнем случае.

У папки с компонентом есть свой «интерфейс»: экспорты на уровне модуля в корневом файле, а его подробности реализации не раскрываются. В результате при рефакторинге можно не бояться сохранения интерфейса.

import React from ‘react’ const ComponentADesktopLazy = React.lazy(() => import(‘./ComponentADesktop’)) const ComponentAMobileLazy = React.lazy(() => import(‘./ComponentAMobile’)) const ComponentA = (props) => < const < isMobile >= props // какая то общая логика return ( > /> ) : ( /> )> ) > export default ComponentA

Далее компонент содержит в себе импортирование десктопных компонентов:

А компонент содержит импортирование мобильных компонентов:

Компонент адаптивный: по флагу isMobile может сам решить, какую версию отрисовать, умеет асинхронно загружать только требуемые файлы, то есть мобильные и десктопные версии могут быть использованы раздельно.

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

Вот структура папки. Корневой файл index.ts просто реэкспортирует ./ComponentB :

./ComponentB — ComponentB.tsx — index.ts — styled.ts
export < default >from ‘./ComponentB’

Файл ./ComponentB с самим компонентом:

Давайте попробуем прикинуть достоинства и недостатки этих компонентов.

Итого по три высосанных из пальца аргумента «за и против» для каждого из них. Да, я заметил, что некоторые критерии упомянуты сразу и в достоинствах, и в недостатках: это сделано намеренно, каждый сам вычеркнет их из неверной для себя группы.

Нужно обратить внимание на два важных момента.

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

Тут мы переходим к причине номер два, которая в скором времени, возможно, станет, или уже стала, основной проблемой больших веб-приложений. Многие уже догадались: да, речь идет о длительности парсинга.

Современные движки вроде V8 умеют кэшировать и результат парсинга, но это пока работает не очень эффективно. У Эдди Османи есть отличная статья на эту тему: https://v8.dev/blog/cost-of-javascript-2019. А ещё можно подписаться на блог V8: https://twitter.com/v8js.

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

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

Также советую банально присмотреться к компоненту. Если UI мобильного и десктопного варианта сильно различаются между собой, то, возможно, их стоит разделить, сохранив некую общую логику в одном месте. Это позволит избавиться от боли при написании сложного CSS, проблем с ошибками в одном из отображений при рефакторинге или изменении другого. Ну и наоборот, если UI максимально близок, то зачем делать лишнюю работу?

Заключение

Подытожим. Мы разобрались в терминологии адаптивного/отзывчивого интерфейса, рассмотрели несколько способов определения мобильности и несколько вариантов организации структуры кода адаптивного компонента, выявили достоинства и недостатки каждого. Наверняка много из перечисленного было вам и так уже известно, но повторение — лучший способ закрепления. Надеюсь, что вы узнали что-нибудь новое для себя. В следующий раз мы хотим опубликовать сборник рекомендаций по написанию прогрессивных веб-приложений, с советами по организации, переиспользованию и поддержанию кода.

• Блог компании Юла
• Интерфейсы
• ReactJS

Источник: habr.com