Комментарии 7
Во первых, видео с перескакивающей шапкой несколько напрягает своей непонятностью - зачем там всё скачет? Текст читал почти не пропуская, но всё равно идею перескакивания не понял.
Во вторых, в одном тексте собран большой объём информации, что мешает восприятию. Нужно либо давать кратко основные идеи, либо выбирать узкую область и в ней всё расписывать подробно. Если же сразу бросать в читателя и про дизайн, и про удобство интерфейса, и про машины, ну и ко всему этому ещё vue, css, js и прочие вспомогательные инструменты, то статья получается исключительно для тех, кто все эти инструменты освоил до уровня чтения ваших примеров как художественной литературы. Таких мало.
В третьих, наблюдая количество кода в тексте, я задаюсь вопросом - а сколько это стоит? Ради одной таблички необходимо потратить минимум неделю прилично оплачиваемого фронтендера. Стоит ли оно того?
В четвёртых, можно же просто отдавать на клиент разный html, в зависимости от соотношения сторон экрана и его размера. Например - 3-4 варианта. Немного, реализуется проще, соответственно, затраты меньше.
Ну и в качестве заключения: автор проделал приличную работу, это следует признать, но всё же узость поставленной цели (отобразить одну таблицу) и выбранный способ её достижения (нагородить длинный, плохо поддерживаемый и сложный в восприятии код), меня конкретно не вдохновляют. Особенно с учётом того, что на сайте, помимо таблицы с ценами, есть куча всяческих меню и прочих украшательств, которые так же должны адаптироваться к размерам и соотношению сторон. Если добавлять ещё столько же кода и для всех этих меню, то на одну лишь красивость на 2-3-х вариациях экранов уйдёт не меньше человекомесяца, и это если разработчик - энтузиаст, как в случае с автором, а если обычный "от забора до обеда", то и человекогод легко наберётся.
Спасибо за комментарий, во многом с вами согласен.
" Если же сразу бросать в читателя и про дизайн, и про удобство интерфейса, и про машины, ну и ко всему этому ещё vue, css, js и прочие вспомогательные инструменты" - фронтенд сейчас не только про html и css, современные скиллы - html + js (или typescript) + Sass/Less,и всё это скомпилировано на каком-нибудь фреймворке типа реакта или ангуляра. Добавление к этому условно техническому набору инструментов "удобство интерфейса" (осмысление результата с т.зр юзер-фриндли) - считаю это не то что не лишним, а наоборот, необходимым этапом вообще любой работы фронтендера. а про машинки - ну надо же было какой-нибудь реальный кейс использовать, вот я и выбрал то, что мне нравится.
Про перескакивающую шапку - если таблица большая, особенно если она не влазит полностью на экран мобильного, то без шапки (ключевое - которая рядом с ячейками) теряется связь со столбцами, названиями этих столбцов.
И да, действительно статья получилась чрезмерно большая. Просто я мало где видел описание тех инструментов / методов, которые использовал - те же CSS-модули и КОП, и поэтому решил написать и о них тоже, с целью переориентации с SCSS и ООП. Наверное, этого делать не стоило, было бы сильно короче.
С удовольствием прочитал, интересная концепция, спасибо! Так может сайтом не ограничиваться сразу конкурента Excel, Google Sheets писать?)
«Реализация переусложнена» — согласен с одним дополнением: это не готовый кейс, а туториал, цель которого — даже не показать, а понять (для себя самого), будет ли эта концепция работать, если таблица будет усложнена как только возможно — с объединением ячеек как в столбцах, так и в рядах, с очень большим количеством ячеек и в шапке, и в заголовках строк, и в блоке, где сравниваются данные.
Плюс в кейсе очень много кода, относящегося к стилям — чтобы и в классическом виде, и в адаптации вид таблицы был близок к идеальному — этим можно было бы пренебречь, навскидку было бы раза в два «меньше букв», но я, наверное, просто перфекционист :)
Про «не будут влезать в экран» — как раз в рамках этой концепции такого просто не может быть (если только в любой из ячеек нет слова (т.е. текста без пробелов), длина которого превышает ширину экрана))). И поэтому тоже кода так много. Гляньте на пример из ссылки в конце статьи, с активированными «Many Columns» и «+Manufacturers» на мобильном устройстве — там намеренно испорченная таблица, с просто чудовищно большой шапкой и большим количеством столбцов — данные по прежнему удобны для сравнения.
Статья хорошая и концепция интересная, но остаётся вопрос: чем ваш подход принципиально лучше, чем классические медиа-запросы? Я не вижу сценариев, в которых экономически более выгодна динамическая адаптация контента. Чтобы это было так, решение должно быть универсальным, а пока выгоднее нанять средней руки верстальщика-джуна на изготовление нескольких вариантов таблиц под разные устройства. Что я упускаю?
по поводу динамической адаптации контента:
1.1. разработка НЕСКОЛЬКИХ нединамических вариантов - более ресурсо-затратно, чем ОДНОГО динамического
1.2. поддержка/развитие нескольких вариантов - более сложный, затратный и, что не менее важно - сильно сложнее контролируемый процесс. добавили какую-нибудь фичу, посмотрели на сматрфоне в portrait и на мониторе, а бедные обладатели планшетов, глядя на нововведения в landscape, думают "опять у них вся верстка поехала"
2. большинство мобильных девайсов имеют две важные характеристики: а) вытянутый (неквадратный) экран, б) две ориентации - portrait и landscape. и в любой момент, удобный пользователю, он может повернуть свое устройство так, как ему удобно. и если думать про usability и user-friendly, то динамическая адаптация с учетом этого более оптимальна
классические медиа-запросы - отличный инструмент, особенно с использованием SASS/LESS. Но CSS-модули, имхо, сильно привлекательнее, хотя бы по следующим причинам:
в современном фронтенде рулит js (ну или ts). И во вью, и в прочих реактах с ангулярами именно script отвечает за формирование/изменение dom-контента. Поэтому разделение, которое существовало до CSS-модулей - стили отдельно, скрипты отдельно - это анахронизм.
классические медиа-запросы сложнее и муторнее поддерживать. Простой пример: есть три лейаута - mobile, tablet и desctop. на веб-странице есть три параграфа <p>. Допустим, что в desktop у первого <p> нужно сделать левый border, в tablet - у второго, в mobile - у третьего. в классике надо border-left прописать три раза в трех media queries. И зачем делать три раза то, что можно сделать один раз?
ну и модульность с локальной областью видимости - отличная штука. и уже не нужны всякие БЭМы с длинными .blockname_elementname__modificatorname
а джунов сейчас разве не адаптивному веб-дизайну учат, а, как в прошлом веке - мобильная версия отдельно, версия для настольных ПК - отдельно? :)
Адаптивные таблицы в вебе