Селекторы: как находить элементы

У chromedp селекторы устроены интереснее, чем кажется: строка и режим поиска — это две разные вещи. Строка — то, что вы хотите найти: «h1.title», «#price», целое XPath-выражение. Режим — то, как браузер будет искать: он выбирается опциями BySearch, ByQuery, ByQueryAll, ByID и задаётся последним аргументом действия. По умолчанию действует BySearch — браузерная команда поиска, которая понимает три вида запросов сразу: CSS-селекторы, XPath-выражения и даже обычный текст. Поэтому WaitVisible("h1") без опций работает и как CSS, и, если начать строку с двойного слэша, как XPath. Для точного контроля есть точные режимы: ByQuery ищет через querySelector — один первый узел по CSS, ByQueryAll — через querySelectorAll — все узлы сразу, ByID — быстрый поиск по атрибуту id. Зачем точные режимы, если есть универсальный? Скорость и предсказуемость: querySelector и querySelectorAll — прямые браузерные команды с понятной семантикой, а универсальный поиск устроен иначе и для простых CSS-случаев избыточен. Правило выбора простое: есть id — берите ByID, обычная CSS-логика — ByQuery или ByQueryAll, текст и оси — XPath через дефолт.

CSS — рабочий язык поиска в большинстве задач, и хромедповские режимы отображаются на него один в один. ByQuery — это document.querySelector: вернуть первый узел, подходящий под селектор. ByQueryAll — document.querySelectorAll: вернуть коллекцию всех подходящих. Разница проявляется в поведении действий: Text с ByQueryAll прочитает текст всё равно первого узла — действие применяется к первому элементу результата, но условие готовности ослабляется: достаточно одного совпадения. Настоящее применение ByQueryAll — действия над списками: Nodes соберёт массив узлов для обхода, а опция AtLeast задаст минимальное число совпадений, ниже которого запрос считается не выполнившимся — полезно для строк таблицы, где «пусто» и «не доехало» надо различать. По умолчанию достаточно одного совпадения: пустой каталог и «строки ещё не доехали» для ByQueryAll выглядят одинаково, и именно AtLeast разделяет эти состояния — с AtLeast(10) запрос добросовестно будет ждать десятую строку. Сам язык CSS пересказывать здесь не будем: классы, атрибуты, комбинаторы и псевдоклассы — то же, что вы знаете по goquery из Colly, и если эта база проседает, лучший тренажёр — консоль браузера: document.querySelectorAll(".card") в DevTools отвечает на вопрос «что найдёт этот селектор» мгновенно и без запуска программы.

XPath — второй язык поиска, встроенный в chromedp через универсальный режим: строка, начинающаяся с двойного слэша, обрабатывается как XPath-выражение. Возможности, за которые xpath go ценят в парсерах, — это поиск по тексту и движение по дереву в обе стороны. CSS умеет искать вниз: от родителя к потомкам и соседям. XPath умеет и вверх: найти кнопку можно от текста внутри неё, а затем подняться к карточке parent::, в которой лежит цена. Самый частый паттерн практики — элементы без устойчивых классов, зато с надписью: //a[contains(text(), "Следующая")] находит кнопку пагинации по тексту, какой бы класс ей ни дали дизайнеры. chromedp селекторы с XPath пишутся той же строкой в тех же действиях — отдельного API нет, и это удобно: одно и то же действие Text принимает и CSS, и XPath. Платить приходится читаемостью: длинные оси и предикаты в коде труднее воспринимаются, чем CSS-селекторы, поэтому рабочая пропорция — CSS для структуры, XPath для текста и редких подъёмов к родителю. Проверять выражения проще всего там же, в консоли: document.evaluate отвечает за XPath в DevTools.

Каждое действие с селектором в chromedp — это конвейер, и полезно видеть его звенья. Сначала запрос ищет узлы выбранным режимом: поиска нет — документ переспрашивается с интервалом в несколько миллисекунд. Затем проверяются условия готовности: по умолчанию достаточно, чтобы узлы нашлись, опции NodeVisible, NodeEnabled и другие добавляют свои требования — они и превращают поиск в ожидание. Наконец, действие исполняется на найденных узлах: текст читается из первого, клик идёт по первому, значение ставится в первое. Хуком в этот конвейер служит QueryAfter — функция, которая выполняется после того, как селектор совпал и условия выполнены: в неё попадают контекст и найденные узлы, и там можно сделать всё, чего нет в готовых действиях — обойти список узлов, прочитать несколько атрибутов разом, собрать структуру. Половина «невозможных» задач решается на этом уровне без экзотики. Механику условий с поллингом мы разобрали в прошлый раз, а тонкая настройка — свои интервалы, свои предикаты — ждёт в уроке про умные ожидания; здесь важен сам принцип: селектор без условия — это поиск, селектор с условием — ожидание.

Стойкость селектора — это его связь со стабильными вещами на сайте, а не с текущей модой вёрстки. Ранжирование надёжности в практике простое. Первый ранг — атрибуты, которые существуют для программ: id и data-атрибуты, особенно data-testid, которые тестировщики оставляют именно для автоматизации; ищутся они и обычным CSS — селектор вида [data-testid="add-to-cart"] читается как смысл и переживает любые редизайны вёрстки. Второй ранг — семантические классы и структурные теги с осмысленными именами: класс price или тег table — вещь, которую дизайнеры переименовывают неохотно. Третий ранг — комбинированные пути: стабильный родитель плюс простое правило внутри, вроде div.card span.price. За пределами рангов остаются позиции — nth-child и индексы в XPath-предикатах: они описывают не смысл, а случайный порядок. Длина пути — отдельный сигнал: чем короче путь, тем меньше у него точек отказа, поэтому селектор вида #price лучше цепочки из шести уровней. Последний штрих дисциплины — проверка на выборке: хороший селектор совпадает на первой странице каталога, на десятой и на карточке товара, а не только там, где вы его написали. Для строк таблиц с пагинацией эта проверка — обязательная, и в двадцать первом уроке она встраивается в сам сценарий скрапинга.