Спасибо Wes Bos за примеры, как можно обойтись без position: absolute для
накладывающихся друг на друга элементов: tweet 1 и
tweet 2. Я применила этот вариант уже раза 3
в текущем проекте, переверстывая старые элементы, и насколько же лучше это выглядит 😊
За подробностями — в твиттер Wes Bos, у него там видео с примерами, или на css-trics.
Я фанат именованных grid-area, поэтому мой любимый подход: родительский компонент превращаем в grid и задаем grid-template-areas: 'stack'.
Компонентам-детям, которые должны накладываться, задаём grid-area: stack.
(имя grid-area может быть любым, главное, чтобы было одинаковым у тех элементов, над которыми колдуем)
Либо можно не задавать именованную grid-area, а просто указать для нужных элементов одинаковые grid-row-start и grid-column-start.
Вот так:
Нашла интересную статью от Adrian Roselli про то, как писать ‘alt’ для images.
Главное — пусть альтернативный текст будет коротким,
не содержит спецсимволов, URL, и в идеале будет на одном языке. А почему
именно так — можно узнать в статье.
Там также представлены примеры того, как скрин-ридеры ведут себя с длинными текстами в alt.
Спойлер: по-разному, но в любом случае это неудобно для пользователя (и виноват не скрин-ридер).
Очень круто, что в дополнение Adrian Roselli подготовил что-то вроде дерева решений,
как понять, какой alt написать. Отвечаем на несколько вопросов про наш image —
и получаем рекомендации, как лучше писать.
Попробовать можно здесь.
Сегодня пришлось заняться e2e-тестами на Java с использованием Selenide.
После ухода автоматизатора из проекта не хочется терять существующие тесты,
поэтому я решила попробовать поддерживать их сама.
Maven, Selenide, Java — это было что-то новое для меня, но запустить оказалось проще,
чем я ожидала. Пофиксить - тоже :)
Планирую погрузиться в это поглубже и, возможно, даже сама начну написать тесты на Java, кто знает.
Немного о задаче, которую сегодня решила на работе.
У нас есть таблица с фильтрами, которая выводит список визитов в офисы.
Некоторые визиты требуют дополнительного внимания менеджеров, например:
выдан пропуск посетителю, визит закончился, а пропуск не вернули.
Задача была подсветить такие визиты в таблице и дать возможность менеджерам
легко отфильтровать их. Я добавила подсветку для строк, а над таблицей - баннер с кнопкой
“Показать проблемые” (условно). Я также добавила функциональность, чтобы фильтр по проблемным визитам не сохранялся
(мы запоминаем выбранные фильтры пользователя). Всё это работало - пока не появились
проблемы с фильтрами.
Большая часть фильтров у нас - это дропдауны со списком опций. На это ветке
эти дропдауны стали медленно работать, и после 3-4 быстрых кликов страница ломалась.
В консоли появлялись ошибки о “Maximum update depth exceeded” и рекомендации проверить
useEffects и их зависимости.
Стек вызовов указывал на компонент дропдауна из библиотеки компонентов нашей компании.
Что я стала делать
Я начала с попытки понять, что происходит и где может быть проблема. Посмотрела изменения
в коде. Сложности добавляло то, что в этой же ветке я стала использовать код из другого
пакета в нашей монорепе (я использую npm workspaces), и изменений было много.
Естественно, я попыталась отлаживаться. Однако было слишком много вызовов, компонент
дропдауна выглядел нормально и не было в нем useEffects.
Я погуглила и спросила Claude. Время шло. Я решила перейти к одному
из моих любимых методов отладки - удалению частей кода.
Для начала я хотела понять, не из-за ли нового пакета возникла проблема.
Создала новую ветку от develop и перенесла минимальные изменения туда.
Фильтры всё еще работали отвратительно и ломались.
Затем я удалила части кода, касающиеся фичи - запросы и обработку данных.
Проблема осталась.
Я уже была готова сдаться, но решила удалить весь код фичи - и вдруг проблема исчезла.
Наконец, я нашла проблему: div, который оборачивал таблицу и баннер над ней.
Когда я заменила его на фрагмент, проблема исчезла.