Да, в целом из коробки будет довольно много вещей, но кажется, что как раз таки IPv6 или те самые корнер-кейсы все же придется решать самому. А вот как раз базовые вещи, которые встречаются повсеместно можно делать из нативно. Как раз выше обсуждали про регулярные выражения для разных ситуаций.
Понял, если вопрос именно к тому насколько целесообразно использовать регулярные выражения для IPv6 и подобных сущностей. То ответ будет: в теории - можно. Но на практике, скорее всего будет легче использовать несколько функций, проверяющих отдельные части или что-нибудь подобное, как вы выразились "в один проход не провалидируешь". Скорее всего, если использовать регулярное выражение будет не сильно сложно для валидации URL, то вероятнее в URLPattern это будет делать проще.
Я бы еще сказал, что инструмент универсальный, и ждать от него легкого решения любой проблемы не стоит, будут ситуации, где он даст слабину. Но для большинства кейсов с ссылками может вполне неплохо работать. Также можно отдельно проверять пути в роутере (например, user/:userId) - тут как будто очень хорошо. Случай с IPv6 кажется менее используемый по сравнению с остальными, да и сам адрес в разы сложнее того же IPv4 или телефона.
Соглашусь, что регулярные выражения хоть и мощный инструмент, но не всегда он идеально решает проблемы. Стоит изучать инструменты, чтобы понимать на что они способны, какие минусы у них есть, чтобы решать ваши задачи с максимальным КПД.
Очень хороший вопрос. Так как 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:]+\\])' });
Привет, кажется, что суть этого вопроса раскрыта, несмотря на то, что под капотом мы получаем регулярное выражение, и работает с оберткой над ними. Но:
Синтаксис path-to-regexp читается и воспринимается легче, чем регулярные выражения, в конце статьи есть сравнение регулярного выражения и такой же проверки на URLPattern.
URLPattern позволяет нам задавать проверки по частям, тогда как склеить несколько регулярных выражений в одно будет сложнее. Особенно если мы пытаемся реиспользовать их в коде.
Также URLPattern помимо сопоставления проводит нормализацию, приведение кириллических доменов в Punicode и т.д. То есть выполняет очень много увлекательной и интересной работы, над которой никто даже не задумывается.
Думаю, можно с легкостью найти еще причины, по которым обертка над регулярными выражениями будет лучше. Это не универсальная обертка, а заточенная под потребности web-платформы. Не зря же ее разрабатывали.
Я абсолютно и полностью с вами согласен. Но не все это знают, а некоторые предлагают так вадилировать и находятся в первых ссылках в поиске, а сейчас и GPT подхватывает этот тренд, как тут не поверить в то, что так можно валидировать?
Не обязательно ручками, можно проверять с помощью библиотек. К сожалению, я не проводил анализа популярных решений, поэтому не могу порекомендовать какую-либо.
"Можно договориться устно. Для команды из 3–5 человек достаточно договоренностей. Устные договоренности снижают издержки и повышают гибкость." Договориться можно, но в результате договора хорошо бы иметь какой-то документ, который описывает эти договоренности. Потому что завтра придет 6-ой человек и ему обязательно забудут что-то рассказать, после чего он нарушит эти договоренности, потому что не в курсе. Даже если вы один в команде и договариваетесь сами с собой, то все равно создать артефакты ваших решений было бы очень правильно, потому что можно уволиться и оставить проект без контекста в вашей голове.
Тогда это сработает, если оба типа содержат поле, которое их идентифицирует, иначе придется писать маппер и что-то добавлять. Но тогда это опять проще сделать через type guard.
А если такое приходит с бэкенда, то это получается "хорошее" решение, чтобы закостылить плохое поведение на бэкенда. Как ты и сказал, так "не стоит так делать".
Даже есть есть такое поле-идентификатор, то что мешает сделать на его основе type guard? Тогда и городить огород не придется.
Не совсем понял про данные с бэкенда. Обычно оттуда прилетает dto с определенным типом. Потом нам для него надо сделать маппинг в такую же dto только с типом success, чтобы показать что это не ошибка? Если речь об этом, то можно вернуть объект с тремя рациональными полями, которые будут содержать в себе модели для состояния loading, hasValue, error. В плане объема кода будет примерно столько же. Чуть увеличится вложенность, но наверное на уровне пропсов это получится. Но возможно, я не очень понял проблему данных с бэкенда.
Как будто у нас есть тип A и тип B, а потом мы каждому добавляем ещё одно поле, чтобы их различать между собой. Такое ощущение, что что-то пошло не так.
Возможно, эту проблему можно решить через type guard?
Кажется, что здесь проблема с приоритезацией задач. Должен быть некий менеджер проекта, который будет говорить что очень важно, а что не важно. Другие могут только добавлять вводные, например, я как разработчик могу повлиять на включение техдолга, который заблокирует разработку или что-нибудь подобное.
Цель спринта как решение проблемы не очень понятно что даст, так как проблема описанная в статье может быть и в канбане. В целом, задача сама по себе должна давать понимание того, зачем она нужна, без цели спринта.
Приоритезация - это то, что решит проблему.
DoD - не всегда должен влиять на клиента, могут быть технические оптимизации. Не стоит смешивать критерии завершенности задачи и клиента
Это был "совковый" метод контроля разработчиков, чтобы мы не котиков смотрели, а код писали. Размеры выдались разные от 300мб, то нескольких Гб. Один раз тимлид смог продавить реформу и всем дали по 10Гб.
А за повышение отключали интернет, надо было написать заявку на админов, они или добавляли трафика немного, то ли обнуляли "пакет", точно не помню уже.
Интернет у меня с 2010 еще в общаге был безлимитный, и все было относительно хорошо. Это особенности той компании, чтобы работники не смотрели картинки, вместо работы)
Есть одна небольшая компания в Екатеринбурге. Название говорить уж не буду. У меня по приходу туда было 2Гб трафика, а потом с подачи тимлида подняли лимит до 10Гб и я был местным мажором) Приходилось изгаляться, поставил расширение, которое блочит не только рекламу, но и скрывает изображения. И дополнительно узнали, что teamviewer не учитывался в трафике и можно было тогда через него смотреть что-нибудь через свой домашний ПК) А ограничение было вроде до момента ухода, это был уже 2018 год. Как сейчас дела не знаю)
Работал в одной компании, где было ограничение трафика для всех, в том числе и разработчиков. У одного коллеги было 300мб на месяц в 2016 году. Он их "сжег" за 5 минут, потому что опечатался и гугл выдал ему вместо stackoverflow - catoverflow. На сайте оказались гифки с котиками)
Понятия не имею, если честно. Я не эксперт в ракетостроении, знаю что есть стартап, который делает центрифугу. Знаю, что проводят уже испытания на прототипах. И у них нет цели выводить на орбиту много груза, они хотят выводить небольшие спутники.
Вроде как идея и заключается в том, чтобы запустить ракету в полет с помощью центрифуги, а потом уже включить двигатели. По сути идея в замене первой ступени ракеты на центрифугу.
Уже есть такой стартап SpinLaunch, который с помощью центрифуги раскручивает ракету и потом запускает ее в космос. Но пока результатов не сильно много. Но рабочие прототипы есть и ведутся исследования.
Да, в целом из коробки будет довольно много вещей, но кажется, что как раз таки IPv6 или те самые корнер-кейсы все же придется решать самому. А вот как раз базовые вещи, которые встречаются повсеместно можно делать из нативно. Как раз выше обсуждали про регулярные выражения для разных ситуаций.
Понял, если вопрос именно к тому насколько целесообразно использовать регулярные выражения для IPv6 и подобных сущностей. То ответ будет: в теории - можно. Но на практике, скорее всего будет легче использовать несколько функций, проверяющих отдельные части или что-нибудь подобное, как вы выразились "в один проход не провалидируешь". Скорее всего, если использовать регулярное выражение будет не сильно сложно для валидации URL, то вероятнее в URLPattern это будет делать проще.
Я бы еще сказал, что инструмент универсальный, и ждать от него легкого решения любой проблемы не стоит, будут ситуации, где он даст слабину. Но для большинства кейсов с ссылками может вполне неплохо работать. Также можно отдельно проверять пути в роутере (например,
user/:userId) - тут как будто очень хорошо. Случай с IPv6 кажется менее используемый по сравнению с остальными, да и сам адрес в разы сложнее того же IPv4 или телефона.Соглашусь, что регулярные выражения хоть и мощный инструмент, но не всегда он идеально решает проблемы. Стоит изучать инструменты, чтобы понимать на что они способны, какие минусы у них есть, чтобы решать ваши задачи с максимальным КПД.
Очень хороший вопрос. Так как URLPattern - это инструмент для работы с URL, то он должен уметь работать с любым его видом. URL имеет формат
<scheme>:<specific-scheme-part>, гдеspecific-scheme-part- это не пустая ASCII-строка. Поэтому допустимы различные вариации hostname, в том числе и с IPv6. Но регулярное выражение там будет сильно мудреное и сложное, а также нужно будет учесть различные моменты с экранированием символов (оно немного отличается от regexp).Ради эксперимента провел опыты с другими вариациями:
Надеюсь удалось ответить на вопрос.
Привет, кажется, что суть этого вопроса раскрыта, несмотря на то, что под капотом мы получаем регулярное выражение, и работает с оберткой над ними. Но:
Синтаксис path-to-regexp читается и воспринимается легче, чем регулярные выражения, в конце статьи есть сравнение регулярного выражения и такой же проверки на URLPattern.
URLPattern позволяет нам задавать проверки по частям, тогда как склеить несколько регулярных выражений в одно будет сложнее. Особенно если мы пытаемся реиспользовать их в коде.
Также URLPattern помимо сопоставления проводит нормализацию, приведение кириллических доменов в Punicode и т.д. То есть выполняет очень много увлекательной и интересной работы, над которой никто даже не задумывается.
Думаю, можно с легкостью найти еще причины, по которым обертка над регулярными выражениями будет лучше. Это не универсальная обертка, а заточенная под потребности web-платформы. Не зря же ее разрабатывали.
Я абсолютно и полностью с вами согласен. Но не все это знают, а некоторые предлагают так вадилировать и находятся в первых ссылках в поиске, а сейчас и GPT подхватывает этот тренд, как тут не поверить в то, что так можно валидировать?
Программистам свойственно давать не только имена в соответствии с тем, как они живут/думают и в каких обстоятельствах работают.
Есть закон Конвея, по которому команды строят взаимодействие сервисов и приложений аналогично тому, как эти команды общаются между собой.
И вам спасибо!
Не обязательно ручками, можно проверять с помощью библиотек. К сожалению, я не проводил анализа популярных решений, поэтому не могу порекомендовать какую-либо.
И вам спасибо! Рад, что эти знания пригодятся кому-то еще!
"Можно договориться устно. Для команды из 3–5 человек достаточно договоренностей. Устные договоренности снижают издержки и повышают гибкость."
Договориться можно, но в результате договора хорошо бы иметь какой-то документ, который описывает эти договоренности. Потому что завтра придет 6-ой человек и ему обязательно забудут что-то рассказать, после чего он нарушит эти договоренности, потому что не в курсе. Даже если вы один в команде и договариваетесь сами с собой, то все равно создать артефакты ваших решений было бы очень правильно, потому что можно уволиться и оставить проект без контекста в вашей голове.
Тогда это сработает, если оба типа содержат поле, которое их идентифицирует, иначе придется писать маппер и что-то добавлять. Но тогда это опять проще сделать через type guard.
А если такое приходит с бэкенда, то это получается "хорошее" решение, чтобы закостылить плохое поведение на бэкенда. Как ты и сказал, так "не стоит так делать".
Даже есть есть такое поле-идентификатор, то что мешает сделать на его основе type guard? Тогда и городить огород не придется.
Не совсем понял про данные с бэкенда. Обычно оттуда прилетает dto с определенным типом. Потом нам для него надо сделать маппинг в такую же dto только с типом success, чтобы показать что это не ошибка? Если речь об этом, то можно вернуть объект с тремя рациональными полями, которые будут содержать в себе модели для состояния loading, hasValue, error. В плане объема кода будет примерно столько же. Чуть увеличится вложенность, но наверное на уровне пропсов это получится. Но возможно, я не очень понял проблему данных с бэкенда.
Как будто у нас есть тип A и тип B, а потом мы каждому добавляем ещё одно поле, чтобы их различать между собой. Такое ощущение, что что-то пошло не так.
Возможно, эту проблему можно решить через type guard?
Кажется, что здесь проблема с приоритезацией задач. Должен быть некий менеджер проекта, который будет говорить что очень важно, а что не важно. Другие могут только добавлять вводные, например, я как разработчик могу повлиять на включение техдолга, который заблокирует разработку или что-нибудь подобное.
Цель спринта как решение проблемы не очень понятно что даст, так как проблема описанная в статье может быть и в канбане. В целом, задача сама по себе должна давать понимание того, зачем она нужна, без цели спринта.
Приоритезация - это то, что решит проблему.
DoD - не всегда должен влиять на клиента, могут быть технические оптимизации. Не стоит смешивать критерии завершенности задачи и клиента
Это был "совковый" метод контроля разработчиков, чтобы мы не котиков смотрели, а код писали. Размеры выдались разные от 300мб, то нескольких Гб. Один раз тимлид смог продавить реформу и всем дали по 10Гб.
А за повышение отключали интернет, надо было написать заявку на админов, они или добавляли трафика немного, то ли обнуляли "пакет", точно не помню уже.
Интернет у меня с 2010 еще в общаге был безлимитный, и все было относительно хорошо. Это особенности той компании, чтобы работники не смотрели картинки, вместо работы)
Есть одна небольшая компания в Екатеринбурге. Название говорить уж не буду. У меня по приходу туда было 2Гб трафика, а потом с подачи тимлида подняли лимит до 10Гб и я был местным мажором) Приходилось изгаляться, поставил расширение, которое блочит не только рекламу, но и скрывает изображения. И дополнительно узнали, что teamviewer не учитывался в трафике и можно было тогда через него смотреть что-нибудь через свой домашний ПК)
А ограничение было вроде до момента ухода, это был уже 2018 год. Как сейчас дела не знаю)
Работал в одной компании, где было ограничение трафика для всех, в том числе и разработчиков. У одного коллеги было 300мб на месяц в 2016 году. Он их "сжег" за 5 минут, потому что опечатался и гугл выдал ему вместо stackoverflow - catoverflow. На сайте оказались гифки с котиками)
Понятия не имею, если честно. Я не эксперт в ракетостроении, знаю что есть стартап, который делает центрифугу. Знаю, что проводят уже испытания на прототипах. И у них нет цели выводить на орбиту много груза, они хотят выводить небольшие спутники.
Вроде как идея и заключается в том, чтобы запустить ракету в полет с помощью центрифуги, а потом уже включить двигатели. По сути идея в замене первой ступени ракеты на центрифугу.
Уже есть такой стартап SpinLaunch, который с помощью центрифуги раскручивает ракету и потом запускает ее в космос. Но пока результатов не сильно много. Но рабочие прототипы есть и ведутся исследования.