Как работать с брейкпойнтами в Drupal 8?

Главные вкладки

Аватар пользователя marassa marassa 22 июня 2020 в 11:43

Наконец-то созрел сделать для сайта мобильную версию с раскладкой, отличающейся от десктопной. Вроде придумал как оно должно выглядеть, осталась сущая ерунда - реализовать.
Нужно спрятать пяток блоков если ширина вьюпорта меньше определенного порога и наоборот показать пару блоков, спрятанных в десктопной версии. Также нужно слегка менять главный шаблон страницы в зависимости от брейкпойнта.
Прочел вдумчиво документацию к ядерному модулю Breakpoint, которая называется "Working with breakpoints in Drupal", содержит многа букф про то как нарисовать красивый файл breakpoints.yml и ни одной буквы про то, как и где потом с этими брейкпойнтами собственно работать.
В условиях видимости блоков я никакой возможности сослаться на брейкпойнты не вижу.
Что я делаю не так?

Комментарии

Аватар пользователя marassa marassa 22 июня 2020 в 13:44

Я, конечно, гляну если никаких других вариантов не останется, но неужели действительно нет никакой внятной документации?

Аватар пользователя VasyOK VasyOK 22 июня 2020 в 20:59

Идея не прижилась. В 7ке был context_breakpoint. Работал, нормально без включенного кеширования. Вообще многое в context работает плохо.

Сейчас брейкпойнты добавляются в теме. https://www.youtube.com/watch?v=eW9Pks3sxaA
С блоки можно попытаться работать модулем block_breakpoint.
У меня не получилось. Ошибками при установке сыпет с моей экосистемой.

Аватар пользователя marassa marassa 22 июня 2020 в 21:24

Да, я уже понял, что на уровне блоков это не работает нормально, наверное нужно на уровне регионов, то есть определить специальные регионы для мобильной версии, и где-то в коде темы подставлять тот или иной шаблон с разными наборами регионов в зависимости от брейкпойнта. Осталось только понять как поймать этот самый брейкпойнт в php-коде темы.
Видео посмотрел - очередное 100500-е видео о том, как составить красивый файл breakpoints.yml, и ни слова о том как же этими брейкпойнтами воспользоваться в теме...

Аватар пользователя marassa marassa 22 июня 2020 в 22:34

Я глянул - модуль выпущен неделю назад, один пользователь, принцип действия: рендерятся все блоки, а потом ненужные вырезаются джаваскриптом на клиенте. Это не совсем то (а скорее совсем не то) о чем мечталось. И верный указатель что я хочу чего-то не того. Ещё бы кто-нибудь объяснил чего я должен хотеть. Неужели ни у кого нет необходимости вывести совершенно разные хедеры для десктопной и мобильной версии?

Аватар пользователя VasyOK VasyOK 22 июня 2020 в 22:47

Необходимость есть. Решается через @media... display: none;
Другие способы то с кешированием не дружат, то с ресайзом (поворот мобилы).

Аватар пользователя charOFF charOFF 22 июня 2020 в 23:40

Всё, что через модуль breakpoint, будет работать в конечном счете на клиенте. Breakpoint это только API чтобы передать информацию о брейкпоинтах допустим из темы в модули. А что потом делать с этим - уже задача других модулей. Например, встроенный модуль responsive_image формирует для картинок вместо тэг с набором изображений под эти брейкпоинты. В любом случае, breakpoint завязан на @media и решения на его базе будут работать в конечном счете на клиенте. Потому как на бэке информации о размерах экрана нет. В вашем случае, если вы хотите формировать разный ответ для мобил и для десктопа, нужно копать в сторону "mobile detect" модулей, которые по заголовкам User-agent пытаются распознать с какого устройства пришел запрос. Но как по мне, то адаптив лучше, чем разные версии для моб. и десктопа.

Аватар пользователя charOFF charOFF 23 июня 2020 в 8:48

Там же все равно размеры экрана считываются дажаваскриптом и сохраняются в куки. А потом уже да, на бэке работает контекст. Но это такое решение, компромиссное, я бы его не назвал элегантным. При первом заходе получается кук еще нет, надо грузить страницу, а потом сразу релоадить. И, допустим, при повороте устройства, если будет переход через брейкпоинт, тоже либо игнорировать это, либо перезагружать (в модуле есть такая опция). Но это как-то не юзер-френдли.
А модули, которые работают на распознавании user-agent есть, ищутся например по "mobile detect"

Аватар пользователя marassa marassa 23 июня 2020 в 11:37

Всем спасибо, вроде улеглось в голове. Видимо придется всё гнать на клиента, а там ненужное прятать. Модули типа mobile detect (их не так мало) посмотрел - они либо вовсе не перенесены на восьмерку, либо используются на восьмерке мизерным количеством сайтов, что опять же говорит что я хочу чего-то не того Wink

Аватар пользователя bsyomov bsyomov 23 июня 2020 в 13:21

Может быть, те блоки, которые можно не показывать на мобильной версии, можно и вовсе не показывать, и разгрузить таким образом интерфейс? Smile И просто обойтись адаптивной вёрсткой?

Аватар пользователя marassa marassa 24 июня 2020 в 7:48

Ох. На это в двух словах и не ответишь Wink
Во-первых, сайт интенсивно использует большие фото и Гугл-карты, поэтому удобно и в полном объеме его возможностями можно воспользоваться только на большом экране. Работоспособная мобильная версия нужна а) для случаев, когда большого экрана нет под рукой и б), что более важно, для работы с сайтом непосредственно на местности, чтобы легко видеть где находится интересующий объект(ы) относительно пользователя. На десктопной версии на каждой странице отображается "карточка объекта" с текстовой информацией о нем и рядом с ней ЛИБО карта ЛИБО фотогалерея (переключается одним кликом). На мобильном экране нет места для всего этого, поэтому будет отображаться ЛИБО карточка ЛИБО карта ЛИБО фотогалерея (то есть уже три переключаемых "вью мода" а не два).
Далее, хедер десктопного сайта содержит 5 (прописью: пять) стандартных ядерных друпаловских блоков в полном соответствии с друпал-веем: большой логотип, переключатель языков, ссылки для логина/логаута/регистрации, постоянно видное главное меню и поле для поиска. На мобильном экране места для этого нет, поэтому будет узенькая "строка навигации" с маленьким лого, кнопками переключения "вью модов" карточка-карта-галерея и возможно полем для поиска, а все остальное, включая ещё и футер, будет убрано в выскакивающее меню под "тремя черточками".
Мне кажется в моем случае "один сайт для всех устройств" будет означать сайт, которым будет одинаково неудобно пользоваться на любом устройстве. Я вижу, что многие пошли по этому пути, но мне туда не хочется. Хотя очень может быть, что я чего-то не понимаю.

Аватар пользователя gun_dose gun_dose 24 июня 2020 в 8:17
1

А в чём проблема спрятать хэдер под три чёрточки? Там нужен только кусок js, который будет на мобиле переключать класс открыто/закрыто, а остальное стилями рулится.

Для картинок есть responsive image. С картой нужно что-то делать, но самое очевидное решение - такое же, как с шапкой. Сделать ссылку "подробнее", видимую только на мобиле и по клику на неё переключать класс, который будет показывать/скрывать на мобиле часть полей.

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

Аватар пользователя marassa marassa 24 июня 2020 в 8:26

gun_dose wrote: в чём проблема спрятать хэдер под три чёрточки?

Спрятать не проблема, но он в своём десктопном виде на мобиле смотрится как седло на корове.

gun_dose wrote: Для картинок есть responsive image

Да с картинками как таковыми нет проблем вообще.

gun_dose wrote: С картой нужно что-то делать, но самое очевидное решение - такое же, как с шапкой

Рендерить и отсылать на клиент, но не показывать гугл-карту - это кидать в печку ассигнации (мои кровные). Карта у меня выводится (и на десктопе в т.ч.) только по явному запросу юзера.

gun_dose wrote: можно подгружать всякие второстепенные блоки асинхронно через ajax

Сделать ВСЮ навигацию по сайту через AJAX у меня в планах, но не получается пока. А "второстепенных" блоков у меня на сайте нет - они все первостепенные, но на разных экранах должны либо выглядеть по-разному (хедер) либо выводиться в разной разметке и с разным алгоритмом переключения между ними (карточка/карта/галерея).

Аватар пользователя gun_dose gun_dose 24 июня 2020 в 9:08

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

А навигация через аякс нормально делается только на всяких реактах и вуях.

Аватар пользователя marassa marassa 24 июня 2020 в 9:26

Нет, с картой проблемы две:
1. Бесплатный порог у гугла стал очень низок, поэтому выходит очень дорого карту показывать всем подряд. Статистика показывает, что карта вообще мало кому нужна, большинство заходят картинки посмотреть. Но это собственно не имеет прямого отношения к мобильной теме, это только к тому, что вывести карту, но не показывать ее стоит очень дорого.
2. На мобильном экране просто не поместится мало-мальски юзабельная карта и что бы то ни было еще кроме строчки навигации. На десктопе/планшете легко выводится вполне юзабельная карта и еще информация об объекте сбоку. Сами по себе маркеры маленькие, и вообще без balloons/infowindows.

Для тотальной навигации через AJAX существует модуль Ajaxify Drupal, который даже почти работает, но возникает проблема с едиными на страницу settings'ами, которые надо как-то ювелирно менять при каждой замене каждого блока, чем данный модуль вообще не озабачивается, а самому мне это пока тяжело. Большим плюсом перевода всей навигации на ajax стала бы возможность инициализировать гугло-карту один раз на сессию, а потом просто динамически всё в ней менять хоть тыщу раз в процесе навигации - это у гугла (в отличие от "дешевых" альтернатив) бесплатно.

Реакты и вуи это круто, но я сейчас не готов взять и всё полностью переписать на них Wink

Аватар пользователя gun_dose gun_dose 24 июня 2020 в 9:28

marassa wrote: На мобильном экране просто не поместится мало-мальски юзабельная карта

Весьма спорное утверждение, посмотри, как это сделано на яндекс-картах.

Аватар пользователя marassa marassa 25 июня 2020 в 11:14

Ну конечно же я смотрел и яндекс-карты и гугл-карты.
Там центром всей парадигмы UI является именно карта. Которая либо занимает весь экран, либо можно выдвинуть снизу на половину экрана "карточку" текущего объекта, при этом от карты остается уже малоюзабельный огрызок, а карточка видна всё равно не вся, либо вытащить карточку на весь экран, тогда ей можно пользоваться, а карта уже не видна. Из карточки (и только из нее) можно посмотреть фото объекта.
У меня в первоначальной версии сайта, когда деревья еще были большими, а гугл-карты де-факто бесплатными, тоже была карта на каждой странице, а сбоку (всегда) небольшая карточка с информацией и одним тамбнейлом фото, кликнув на который можно было открыть лайтбокс и там листать фото, галереи как таковой не было.
Но сейчас всё не так - карту с каждой страницы пришлось убрать, заменив ее по умолчанию на фотогалерею, "карточка" осталась где была.
Ну не лезут на мобильный экран и полная карточка объекта и что бы то ни было еще. Сделать одну бесконечную скроллируемую страницу в модной ныне стилистике рулона туалетной бумаги тоже не получится, ибо и карта, и фотогалерея требуют скроллинга сами по себе. А когда на некоторых сайтах мне предлагают скроллировать карту двумя пальцами, мне хочется предложить предлагающему засунуть свои два пальца себе же в [censored] Wink

Аватар пользователя Punk_UnDeaD Punk_UnDeaD 25 июня 2020 в 15:04

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

Аватар пользователя marassa marassa 25 июня 2020 в 15:06

Punk_UnDeaD wrote: карту выгоднее делать скриншотом с активацией по клику

Порнография вообще выгодное дело, но я так делать не буду Wink

Аватар пользователя ivnish ivnish 28 июня 2020 в 12:45

На самом деле тоже теперь так делаю. Нет смысла дергать api карт для каждого посетителя, если картой будет пользоваться каждый двадцатый. А еще google pagespeed доволен)

Аватар пользователя marassa marassa 28 июня 2020 в 19:43

ivnish wrote:тоже теперь так делаю

Ох. Есть разница между страничкой "Эбаут ас" с маленькой картой фиксированного размера и пятнадцатью тысячами объектов с картами (помножить на два языка), где карта занимает всю оставшуюся от "карточки объекта" площадь экрана (какого размера должен быть скриншот?). Если моим юзерам нужна карта, они на нее не кликают (это неинтуитивно и бессмысленно), а сразу ее зумают или двигают. И я даже начинать не буду про легальную сторону размещения на своем сайте скриншотов гуглокарт.

ivnish wrote: Нет смысла дергать api карт для каждого посетителя, если картой будет пользоваться каждый двадцатый

И я не дергаю. Я написал чуть выше как сделал я: у каждой страницы есть два "вьюмода" - фотогалерея и карта. По умолчанию всегда показывается галерея, карта показывается только если ткнуть в таб "карта". Текущий вьюмод запоминается в куке, и в URL'е нарочно никак не отражается, чтобы технически невозможно было дать прямой линк на карту.