Статья очень интересная, сам хотел буквально пару месяцев назад писать что-то подобное, только про проявления и развитие парадигмы ФП в JS. JS изначально был попыткой перенести функциональный Sheme за 10 дней в браузеры. А после, чтобы другие браузеры могли его использовать завели уже стандарт EcmaScript, но уже как ООП (чтобы новый стандарт приняли благосклонно), ну и в последствии развитие шло в разных направлениях. Что-то добавляли от ФП, например стрелочные (лямбда) функции, что-то от ООП - классы.
В целом, мультипарадигменность - это как раз и не ФП и не ООП.
Касательно социализации, есть люди, которым хорошо даётся писать хороший код, но плохо даётся общаться с людьми (застенчивость, скромность и другой набор проблем с социализацией). Мне допустим много раз было тяжело продавить свое мнение/идею, хотя она была объективно лучше. Я не умею спорить ни аргументированно, ни не аргументированно. Из-за этого приходилось страдать от чужих плохих решений.
Вот тут, кажется софт-скиллы - это то, что должно развиваться и приносить пользу для хард скиллов.
P.S. Можно выносить все на документальные обсуждения с за и против, но это должен быть налажен процесс, а он есть не везде.
Полностью согласен, архитектура есть везде и в сайте когтеточек тоже. В своей мысли я подразумевал под архитектурой что-то похожее на system design интервью. Когда надо продумать какие приложения и как будут взаимодействовать, какие роли, какие контракты. Наличие очередей и кэшей. И много всего подобного. В общем, речь шла про проектирование, а не про кодирование.
У каждого свои интересы. Кому-то интересно писать каждую букву своими руками, а кому-то наоборот - хочется складывать приложение из больших/средних кубиков не создавая каждую функцию своими руками. Кто-то больше любит думать про архитектуру и высокие материи, кто-то запариваться за код функции, чтобы выжать максимум из нее. Так что тут "каждому свое".
В мире нет 100% гарантии ни на что при разработке ПО. У Яндекса был постмортрем, что датацентр отключился из-за того, что вышли из строя основная и резервная линия электропитания, думаю таких примеров может быть сотни. Политика, погода, строители - кто угодно может повлиять на работу ПО.
Как-то лет 10 назад я переделывал работу за своим коллегой, который для встраивания виджета добавил jQuery, чтобы сократить количество строк в запросе. В итоге чистый XHR (тогда fetch только-только зараждался) занял у меня порядка 10 строк, у него было 6 строк + jQuery. И как будто я уже не видел приложений, которые делают пару запросов, обычно это пара десятков.
Хотелось бы увидеть ссылку на статью, или методику подсчёта цифры в 90%.
Если рассматривать первый пункт с отпиской, то можно было добавить takeUntilDestroyed, относительно новая штука.
Полагаться на any? Идея писать на Typescript и родилась из-за того, чтобы не писать на JavaScript, который по сути any.
На счёт модулей, уже несколько версий как singleton-компоненты идут по умолчанию. А сделать "божественный компонент" гораздо сложнее, чем модуль.
Касательно сервисов, они не предназначены быть синглтоном. В документации об этом не сказано. Сервисы нужны для обработки логики. А синглтон - просто паттерн, чтобы сделать один экземпляр сервиса на приложение, если так надо.
Хранить версию в строке, это нормально. Потому что будут всякие alpha, релиз-кандидаты и прочие версии, например "1.0.0rc".
Но можно вполне сравнивать версии имея их список, и смотреть между какими версиями находится текущая в списке. Простой и дешёвый вариант. Можно ещё заняться разложением на объект и там уже магию строки принять к последнему элементу.
Да, в целом из коробки будет довольно много вещей, но кажется, что как раз таки 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. В плане объема кода будет примерно столько же. Чуть увеличится вложенность, но наверное на уровне пропсов это получится. Но возможно, я не очень понял проблему данных с бэкенда.
Статья очень интересная, сам хотел буквально пару месяцев назад писать что-то подобное, только про проявления и развитие парадигмы ФП в JS. JS изначально был попыткой перенести функциональный Sheme за 10 дней в браузеры. А после, чтобы другие браузеры могли его использовать завели уже стандарт EcmaScript, но уже как ООП (чтобы новый стандарт приняли благосклонно), ну и в последствии развитие шло в разных направлениях. Что-то добавляли от ФП, например стрелочные (лямбда) функции, что-то от ООП - классы.
В целом, мультипарадигменность - это как раз и не ФП и не ООП.
Статья интересная, выводы тоже.
Касательно социализации, есть люди, которым хорошо даётся писать хороший код, но плохо даётся общаться с людьми (застенчивость, скромность и другой набор проблем с социализацией). Мне допустим много раз было тяжело продавить свое мнение/идею, хотя она была объективно лучше. Я не умею спорить ни аргументированно, ни не аргументированно. Из-за этого приходилось страдать от чужих плохих решений.
Вот тут, кажется софт-скиллы - это то, что должно развиваться и приносить пользу для хард скиллов.
P.S. Можно выносить все на документальные обсуждения с за и против, но это должен быть налажен процесс, а он есть не везде.
Полностью согласен, архитектура есть везде и в сайте когтеточек тоже. В своей мысли я подразумевал под архитектурой что-то похожее на system design интервью. Когда надо продумать какие приложения и как будут взаимодействовать, какие роли, какие контракты. Наличие очередей и кэшей. И много всего подобного. В общем, речь шла про проектирование, а не про кодирование.
А CRUD-ы и правда выходят очень хорошо и быстро.
У каждого свои интересы. Кому-то интересно писать каждую букву своими руками, а кому-то наоборот - хочется складывать приложение из больших/средних кубиков не создавая каждую функцию своими руками. Кто-то больше любит думать про архитектуру и высокие материи, кто-то запариваться за код функции, чтобы выжать максимум из нее. Так что тут "каждому свое".
В мире нет 100% гарантии ни на что при разработке ПО. У Яндекса был постмортрем, что датацентр отключился из-за того, что вышли из строя основная и резервная линия электропитания, думаю таких примеров может быть сотни. Политика, погода, строители - кто угодно может повлиять на работу ПО.
Интересное опровержение:
- Ты Сатоши Накомото
- Я не Сатоши Накомото
Информация опровергнута.
Как-то лет 10 назад я переделывал работу за своим коллегой, который для встраивания виджета добавил jQuery, чтобы сократить количество строк в запросе. В итоге чистый XHR (тогда fetch только-только зараждался) занял у меня порядка 10 строк, у него было 6 строк + jQuery.
И как будто я уже не видел приложений, которые делают пару запросов, обычно это пара десятков.
Хотелось бы увидеть ссылку на статью, или методику подсчёта цифры в 90%.
Если рассматривать первый пункт с отпиской, то можно было добавить takeUntilDestroyed, относительно новая штука.
Полагаться на any? Идея писать на Typescript и родилась из-за того, чтобы не писать на JavaScript, который по сути any.
На счёт модулей, уже несколько версий как singleton-компоненты идут по умолчанию. А сделать "божественный компонент" гораздо сложнее, чем модуль.
Касательно сервисов, они не предназначены быть синглтоном. В документации об этом не сказано. Сервисы нужны для обработки логики. А синглтон - просто паттерн, чтобы сделать один экземпляр сервиса на приложение, если так надо.
Хранить версию в строке, это нормально. Потому что будут всякие alpha, релиз-кандидаты и прочие версии, например "1.0.0rc".
Но можно вполне сравнивать версии имея их список, и смотреть между какими версиями находится текущая в списке. Простой и дешёвый вариант. Можно ещё заняться разложением на объект и там уже магию строки принять к последнему элементу.
Да, в целом из коробки будет довольно много вещей, но кажется, что как раз таки 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. В плане объема кода будет примерно столько же. Чуть увеличится вложенность, но наверное на уровне пропсов это получится. Но возможно, я не очень понял проблему данных с бэкенда.