Как проверить шаблон на ошибки

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

Что это и зачем

Валидный HTML-код, валидная разметка — это HTML-код, который написан в соответствии с определёнными стандартами. Их разработал Консорциум Всемирной Паутины — World Wide Web Consortium (W3C). Что именно это значит?

Писать код — это примерно как писать какой угодно текст, например, на русском языке. Можно написать понятно, вдобавок грамотно, а также разбить текст на абзацы, добавить подзаголовки и списки. Так и с валидностью кода. Если вы создаёте разметку, которая решает ваши задачи корректно, то для того, чтобы ваша работа была валидной, в ней стоит навести порядок.

Понятный код — меньше хлопот

Для чего это нужно? Иногда нам кажется, что другие думают как мы. Что не надо стараться объяснять. Но вот нет. Чтобы другие поняли вас быстрее, надо учитывать правила передачи информации. Под другими можно иметь в виду коллегу по команде, а также браузер или компилятор — любое ПО, которое будет работать с вашей разметкой.

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

Спецификации кода могут быть разными. Нет универсальной в такой же степени, как и нет абсолютно правильного кода, который работает на всех устройствах и программах правильно. Хотя, сферический вакуумный конь поспорил бы с этим.

Валидатор — это…

Так же, как и с проверкой грамотности языка, HTML-код можно проверять вручную — своими глазами и мозгами, а можно пользоваться и автоматическими помощниками. Это может быть отдельный целостный сервис, а может быть дополнение к браузеру. Первое лучше. Инструменты валидации HTML-кода онлайн облегчают жизнь разработчика, которому не нужно самому вычислять, например, парность скобок.

Как пользоваться валидатором

Рассказываем на примере «родного» валидатора W3C. Этот валидатор используется потому, что его сделали авторы правил, которым должен соответствовать код. Вы можете пройти по ссылке и провести валидацию кода на своём любимом сайте. Будет интересно.

За вами выбор способа проверки. Можно проверять код по ссылке, можно загрузить в сервис HTML-файл, а можно фрагмент кода. В третьем варианте как раз и идёт речь о написанном в окне сервиса коде или скопированной части из разметки всей страницы.

Цепочка действий в два шага. Первый — предоставить исходный код, а второй — нажать на кнопку проверки.

Вы можете пойти дальше и задать дополнительные параметры валидации. Они нужны, чтобы структурировать и детализировать результаты.

Интерпретация результатов валидации

Инструмент валидации оценивает синтаксис, находит синтаксические ошибки типа пропущенных символов и ошибочных тегов и т. д. И отлавливает одну из частых ошибок вложенности тегов.

Часто в результате сервисы валидации разметки, как и компиляторы в разработке, выдают список, разделённый на предупреждения и ошибки. Разница в критичности. Ошибки с максимальной вероятностью могут создать проблемы в работе кода. Это опечатки (да, техника любит точность), лишние или недостающие знаки. А вот к предупреждениям относятся неточности, которые с минимальной вероятностью навредят работе страницы, но не соответствуют стандартам. Это избыточный код, бессмысленные элементы и другие «помарки».

Так выглядит результат валидации HTML-кода на очень простой странице, созданной за пару часов в конструкторе сайтов.

Ошибки и предупреждения собраны в список. В каждом элементе списка указаны значение, атрибут и элемент, которые не устроили валидатор, а также приведена цитата кода с ошибкой.

Сами валидаторы могут ошибаться. То, что не пропускает валидатор, может быть корректно обработано браузером. Так что не обязательно исправлять абсолютно все ошибки в своей разметке. Обращать внимание и уделять время проверке надо при серьёзных ошибках, которые мешают корректной работе сайта и отображению страниц.

Подробнее о валидаторе, правилах построения HTML-разметки, а также другие интересные и важные вещи мы разбираем на курсе «HTML и CSS. Профессиональная вёрстка сайтов».

Список на память

• Не стоит путать валидность с абсолютной правильностью.
• Важна каждая запятая и закрывающая скобка, закрытый тег. Глазами это сложно усмотреть всё, поэтому валидатор и придумали.
• Валидаторы проверяют синтаксис. Термин из филологии.
• Редактор, в котором вы пишете код, также можно настроить так, что он будет автоматически закрывать открытые вами теги и сообщать об ошибках ещё до валидации — в процессе написания разметки.
• Алгоритмы любят порядки. Чем лучше написан код страниц на сайте, тем выше сайт продвигается в релевантной выдаче.

«Доктайп» — журнал о фронтенде. Читайте, слушайте и учитесь с нами.

ТелеграмПодкастБесплатные учебники

Обновлено: 12.06.2022

Дизайн сайта устарел, и вы решили заказать новый шаблон? Не спешите: ошибки вёрстки могут обрушить позиции в поиске. Но при правильном подходе они только улучшаться – как и конверсии.

На что влияет шаблон сайта

Когда вы думаете о смене дизайна сайта, в первую очередь рассматриваются следующие моменты:

• Актуальность дизайна
• Способность лучше конвертировать посетителя в покупателя
• Адаптивный дизайн для мобильных устройств
• Личные предпочтения владельца сайта

Как можно заметить, все эти пункты преимущественно касаются либо частных субъективных вкусов, либо маркетинга, но практически никогда – таких приземленных материй, как способность поисковых роботов полноценно сканировать и индексировать сайт, возможность отдавать роботам предельно уникальный в рамках сайта контент посадочных страниц, быстродействие и т.п. То есть именно то, что напрямую влияет на оценку сайта поисковыми системами.

Типовые ошибки вёрстки, опасные для SEO

Вывод важного контента средствами Javascript и AJAX

Поисковые системы до сих пор плохо справляются с контентом, формируемым средствами JS. При первичном индексировании поисковые роботы могут прочитать лишь «сырой» HTML – статический контент. То, что выводится средствами JS, будет просканировано и учтено при последующих обходах и пересчётах, если поисковый робот вообще решит обходить страницу ещё раз. По этой причине весь критически важный для оценки страницы контент должен выводиться средствами HTML, либо роботу должна предоставляться кэшированная версия всё с тем же HTML.

Контент, генерируемый средствами AJAX, роботу недоступен. Он не может коммуницировать со страницей так, как человек: он не нажимает кнопки, не заполняет формы, он не умеет даже прокручивать страницу. Поэтому контент, подгружаемый с сервера по запросу пользователя без перезагрузки страницы, роботу недоступен и не может быть учтен в оценке страницы.

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

Вывод. Не позволяйте верстальщику решать все вопросы с помощью JS без особой необходимости, и тестируйте шаблон на доступность для роботов.

Подробно о Javascript SEO в статье на vc.ru

Псевдоссылки вместо ссылок

Поисковые роботы ходят по ссылкам. Ссылка – это HTML-тэг “a href=…”, включающий в себя какой-то текст (анкор) или изображение. Лучшая ссылка – это тэг A, в анкор которого входит какое-то описание страницы, на которую ведёт ссылка. Благодаря ссылкам и их анкорам люди и поисковые системы могут увидеть структуру какого-то ресурса, связь между двумя ресурсами, предположить содержание документа, на который ведёт ссылка.

Псевдоссылками называют интерактивные элементы, которые ведут себя как ссылка – но ссылкой не являются, поскольку реализованы средствами JS.

Для того, чтобы робот перешёл по ссылке и обнаружил новую статью, товарную категорию или карточку товара, он должен во время сканирования увидеть ссылку, понять, что это именно ссылка и перейти на найденный URL. Проблемы с этой простой схемой возможны в следующих случаях:

• Ссылка выводится средствами JS и в «сыром» HTML её попросту нет. Это значит, что при первичном сканировании робот её не увидит, и обнаружит только при следующих обходах сайта, после рендеринга JS.
• Вместо нормальной ссылки в HTML используется псевдоссылка, реализованная средствами JS, и для её выполнения поисковый робот должен этот JS выполнить. Соответственно, страница по ссылке будет найдена значительно позже, либо не найдена вообще.
• Отдельную проблему представляют собой анкоры псевдоссылок: они не могут участвовать в расчётах текстовых метрик страницы в качестве ссылок и рассматриваются как шинглы. Более подробно мы рассмотрим этот вопрос ниже, отдельно.
• Веб-структуры любого уровня представляют собой графы, состоящие из троек «субъект – предикат – объект», где связующим звеном выступают именно ссылки. Псевдоссылки в качестве предиката выступать не могут, а значит, их использование негативно сказывается на структурировании сайта в целом.

Вывод. Не используйте JS-ссылки, если не хотите эти ссылки скрыть от поисковиков. Не выводите ссылки средствами JS, если речь идёт о критически важном контенте, навигации, листингах товаров и услуг и т.п.

Безанкорные блочные ссылки

С помощью анализа ссылочных анкоров поисковая система может алгоритмически просчитать коммерческие метрики сайта. Если на странице категории товаров в интернет-магазине выводится 50 ссылок с анкором «Офисный стул…», а всего в категории 10 страниц – у вас неплохой ассортимент офисной мебели. А полнота ассортимента – один из важнейших сигналов для поисковой системы, означающих, что ваш сайт стоит показать на выдаче по запросам группы «купить офисные стулья».

Важно понимать, что текстовый анализ оценивает сначала весь контент страницы целиком, по простейшим алгоритмам типа «мешка слов», а потом, на следующей итерации – с разделением на отдельные текстовые зоны, куда входят метатеги, заголовки, ссылочные анкоры, шинглы и текстовые блоки. «Вес» ключей в них сильно отличается.

Ссылки, оборачивающие целые контентные блоки, включающих в себя изображения, текстовые блоки и т.п. относятся к безанкорным ссылкам. Ключи в таких блоках рассматриваются как ключи в шинглах, текстовых фрагментах, не как ссылочные анкоры. В настоящий момент ключи такого рода могут рассматриваться как обычный текстовый спам, считываемый именно как спам.

Вывод. Использование безанкорных блочных ссылок может привести к полной утрате текстовой релевантности страницы и попаданию под текстовые фильтры за спамность. Такие ссылки полезнее псевдоссылок, реализованных средствами JS, но их нельзя признать эффективными с точки зрения SEO.

Неправильная структура страниц и сайта в целом

Разработка дизайна сайта невозможна без предварительного анализа поисковой семантики и основанной на ней структуры. Это касается как структуры сайта в целом, так и структуры отдельных типов страниц – главной, каталога, страниц категорий, товарных карточек и т.п. Игнорирование SEO-требований к структурированию может стать причиной множества серьёзных ошибок различного характера. Вот лишь некоторые:

• Появление страниц-дублей и каннибализация запросов
• Текстовая нерелевантность
• Низкие поведенческие метрики по причине недочётов UX
• Неконверсионность: сайт не продаёт

Простой пример: вы выводите на категорию подкатегории, товарные карточки и теги без учёта их важности для поисковых систем и пользователей, либо вообще выводите только товарные карточки – просто потому, что шаблон не предусматривает блока для подкатегорий и тегов, а товарные карточки вы можете сортировать только по не самым важным критериям. В результате текстовая релевантность резко снижается, а посетителю сложно найти интересующий его товар.

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

Вывод. Дизайн сайта в целом и отдельных типов страниц неэффективен без предварительной проработки структуры с опорой на поисковую семантику и коммерческие задачи сайта.

Когда дизайн сайта противоречит логике SEO

Дизайн – это не про эффектность и оригинальность. В первую очередь, дизайн – это удобство и понятность для пользователя. В сайтостроительстве этот принцип часто забывают. И вот заходя на каждый первый сайт вы видите огромный слайдер, который сразу проматываете, «новости» о компании, о которой впервые слышите и пока не знаете, чем она занимается в принципе, потом какие-то товары или блоки услуг. Минимум информативности – и только потому, что дизайнер проектировал шаблон ради визуальной привлекательности, броскости – но без учёта задач вашего бизнеса и удобства для посетителей.

Благодаря продуманной структуре посадочная страница понятна и для роботов, и для людей. Попав на такую страницу, вы сразу понимаете, что вам тут предлагают, кто предлагает, каковы альтернативы, что делать дальше и почему вообще стоит что-то делать. Такая структура действует как хороший экскурсовод или продавец-консультант: встречает, объясняет и доводит до заданной цели.

Для поискового робота максимально важен контент, размещенный на первых 2-3 экранах. Точно так же – и для человека: куда я попал? Соответствует ли это моим целям? Как это получить?

Казалось бы – всё просто. Но зайдите на каждый первый сайт, и вместо конкретики вы увидите огромный слайдер с мусорной информацией, размещенной по принципу «чтобы было» – просто потому, что так задумано дизайнером. А ведь это – самое драгоценное пространство на странице.

Вывод. Попробуйте отключить оформление и посмотреть на текстовый контент страницы критическим взглядом. Похоже ли это на полноценный лендинг? Соответствует ли такая структура задачам вашего бизнеса? Если нет – это явный повод внести правки в дизайн страницы и сайта в целом. Не позволяйте дизайнеру шаблонизировать ваше уникальное торговое предложение без учёта сути и смысла этого предложения.

Как проверить шаблон сайта на ошибки

Комплексный аудит сайта подразумевает обязательные проверки доступности основного контента при первичном сканировании его в формате HTML. Для этого вам понадобится парсер уровня Screaming Frog SEO Spider, который умеет эмулировать основных поисковых роботов, а также может сканировать сайт в трёх основных режимах: только текст, эмуляция сканирования кэшированного AJAX и режим рендеринга Javascript.

В результате такой проверки вы можете сравнить две версии сканирования: «сырой» HTML и вариант с рендерингом JS. В хорошем случае эти две версии практически не отличаются.

На отдельной вкладке можно посмотреть, какой контент и в каком объёме на заданном URL выводится средствами Javascript. Бывают случаи, когда средствами JS выводится второстепенный и неважный контент (чат с консультантом, дополнительные отзывы на товар, ссылки на соцсети), а бывает, что выводится практически всё – и вот это уже серьёзная проблема.

Кроме того, после парсинга вы можете увидеть, какие служебные ресурсы (файлы CSS, JS, изображения и шрифты) необходимы поисковому роботу, чтобы полноценно отрисовать сайт так, как его видят люди. Если робот не получает доступ к этим ресурсам и не может отрисовать адаптивный шаблон, поисковая система может решить, что сайт не адаптирован для мобильных устройств, и это плохо повлияет на ранжирование.

Второй способ – это оценка сохраненной копии (то, что сохранено в поисковом кэше). Как правило, при оценке сохраненной копии вам доступно две версии данных: полная версия в HTML и версия, включающая только текст. Таким образом, вы можете увидеть, что доступно роботу в настоящий момент, а какие блоки полностью выпадают из сканирования или ещё не просканированы.

Заключение

В этой статье мы разобрали лишь базовые факторы, способные как повысить позиции сайта в поисковой выдаче, так и выбросить его оттуда. Я умышленно не стал рассматривать ряд некоторых технических моментов, интересных только специалистам, а также быстродействие, юзабилити, вопросы конверсии (CRO) – это слишком широкие темы, к тому же связанные с SEO только косвенно. Однако нужно понимать, что подготовка ТЗ дизайнеру на подготовку нового шаблона не ограничивается только данными от SEO-специалиста: в работе должны принимать специалисты по UX, дизайн сайта должен разрабатываться с учётом пользовательского маршрута (конверсионной воронки), возможностей коммуникаций потенциального клиента с вашим бизнесом и т.п.

Не отдавайте разработку дизайна сайта на откуп дизайнеру, верстальщику и разработчику. У них свои задачи, и они могут не совпадать с задачами вашего бизнеса. Смена дизайна сайта – комплексная задача, в решении которой должны принимать специалисты из разных отраслей сайтостроительства. Лишь в этом случае вы сможете избежать большинства фатальных ошибок и минимизировать менее существенные, но досадные ошибки и недочёты.

Разберем, насколько критическими для работы сайта и его продвижения могут быть ошибки в HTML-коде, и зачем нужны общие стандарты верстки.

Что такое валидность кода

После разработки дизайна программисты верстают страницы сайта — приводят их к единой структуре в формате HTML. Задача верстальщика — сделать так, чтобы страницы отображались корректно у всех пользователей на любых устройствах и браузерах. Такая верстка называется кроссплатформенной и кроссбраузерной — это обязательное требование при разработке любых сайтов.

Для этого есть специальные стандарты: если им следовать, страницу будут корректно распознавать все браузеры и гаджеты. Такой стандарт разработал Консорциумом всемирной паутины — W3C (The World Wide Web Consortium). HTML-код, который ему соответствует, называют валидным.

Валидность также касается файлов стилей — CSS. Если в CSS есть ошибки, визуальное отображение элементов может нарушиться.

Разработчикам рекомендуется следовать критериям этих стандартов при верстке — это поможет избежать ошибок в коде, которые могут навредить сайту.

Чем ошибки в HTML грозят сайту

Типичные ошибки кода — незакрытые или дублированные элементы, неправильные атрибуты или их отсутствие, отсутствие кодировки UTF-8 или указания типа документа.

Какие проблемы могут возникнуть из-за ошибок в HTML-коде

• страницы загружаются медленно;
• сайт некорректно отображается на разных устройствах или в браузерах;
• посетители видят не весь контент;
• программист не замечает скрытую рекламу и вредоносный код.

Как валидность кода влияет на SEO

Валидность не является фактором ранжирования в Яндекс или Google, так что напрямую она не влияет на позиции сайта в выдаче поисковых систем. Но она влияет на мобилопригодность сайта и на то, как поисковые боты воспринимают разметку, а от этого косвенно могут пострадать позиции или трафик.

Почитать по теме:
Главное о микроразметке: подборка знаний для веб-мастеров

Представитель Google Джон Мюллер говорил о валидности кода:

«Мы упомянули использование правильного HTML. Является ли фактором ранжирования валидность HTML стандарту W3C?

Это не прямой фактор ранжирования. Если ваш сайт использует HTML с ошибками, это не значит, что мы удалим его из индекса — я думаю, что тогда у нас будут пустые результаты поиска.
Но есть несколько важных аспектов:

— Если у сайта действительно битый HTML, тогда нам будет очень сложно его отсканировать и проиндексировать.
— Иногда действительно трудно подобрать структурированную разметку, если HTML полностью нарушен, поэтому используйте валидатор разметки.
— Другой аспект касается мобильных устройств и поддержки кроссбраузерности: если вы сломали HTML, то сайт иногда очень трудно рендерить на новых устройствах».

Итак, критические ошибки в HTML мешают

• сканированию сайта поисковыми ботами;
• определению структурированной разметки на странице;
• рендерингу на мобильных устройствах и кроссбраузерности.

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

Как проверить код на валидность

Не нужно вычитывать код и считать символы — для этого есть сервисы и инструменты проверки валидности HTML онлайн.

Что они проверяют:

• Синтаксис
  Синтаксические ошибки: пропущенные символы, ошибки в написании тегов.
• Вложенность тэгов
  Незакрытые и неправильно закрытые теги. По правилам теги закрываются также, как их открыли, но в обратном порядке. Частая ошибка — нарушенная вложенность

  .

• DTD (Document Type Definition)
  Соответствие кода указанному DTD, правильность названий тегов, вложенности, атрибутов. Наличие пользовательских тегов и атрибутов — то, чего нет в DTD, но есть в коде.

Обычно сервисы делят результаты на ошибки и предупреждения. Ошибки — опечатки в коде, пропущенные или лишние символы, которые скорее всего создадут проблемы. Предупреждения — бессмысленная разметка, лишние символы, какие-то другие ошибки, которые скорее всего не навредят сайту, но идут вразрез с принятым стандартом.

Валидаторы не всегда правы — некоторые ошибки не мешают браузерам воспринимать код корректно, зато, к примеру, минификация сокращает длину кода, удаляя лишние пробелы, которые не влияют на его отображение.

Почитать по теме:
Уменьшить вес сайта с помощью gzip, brotli, минификации и других способов

Поэтому анализируйте предложения сервисов по исправлениям и ориентируйтесь на здравый смысл.

Перед исправлением ошибок не забудьте сделать резервное копирование. Если вы исправите код, но что-то пойдет не так и он перестанет отображаться, как должен, вы сможете откатить все назад.

HTML и CSS валидаторы — онлайн-сервисы для проверки кода

Есть довольно много валидаторов, выберите тот, в котором вам удобнее работать. Мы рекомендуем использовать известные сервисы от создателей стандартов. Если пояснения на английском воспринимать сложно, можно использовать автоматический перевод страницы.

Валидатор от W3C

Англоязычный сервис, онлайн проверяет соответствие HTML стандартам: можно проверить код по URL, залить файл или вставить код в окошко.

Инструмент покажет список ошибок и предупреждений с пояснениями — описанием ошибки и ее типом, а также укажет номер строки, в которой нужно что-то исправить. Цветом отмечены типы предупреждений и строчки с кодом.

Валидатор CSS от W3C

Инструмент от W3C для проверки CSS, есть русский язык. Работает по такому же принципу, анализирует стили на предмет ошибок и предупреждений. Первым идет блок ошибок, предупреждения собраны ниже отдельно.

Исправления ошибок и валидации HTML и CSS может быть недостаточно: всегда есть другие возможности испортить отображение сайта. Если что-то не работает, как надо, проведите полноценный аудит, чтобы найти ошибки.

С другой стороны, не зацикливайтесь на поиске недочетов в HTML — если код работает, а контент отображается корректно, лучше направить ресурсы на что-то другое — оптимизацию и ускорение загрузки, например.

При выборе шаблона WordPress, желательно проверить его на работоспособность и совместимость с текущей, свежей версией самого движка WordPress. Что это значит?

Очень важно, чтобы шаблон выполнял все новые функции, чтобы в нем не было критических ошибок, которые в последствии негативно скажутся на работоспособности сайта. Вы ведь не устанавливаете старые плагины, которые давно не обновлялись? Так и с шаблоном будущего сайта. Не ставьте старые шаблоны WordPress на новую версию самого движка. В старых шаблонах отсутствует реализация новых возможностей, используются устаревшие функции.

Так как же выполнить проверку шаблона WordPress? Плагин Theme Check.

В этом вам поможет

плагин WordPress — Theme Check

Этот плагин сканирует шаблон на ошибки, проверяет наличие всех файлов, новых функций. Об этом на наглядном примере в статье далее. Давайте по порядку.
Для начала установите плагин Theme Check из официального WordPress репозитория. После активации, в его админ. панель можно попасть через вкладку «внешний вид». В этом плагине нет настроек и для проверки шаблона нужно нажать всего одну кнопку. Вот, посмотрите на скриншот:

Я нажал на кнопку Check и отметил чебокс. Вот результат проверки разрабатываемого мной шаблона WordPress плагином Theme Check:

— Кликните по картинке, и посмотрите в полном размере.
Итак, в репортаже видны предупреждения и рекомендации.
Первое предупреждение, если перевести, говорит о том, что в шаблоне, в файле style.css обнаружен недопустимый тег.
Второе — в моей теме не хватает постраничной навигации на страницах с выводами анонсов (я до нее еще не добрался).
Ну и дальше идут рекомендации — в теме нет поддержки возможности описания меток, скриншот темы не соответствует размерам, нет возможности выбора цвета и картинки для фона сайта.
Что касается первых двух предупреждений — таких ошибок в вашей новой теме быть не должно !
А как быть, если шаблон очень подходит под тему вашего сайта, но в нем после проверки обнаружены ошибки? Если вы разбираетесь в функциях WordPress, то исправить их, если такие-же как на скрине, не составит труда. Ну или можно поручить исправление специалисту. Но работа специалиста стоит недешево. И стоит задуматься — а может найти другой шаблон, или за те-же деньги купить новый, валидный ?

Подробное описание okvision линзы на сайте.

Похожие по Тегам статьи

Проверка типа шаблона

Обзор проверки типа шаблона

Подобно тому, как TypeScript улавливает ошибки типа в вашем коде, Angular проверяет выражения и привязки в шаблонах вашего приложения и может сообщать о любых обнаруженных ошибках типа. Angular в настоящее время имеет три режима для этого, в зависимости от значения флагов fullTemplateTypeCheck и strictTemplates в файле конфигурации TypeScript .

Basic mode

В самом основном режиме проверки типов, fullTemplateTypeCheck флага fullTemplateTypeCheck установлено значение false , Angular проверяет только выражения верхнего уровня в шаблоне.

Если вы напишете <map [city]="user.address.city"> , компилятор проверит следующее:

• user является свойством класса компонента
• user — это объект со свойством адреса
• user.address — это объект со свойством города.

Компилятор не проверяет, можно ли user.address.city значение user.address.city входу city компонента <map> .

Компилятор также имеет некоторые существенные ограничения в этом режиме:

• Важно отметить, что он не проверяет встроенные представления, такие как *ngIf , *ngFor , другие встроенные представления <ng-template> .
• Он не определяет типы #refs , результаты каналов или тип $event в привязках событий.

Во многих случаях эти вещи заканчиваются типом any , что может привести к тому, что последующие части выражения не будут отмечены.

Full mode

Если для флага fullTemplateTypeCheck установлено значение true , Angular более агрессивно проверяет типы в шаблонах. Особенно:

• Встроенные представления (например, внутри *ngIf или *ngFor ) проверяются .
• Трубы имеют правильный тип возврата
• Локальные ссылки на директивы и каналы имеют правильный тип (за исключением любых универсальных параметров, которые будут any ) .

Далее по- прежнему имеют тип any .

• Локальные ссылки на элементы DOM
• Объект $ $event
• Безопасные навигационные выражения

fullTemplateTypeCheck флаг был устаревшим Угловая 13. strictTemplates семейства опций компилятора должен использоваться вместо этого.

Strict mode

Angular поддерживает поведение флага fullTemplateTypeCheck и вводит третий «строгий режим». Строгий режим — это надмножество полного режима, доступ к которому можно получить, установив для флага strictTemplates значение true. Этот флаг заменяет флаг fullTemplateTypeCheck . В строгом режиме Angular использует проверки, выходящие за рамки проверки типов версии 8.

ПРИМЕЧАНИЕ . Строгий режим доступен только при использовании Ivy.

В дополнение к поведению в полном режиме,Angular делает следующее:

• Проверяет, что привязки компонента/директивы могут быть назначены их @Input() s
• strictNullChecks TypeScript при проверке предыдущего режима.
• Выявляет правильный тип компонентов/директив,включая дженерики
• Выводит типы контекста шаблона, если они настроены (например, разрешая правильную проверку типов NgFor )
• Выводит правильный тип $event в компонентах/директивах, DOM и привязках событий анимации.
• Выводит правильный тип локальных ссылок на элементы DOM на основе имени тега (например, тип, который document.createElement вернет для этого тега) .

Проверка *ngFor

Три режима проверки типа по-разному относятся к встроенным представлениям.Рассмотрим следующий пример.

interface User {
  name: string;
  address: {
    city: string;
    state: string;
  }
}

<div *ngFor="let user of users">
  <h2>{{config.title}}</h2>
  <span>City: {{user.address.city}}</span>
</div>

<h2> и <span> находится в *ngFor встроенного представления. В базовом режиме Angular не проверяет ни один из них. Однако в полном режиме Angular проверяет наличие config и user и предполагает наличие any типа . В строгом режиме Angular знает, что user в <span> имеет тип User , и этот address является объектом со свойством city типа string .

Устранение ошибок шаблона

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

Могут быть и ложные срабатывания,когда наборы в библиотеке Angular либо неполные,либо неправильные,либо когда наборы не совсем соответствуют ожиданиям,как в следующих случаях.

• Когда типизация библиотеки неверна или неполна (например, отсутствует null | undefined , если библиотека не была написана с strictNullChecks )

• Когда типы входных данных библиотеки слишком узкие и библиотека не добавила соответствующие метаданные для Angular, чтобы понять это. Обычно это происходит с отключенными или другими обычными логическими входами, используемыми в качестве атрибутов, например, <input disabled> .

• При использовании $event.target для событий DOM (из-за возможности всплытия событий $event.target в типах DOM не имеет ожидаемого типа)

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

• Используйте функцию приведения типа $any() в определенных контекстах, чтобы отказаться от проверки типа для части выражения.
• Полностью отключите строгие проверки, установив strictTemplates: false в файле конфигурации TypeScript приложения, tsconfig.json .
• Отключите определенные операции проверки типов по отдельности, сохраняя при этом строгость в других аспектах, установив для флага строгости значение false .
• Если вы хотите использовать strictTemplates и strictNullChecks вместе, откажитесь от строгой проверки нулевого типа специально для входных привязок с использованием strictNullInputTypes .

Если не указано иное, для каждой следующей опции устанавливается значение для strictTemplates ( true , когда strictTemplates равно true , и наоборот, наоборот).

<input matInput disabled="true">

<input matInput [disabled]="true">

Если после устранения неполадок с этими флагами у вас все еще возникают проблемы, вернитесь в полный режим, отключив strictTemplates .

Если это не сработает, последний вариант — полностью отключить полный режим с помощью fullTemplateTypeCheck: false .

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

Входы и проверка типа

Проверка типа шаблона проверяет,совместим ли тип выражения привязки с типом соответствующей входной директивы.В качестве примера рассмотрим следующий компонент:

export interface User {
  name: string;
}

@Component({
  selector: 'user-detail',
  template: '{{ user.name }}',
})
export class UserDetailComponent {
  @Input() user: User;
}

В шаблоне AppComponent этот компонент используется следующим образом:

@Component({
  selector: 'app-root',
  template: '<user-detail [user]="selectedUser"></user-detail>',
})
export class AppComponent {
  selectedUser: User | null = null;
}

Здесь, во время проверки типа шаблона для AppComponent , тем [user]="selectedUser" связывания соответствует UserDetailComponent.user ввода. Следовательно, Angular назначает свойство selectedUser для UserDetailComponent.user , что приведет к ошибке, если их типы несовместимы. TypeScript проверяет присвоение в соответствии со своей системой типов, подчиняясь таким флагам, как strictNullChecks ,по мере их настройки в приложении.

Избегайте ошибок типа во время выполнения, предоставляя более конкретные требования к типу в шаблоне для средства проверки типа шаблона. Сделайте требования к типу ввода для ваших собственных директив как можно более конкретными, предоставив функции защиты шаблона в определении директивы. См. Раздел « Улучшение проверки типа шаблона для пользовательских директив» в этом руководстве.

Строгий нулевой контроль

Когда вы включаете strictTemplates и флаг TypeScript strictNullChecks , в определенных ситуациях могут возникать ошибки проверки типов, которых нелегко избежать. Например:

• Обнуляемое значение, привязанное к директиве из библиотеки, для которой не включен strictNullChecks .

  Для библиотеки, скомпилированной без strictNullChecks , ее файлы объявлений не будут указывать, может ли поле быть null или нет. Для ситуаций, когда библиотека обрабатывает null правильно, это проблематично, поскольку компилятор будет проверять значение, допускающее значение null, по файлам объявлений, которые пропускают null тип. Таким образом, компилятор выдает ошибку проверки типа, потому что он придерживается strictNullChecks .

• Использование async pipe с Observable, которое, как вы знаете, будет излучать синхронно.

  В настоящее время async канал предполагает, что Observable, на который он подписывается, может быть асинхронным, а это означает, что, возможно, пока нет доступного значения. В этом случае он все равно должен что-то вернуть — null . Другими словами, возвращаемый тип async канала включает null , что может привести к ошибкам в ситуациях, когда известно, что Observable синхронно выдает ненулевое значение.

Существует два возможных обходных пути решения вышеупомянутых проблем:

• Включите в шаблон ненулевой оператор утверждения ! в конце выражения, допускающего значение NULL, например

  <user-detail [user]="user!"></user-detail>

  В этом примере компилятор игнорирует несовместимость типов в допустимости значений NULL, как и в коде TypeScript. Обратите внимание, что в случае async канала выражение должно быть заключено в круглые скобки, как в

  <user-detail [user]="(user$ | async)!"></user-detail>

• Полностью отключите строгую нулевую проверку в угловых шаблонах.

  Когда strictTemplates включен, некоторые аспекты проверки типов по-прежнему можно отключить. Установка опции strictNullInputTypes в false отключает строгие проверки нуля в пределах угловых шаблонов. Этот флаг применяется ко всем компонентам, которые являются частью приложения.

Как автор библиотеки вы можете предпринять несколько мер для обеспечения оптимального взаимодействия с пользователями. Во-первых, включение strictNullChecks и включение null в тип ввода, в зависимости от ситуации, сообщает вашим потребителям, могут ли они предоставить значение, допускающее значение NULL, или нет. Кроме того, можно предоставить подсказки типа, специфичные для средства проверки типа шаблона. См. Разделы «Улучшение проверки типа шаблона для пользовательских директив» и « Принуждение установщика ввода» .

Принуждение входного задатчика

Иногда желательно, чтобы @Input() директивы или компонента изменяла привязанное к нему значение, обычно используя пару геттер / сеттер для ввода. В качестве примера рассмотрим этот компонент настраиваемой кнопки:

Рассмотрим следующую директиву:

@Component({
  selector: 'submit-button',
  template: `
    <div class="wrapper">
      <button [disabled]="disabled">Submit</button>
    </div>
  `,
})
class SubmitButton {
  private _disabled: boolean;

  @Input()
  get disabled(): boolean {
    return this._disabled;
  }

  set disabled(value: boolean) {
    this._disabled = value;
  }
}

Здесь disabled ввод компонента передается в <button> в шаблоне. Все это работает, как ожидалось, до тех пор, пока ко входу привязано boolean значение. Но предположим, что потребитель использует этот ввод в шаблоне как атрибут:

<submit-button disabled></submit-button>

Это имеет такое же действие,как и переплет:

<submit-button [disabled]="''"></submit-button>

Во время выполнения вводом будет пустая строка, которая не является boolean значением. Библиотеки компонентов Angular, которые решают эту проблему, часто «переводят» значение в правильный тип в установщике:

set disabled(value: boolean) {
  this._disabled = (value === '') || value;
}

Было бы идеально изменить тип value здесь с boolean на boolean|'' , чтобы соответствовать набору значений, которые фактически принимаются установщиком. TypeScript до версии 4.3 требует, чтобы и геттер, и сеттер имели один и тот же тип, поэтому, если получатель должен возвращать boolean то сеттер застревает на более узком типе.

Если у потребителя включена самая строгая проверка типов Angular для шаблонов, это создает проблему: пустая строка ( '' ) фактически не может быть назначена disabled полю, что создает ошибку типа при использовании формы атрибута.

В качестве обходного пути для этой проблемы Angular поддерживает проверку более широкого, более разрешающего типа для @Input() чем объявлено для самого поля ввода. Включите это, добавив статическое свойство с префиксом ngAcceptInputType_ к классу компонента:

class SubmitButton {
  private _disabled: boolean;

  @Input()
  get disabled(): boolean {
    return this._disabled;
  }

  set disabled(value: boolean) {
    this._disabled = (value === '') || value;
  }

  static ngAcceptInputType_disabled: boolean|'';
}

Начиная с TypeScript 4.3, можно было объявить установщик, принимающий boolean|'' качестве типа, что сделало бы поле принуждения установщика ввода устаревшим. Таким образом, поля принуждения установщиков ввода устарели.

Это поле не обязательно должно иметь значение. Его существование сообщает средству проверки типов Angular, что disabled ввод должен рассматриваться как принимающий привязки, соответствующие типу boolean|'' . Суффикс должен быть именем поля @Input .

Следует позаботиться о том, чтобы если для данного ввода присутствует переопределение ngAcceptInputType_ , то установщик должен иметь возможность обрабатывать любые значения переопределенного типа.

Отключение проверки типа с помощью $any()

Отключить проверку обязательного выражения, окружая выражение в вызове к $any() литой псевдо-функции . Компилятор рассматривает его как приведение к any типу, как и в TypeScript, когда используется <any> или as any приведение.

В следующем примере приведение person к any типу подавляет ошибку. Property address does not exist .

@Component({
  selector: 'my-component',
  template: '{{$any(person).address.street}}'
})
class MyComponent {
  person?: Person;
}

Последнее редактирование:Пн Фев 28 2022

Angular

15.0

• Template statements

  Операторы шаблонов-это методы или свойства,которые вы можете использовать в HTML для реагирования на события пользователя.

• Template syntax

  В Angular шаблон-это фрагмент HTML.

• Debugging tests

  Если ваши тесты не работают должным образом, вы можете проверить и отладить браузер.

• Testing

  Тестирование вашего приложения Angular помогает проверить,что оно работает так,как ожидается.