Максим Морев

За slick не скажу, Swiper'ом точно можно.
Вот тут отвечал.

Я бы в первую очередь куда-то в эту сторону посмотрел.



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

Если бы не хватило - полез бы смотреть в сторону SVG-клипа.
Но в целом случай сложный, придётся заморочиться, чтобы сделать более-менее приятно глазу. :)

Нет, неправильно. У вас window.dataLayer до подключения Метрики не определен.
E-commerce события вызываются после подключения Метрики, причём не сами по себе, а в ответ на конкретные действия пользователя (просмотр товара, удаление из корзины, покупка и другие, о чём в документации написано).

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

Да, всё верно. Каждое изменение текстового поля - новый запрос к API.
Единственное что - на изменение повешайте throttle с интервалом в районе 200-500мс, так как есть люди, которые быстро печатают, и им не надо смотреть на промежуточные результаты, да и количество запросов сэкономите.

Потому что синтаксис комментариев в HTML выглядят иначе. Вот так:
<!-- Комментарий -->

Указать вы можете что угодно и на любом этапе изучения, просто это мало кому интересно, на "теги" никто не смотрит, это шум. Работодателю важно ваше умение решать задачи, а вовсе не то, чтобы вы прочитали блоки документации.
Можете решать задачи, пользуясь Реактом? Значит, знаете Реакт.
Чем сложнее задачи можете решать, тем лучше знаете. Зная только про main concepts - на любом реальном проекте вы потеряетесь и ничего толкового сделать не сможете.

А также, сколько времени у вас потребовалось на main и advanced?

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

Стилям оверлея допишите pointer-events: none; - можно будет взаимодействовать с картой.
А дизайнеру двойка, любой креатив не должен идти вразрез с юзабилити.

Фронтендер, не умеющий верстать - это оксюморон.

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

Насколько вёрстка важна?
Максимально, ибо работает ваша отрисовка 0.1с или 0.2с, используете ли вы fetch, или axios, или даже XMLHttpRequest - это пользователю неинтересно (в очередной раз напоминаю, что сайты и приложения мы делаем для пользователей), бизнесу обычно тоже не особо интересно, а вот если вёрстка расползается, что-то где-то едет, становится недоступным, или простая страница верстается 30 часов, а потом ещё 20 тестируется и правится, а в итоге всё равно какое-то говно - это уже замечают все причастные.

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

HTML, CSS, JS - навыки, которые растут параллельно, если всё идёт правильно.
Не в одинаковой пропорции, но одно без другого смысла не имеет.

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

Вы можете совершенно спокойно каждому элементу управления добавить в разметке какой-то уникальный класс (.js-slider-1-button-prev, .js-slider-2-button-prev и так далее) подобно тому, как вы вызываете сейчас .swiper-container и .swiper-container1 и в опции передавать этот уникальный класс.
Также можно в nextEl и prevEl передавать не строку, а Element (querySelector('.your-button')) с нужной кнопкой.

Тыкаем Ctrl+Shift+P, чтобы вызвать палитру команд. Там пишем "scope" - отфильтруется так, что останется один пункт. Клацаем Enter.
Далее клацаем на то место, которое вас не устраивает. В вашем случае на переменную.
Получаем окно, в котором нас интересует выделенное оранжевым.


Далее идём в settings.json, туда добавляем правила, основываясь на выделенном выше фрагменте.
Для вашего случая будет как-то так, аналогично выделил оранжевым то, что нужно вам:


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

Есть прям навязчивое желание всё переделать, что-то изменить, а что — не знаешь. Вроде всё здорово.

Первое правило инженера: работает - не трогай

Задача достигнута? Заказчик доволен? Если да - не трогать.
Есть какие-то конкретные несовершенства, которые можно сформулировать? Если нет - не трогать.

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

Привет.
Ответ Alexey10 сработает, но имеет недостаток - отсутствие плавного перехода между состояниями, что особенно заметно, если неспешно перетаскивать слайды мышкой.
У Swiper'a для этих вещей есть эффект "coverflow", который путём определённых настроек позволяет добиться нужного результата.
Сами настройки для вашего макета будут выглядеть примерно так:

Со значениями depth и modifier нужно будет поиграться, чтобы добиться нужного смещения, а прозрачность и размытие - как и было сказано, через специальные классы элементов, которые добавляет Swiper. :)

Здравствуйте. Просто не указывайте расширение при импорте.

@import 'bla.css'; // вернёт @import url(bla.css);
@import 'bla'; // вернёт import как вы хотите

Потому что в спеке отдельной графой так описано. Про специфичность.

Стили непосредственно соответствующих элементов всегда предпочитаются унаследованным стилям, независимо от специфичности унаследованного правила

Чтобы уложить в голове, нужно нарочито утрировать и посмотреть как это работает: