Comments 8
Самое главное не раскрыто. Чем обёртка над регекс лучше чем регекс? Я вижу только вариант когда вы сервер с укуренными нестандартными протоколами.
Привет, кажется, что суть этого вопроса раскрыта, несмотря на то, что под капотом мы получаем регулярное выражение, и работает с оберткой над ними. Но:
Синтаксис path-to-regexp читается и воспринимается легче, чем регулярные выражения, в конце статьи есть сравнение регулярного выражения и такой же проверки на URLPattern.
URLPattern позволяет нам задавать проверки по частям, тогда как склеить несколько регулярных выражений в одно будет сложнее. Особенно если мы пытаемся реиспользовать их в коде.
Также URLPattern помимо сопоставления проводит нормализацию, приведение кириллических доменов в Punicode и т.д. То есть выполняет очень много увлекательной и интересной работы, над которой никто даже не задумывается.
Думаю, можно с легкостью найти еще причины, по которым обертка над регулярными выражениями будет лучше. Это не универсальная обертка, а заточенная под потребности web-платформы. Не зря же ее разрабатывали.
Ваша регулярка IPv6-адрес в роли хоста проглотит или нет?
Очень хороший вопрос. Так как URLPattern - это инструмент для работы с URL, то он должен уметь работать с любым его видом. URL имеет формат <scheme>:<specific-scheme-part>, где specific-scheme-part - это не пустая ASCII-строка. Поэтому допустимы различные вариации hostname, в том числе и с IPv6. Но регулярное выражение там будет сильно мудреное и сложное, а также нужно будет учесть различные моменты с экранированием символов (оно немного отличается от regexp).
Ради эксперимента провел опыты с другими вариациями:
Пример с телефоном, который ограничен 11-символами, НО в разных странах может быть другое количество символов. Здесь работаем с протоколом `tel`, а не с привычными http/https.
new URLPattern('tel:\\+(\\d{11})');
Пример с IPv4, где последний октет может быть любым, в идеале можно довести до проверки от 0 до 255, но думаю принцип будет понятен и здесь.
new URLPattern({ hostname: '(192.168.0.\\d{1,3})' });
Скажу сразу, почти никогда не работал с IPv6, особенно в плане разбора его каким-то регулярным выражением, сделал вот такую реализацию, и она вряд ли соответствует всем правилам для IPv6. Но ее вполне можно развивать, добавляя больше ограничений, приводя ее к нужному нам виду.
new URLPattern({ hostname: '(\\[[0-9a-fA-F:]+\\])' });
Надеюсь удалось ответить на вопрос.
Вопрос был не к вам, как автору статьи, а тем, кто каждый гвоздь регулярками забивает. В вашем же ответе и IPv6, и IPv4, и телефонный номер неверны.
M2M sim cards are ... up to 15 characters
M2M sim cards are for machine-to-machine communication and are up to 15 characters long. Typically they are used for data and SMS messages, however there are cases in which someone may voice-call an M2M sim. One example is for in-home & roaming telecare/medical alarms, in the event of an alarm activation then automated voice messages can be played on the device via telephony APIs, or a human may call the device directly (potentially also via a telephony API).
IPv4 может быть десятичным, восьмиричным, шестнадцатиричным. И даже одним числом. IPv6 в один проход всё равно не провалидируешь.
Понял, если вопрос именно к тому насколько целесообразно использовать регулярные выражения для IPv6 и подобных сущностей. То ответ будет: в теории - можно. Но на практике, скорее всего будет легче использовать несколько функций, проверяющих отдельные части или что-нибудь подобное, как вы выразились "в один проход не провалидируешь". Скорее всего, если использовать регулярное выражение будет не сильно сложно для валидации URL, то вероятнее в URLPattern это будет делать проще.
Я бы еще сказал, что инструмент универсальный, и ждать от него легкого решения любой проблемы не стоит, будут ситуации, где он даст слабину. Но для большинства кейсов с ссылками может вполне неплохо работать. Также можно отдельно проверять пути в роутере (например, user/:userId) - тут как будто очень хорошо. Случай с IPv6 кажется менее используемый по сравнению с остальными, да и сам адрес в разы сложнее того же IPv4 или телефона.
Соглашусь, что регулярные выражения хоть и мощный инструмент, но не всегда он идеально решает проблемы. Стоит изучать инструменты, чтобы понимать на что они способны, какие минусы у них есть, чтобы решать ваши задачи с максимальным КПД.
Регулярка проверки url не так проста. Например, допускать номер порта по умолчанию соответствующий протоколу (чтобы проходило http://example.com:80 и https://example.com:443, но не наоборот). Ещё надо нормализовывать хосты (преобразовать punicode, игнорировать регистр). Ещё какой-нибудь IPv6 в качестве хоста не так уж тривиально парсится регуляркой.
В общем, куча corner case, которые технически реализуемы, но тянут на целый отдельный модуль (а в мире npm и на библиотеку). Теперь будет из коробки.
Понятное дело, что в простых случаях хватает вообще startswith, но шаг влево шаг вправо и всё становится резко сложнее.
URLPattern — pattern matching, который мы ждали