Или: как сочетание CSS Chrome и Bitbucket помогло мне пропустить ошибку.
Позвольте мне рассказать вам о небольшом раздражении, которое я недавно испытал при просмотре кода на Bitbucket. Я мог бы (и, может быть, должен?) зарегистрировать ошибку в Bitbucket, но у меня были менее чем успешные взаимодействия с их процессом поддержки, поэтому, чтобы немного повеселиться, я сделаю:
- Напишите об этом здесь, чтобы я мог попрактиковаться в своих разглагольствованиях, я имею в виду письменные навыки,
- Направьте команду поддержки Bitbucket на эту статью, чтобы они могли прочитать ее и сообщить об ошибке для себя, а также
- Предоставить вам, мой читатель, обходной путь.
Но подождите, давайте сначала сделаем № 3, потому что ваше время ценно, и я такой милый. 😉
Загружайте это правило CSS при каждом запросе на включение через Stylebot:
ins,del { display: inline
Вау, какой сложный обходной путь. Но какую проблему я решаю этой строкой? Давайте посмотрим на проблему в формате GIF.
Предыстория, она же известный вам PR-процесс
Когда разработчик выполняет большой рефакторинг, иногда функции меняются местами в файле, вещи переименовываются, и внешние вызовы этих модулей должны быть обновлены, чтобы соответствовать измененной реализации. Это обычная работа для разработчика.
Теперь может быть сложно отслеживать имена функций во всех файлах в большом запросе на вытягивание (PR). Чтобы отслеживать изменения, я иногда копирую имя функции в буфер обмена и использую встроенную в браузер функцию «Найти» для поиска всех вхождений этого имени функции в этом PR.
К сожалению, у Bitbucket есть проблема в Chrome, из-за которой Chrome иногда не может найти фрагменты текста на странице. Это поймало меня, когда я просматривал огромный запрос на включение. Chrome дал мне ложное чувство безопасности, что я все проверил, но он пропустил другие вхождения этого текста, хотя они были прямо здесь в PR. Если бы он не пропускал эти другие вхождения, я бы увидел ошибку рефакторинга.
Chrome дал мне ложное чувство безопасности, что я все проверил.
Проблема, сломалась.
Давайте посмотрим на некоторый код, в котором есть проблема, и попытаемся понять проблему.
Скажем, я хочу найти текст actionCreators.progressTick в этом PR. Итак, как и любой нормальный человек, я выделяю этот текст и копирую его в буфер обмена, а затем использую функцию поиска Chrome, чтобы найти другие вхождения на той же странице.
Звучит просто, правда?
Это. Нет. Работа. 😧
К сожалению, разработчики Bitbucket усложнили нам поиск по запросам на вытягивание очень с помощью всего одного правила CSS. Как и большинство CSS, кажется, что он был добавлен по стилистическим соображениям, но он непреднамеренно ломает инструмент «найти», когда он вам нужен больше всего.
Итак, что здесь происходит?
Давайте еще раз взглянем на скриншот выше. В частности, обратите внимание на зеленые цвета. Обратите внимание, что между actionCreators и progressTick находится символ точки со светло-зеленым фоном, но термины по обе стороны от него имеют темно-зеленый фон.
Окраска фона - вот что вызывает проблему!
Ну, это упрощение, но почти так. Проблема существует из-за особой комбинации правил CSS и структуры HTML, из-за которой появляются разные цвета.
Хорошо, а какая комбинация?
С точки зрения разметки HTML все это имеет смысл. Они разбили определенные части кода на <ins> элементов для вставки и <del> элементов для удаления. Вполне разумно.
Вот как эта строка выглядит в HTML:
Обратите внимание на теги ins вокруг текста слева от символа . и progressTick справа? Разделение текста на несколько элементов является причиной нашей проблемы с поиском!
Почему это вызывает проблему? Обычно этого не происходит, но команда Bitbucket добавила к этим элементам следующий стиль CSS:
Но почему этот CSS вызывает проблемы с поиском?
Обычно в HTML элементы ins и del отображаются как элементы inline. Что такое встроенный элемент? Ознакомьтесь с приведенным ниже определением встроенных элементов из MDN (выделено мной).
Встроенные элементы – это элементы, которые занимают пространство, ограниченное тегами, определяющими элемент, вместо того, чтобы нарушать поток содержимого.
Таким образом, элементы inline не нарушат поток контента, чего можно ожидать от других встроенных элементов (например, <strong>). Эти встроенные элементы не нарушают поток контента, иначе просто сделать слово жирным в абзаце текста было бы очень, очень сложно.
Поскольку ins и del больше не отображаются как элементы inline на странице запроса на вытягивание, Chrome будет искать вверх пока не найдет один из этих элементов, но не продолжит поиск в этом элемент. Chrome больше не считает, что символы в тегах ins и del связаны с текстом, который появился перед ними.
Chrome больше не считает, что символы в тегах ‹
ins>и ‹del>связаны с текстом, который появился перед ними.
Похоже, это решение реализации браузера (или ошибка?), поскольку у Firefox нет проблем с поиском текста, который мы ищем. Если это ошибка, кто-то должен исправить ее в Chrome. Добровольцы?
Решение Chrome
Поскольку я разработчик, мне нравится решать проблемы, поэтому я решил эту проблему (для себя), найдя обходной путь!
Во-первых, нам нужно расширение для браузера, чтобы помочь нам. Существует расширение для браузера под названием Stylebot, которое позволяет нам запускать любой указанный CSS на любом веб-сайте. Вы видите, к чему я клоню?
Ранее я использовал это расширение для решения других мелких проблем Bitbucket (например, для перекрашивания ссылок, которые были настолько темными, что они не выглядели как ссылки), и для общего развлечения, например, для стилизации кнопки создания Gmail в наихудший способ, почему бы и нет?
Конфигурация бота
После установки Stylebot решить проблему с поиском очень просто. Сначала откройте экран параметров Stylebot, как показано на снимке экрана ниже, и нажмите кнопку «Добавить новый стиль…».
Затем просто добавьте CSS ins, del { display: inline } для применения к bitbucket.org.
Вот и все. Сделанный. Удачных поисков! 🎉
Но подождите, так почему же они вообще стилизованы под встроенные блоки?
В GIF ниже вы увидите, что происходит, когда я отключаю добавленное переопределение. Это тонкое изменение стиля; ты это видишь?
Похоже, когда элементы ins и del отображаются как их правильный тип отображения inline, их темно-зеленый фон не растягивается на всю высоту строки, оставляя светло-зеленую полосу между каждой строкой.
Я предполагаю, что исходный стиль, вызвавший нашу проблему с поиском, был просто добавлен, чтобы убрать этот светло-зеленый пробел между каждой измененной строкой.
Кто бы мог подумать, что, казалось бы, небольшое, безобидное визуальное изменение в инструменте для просмотра кода сломает инструмент «найти» и вызовет проскальзывание ошибки?
К счастью, мы обнаружили это до того, как отправили наш код в производство. 😅
Спасибо за чтение!
Итак, сегодня около 9 часов вечера (суббота), и я понимаю, что работаю над этой статьей уже несколько часов. Чтобы написать и доработать подробный пост в блоге, нужно приложить немало усилий, и я надеюсь, что смогу делать это чаще, чтобы он звучал более естественно и занимал меньше времени.
Недавно я написал несколько других небольших JS-скриптов, которые помогут сделать Bitbucket более полезным для моего рабочего процесса (загрузка через Tampermonkey), в том числе несколько приятных изменений на странице запросов на включение, поэтому я планирую написать еще несколько статей об этих скоро.
Приходилось ли вам решать некоторые проблемы с Bitbucket с помощью пользовательских сценариев? Поделитесь своими лайфхаками в комментариях ниже!
Конечно, обязательная вилка…
Единственное, что мешает написать больше статей: когда я составляю пост в блоге, я мог бы вместо этого работать над своим любимым побочным проектом Potent Playbooks.
Я уже некоторое время работаю над новой версией моего приложения для повышения производительности. Он снова стал почти стабильным после изменения дизайна работающего экрана и переписывания огромной части функциональности, чтобы сделать редизайн возможным. Редизайн открывает дверь для многих других функций, которые в настоящее время находятся в стадии разработки. Мне все еще нужно провести намного больше регрессионного тестирования, но следите за ним в следующем месяце.
Хорошего дня!