тогда вопрос, зачем он нужен

ну ты такой в чатах like a boss можешь писать что рельса гавно и оверхед и оверскилл

скорее ты можешь задать явно типизированную схему для валидации и для дата объектов

тогда вопрос, зачем он нужен

затем, что dry-* это не про попытку сделать из руби строготипизированный функциональный язык

я пока с dry столкнулся в виде модуля импорта из xlsx

dry предоставляет удобный IoC, это с фп связанно как-то никак

кто-то его туда раньше вкрутил, и я уже давно морально готовлючь выпились нафиг

почитав код вижу только вкряченную типизацию для валидаций

dry предоставляет удобный IoC, это с фп связанно как-то никак

по сути, основная идея dry в том, что он пропогандирует декомпозицию на функциональные объекты (оперейшены, сервисы, етц) и работу с этими объектами

почитав код вижу только вкряченную типизацию для валидаций

1. это только малая часть dry 2. кто-то, судя потому, что ты написал, решил сделать нормальную схему ваших данных для xlsx, вот и все

ага, и судя по всему на пол пути ему надоел список типов в 200 строк и он завернул все в хэши

и стла проверять что из парсилки приходит хэш

круто

я не видел код, так что я ничего не могу сказать тебе

вообще есть где-нибудь примеры его адекватного использования?

в целом это выглядит вот так: 1. ты объявляешь схему данных

после чего, вызываешь call у схемы и передаешь туда твои данные

получаешь объект, который говорит валидны данные в зависимости от схемы или нет

все

вообще есть где-нибудь примеры его адекватного использования?

http://dry-rb.org/gems/dry-validation/

это дока

получаешь объект, который говорит валидны данные в зависимости от схемы или нет

это единственное, зачем нужен dry-validation

это дока

а в доке не бывает примеров адекватного испольования?

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

это пример синтаксиса, а не использования

мне интересен именно пример ситуации, когда оно реально нужно и полезно

тут недавно митап был в здании телеграфа, там мужик рассказывал, как использовать dry вместо валидаций ActiveRecord

но так и не рассказал, зачем

да, интересно зачем

это просто как альтернатива?

ну типа того

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

основная проблема в: 1. существует не только рельса и грейп 2. даже с рельсой оно работает хорошо https://mensfeld.pl/2017/03/dry-validation-as-a-schema-validation-layer-for-ruby-on-rails-api/

мне интересен именно пример ситуации, когда оно реально нужно и полезно

ну ок, ситуации: 1. мы в ханами используем dry-v для валидации параметров под каждый эндпоинт. То же делается в трейлблейзере и в dry-web. 2. ты можешь самостоятельно использовать такую штуку в той же синатре, и тебе не придется тащить AR, сиквела будет достаточно 3. ты можешь проверять вообще любые данные, например в клиенте к API

да, интересно зачем

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

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

когда валидация изолированна от модели, ты можешь написать 2 схемы и абсолютно легко и не зависимо проверять твои данные где угодно и как угодно

ну это вопрос одно if: lambda {} по сути, и если написать две схемы на dry то этот if просто будет в другом месте

ну это вопрос одно if: lambda {} по сути, и если написать две схемы на dry то этот if просто будет в другом месте

ты же понимаешь, что это говнокод?

объясню даже почему

тоесть, по большей части dry используется вне Рельсы для получения отсусвтующего функционала?

1. ты добавляешь условие с лямбдой, которое достаточно сложно читается и тестируется. 2. что будешь делать, когда у тебя будет 4 эндпоинта для поста и везде разная валидация?

ты же понимаешь, что это говнокод?

говнокод конечно, но как dry позволит его обойти?

тоесть, по большей части dry используется вне Рельсы для получения отсусвтующего функционала?

скорее dry нужен для декомпозиции твоей логики и последующей работы с ней изолированно

Использовать разные схемы в клнтроллерах?

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

говнокод конечно, но как dry позволит его обойти?

Admin::CreateScheme Web::CreateScheme Admin::UpdateScheme ...

вот, нашел. для рельсы есть вот такая штука, которую я не проверял https://github.com/kirs/dry-params

вот кста под это очень ок dry-v подходит, ибо strong parameters в рельсе тупая довольно штука

вот кста под это очень ок dry-v подходит, ибо strong parameters в рельсе тупая довольно штука

именно. ты не имеешь никакого контроля с ней

Они рано или поздно обыграют это чем-то

что делать, если у тебя может быть параметр только строкой, но тебе пихают число? например какой-нибудь мамкин хацкер руками запрос с данными закинет тебе

Они рано или поздно обыграют это чем-то

а вот тут сложнее

да, тупо проверка что там есть _что-то_ или нихуя, работаешь с этим а потом при сохранении модель такая - а вот хуй, не валидно же

как мне говорил аарон и другой кор разработчик, проблема рельсы в ее инертности и очень сложно делать что-то новое ибо люди сложно принимают это

да, тупо проверка что там есть _что-то_ или нихуя, работаешь с этим а потом при сохранении модель такая - а вот хуй, не валидно же

итого, ты делаешь 2 валидации в 2ух местах, так?

1. ты проверяешь одно поле в контроллере, а потом проверяешь это все в моделе

именно так)

тебе не кажется это немного странным?

для этого конеш можно накостылить FormObject но думаю dry-v тут вообще ок подойдёт

для этого конеш можно накостылить FormObject но думаю dry-v тут вообще ок подойдёт

ты можешь использовать форм объект с драй валидацией тоже

да, я наверное хуёво излагаю мысли, но вижу плюсы dry-v

ты можешь использовать форм объект с драй валидацией тоже

но зачем?

форм обжекты ж вроде и нужны чтобы проверить структуру данных, не?

dry-v и вообще dry-* не говорят вам, что мол что-то говно и не используйте это. они говорят, что используете изолированные объекты и держите логику в одном месте

форм обжекты ж вроде и нужны чтобы проверить структуру данных, не?

не только

ERROR: S client not available

простой пример, тебе пост пришел в мд, а его надо в html сохранить, что бы показывать

ты можешь это делать в форм объекте

например, если говорить про dry-matcher, то это тоже полезная штука

т.е. не только проверить данные но и подготовить?

т.е. не только проверить данные но и подготовить?

форм объект - да

например, если говорить про dry-matcher, то это тоже полезная штука

у меня есть реальный юз кейс, где это работает

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

вот так это выглядит в экшене

https://github.com/ossboard-org/ossboard/blob/master/apps/api/controllers/issue/show.rb#L24-L28

а вот сам матчер https://github.com/ossboard-org/ossboard/blob/master/lib/ossboard/matchers/git_host_matcher.rb

Антон всех задавил драем :)

ну зато мб в будущем не будет мнения, что dry - это такой вот рейлс киллер или что это попытка сделать строготипизированный руби :)

Всем привет! А руби вообще актуален? А то решил перейти с пхп на руби, и пару раз мелькало, типа "руби мертв" и тому подобное

нет. Учи OCaml, не промахнешься

нет. Учи OCaml, не промахнешься

два чая господину

прямо дело говорит

а вот сам матчер https://github.com/ossboard-org/ossboard/blob/master/lib/ossboard/matchers/git_host_matcher.rb

А это нормально объявлять GITHUB_ISSUE_REGEXP на верхнем уровне?

если говорить про dry-container, то там есть один очень крутой пример, как можно легко избавится от толстохудых моделей и контроллеров

А это нормально объявлять GITHUB_ISSUE_REGEXP на верхнем уровне?

ну типа константа же

все так делают О_О

А это нормально объявлять GITHUB_ISSUE_REGEXP на верхнем уровне?

не, не очень. это говнокод имхо

ну в рельсах много такого, кек

я бы лучше обернул все в Matchers::GitHost::Matcher

ну типа константа же

Это должно быть в своем неймспейсе

но коду уже больше полугода и писался он просто для проверки идеи

ну собственно да, это надо оборачивать в неймспейс в идеале

но основная идея в том, что такие штуки работают и помогают жить

например, такой код просто тестировать

Это должно быть в своем неймспейсе

осталось рельсы перепилить )

осталось рельсы перепилить )

Там есть подобное?

Там есть подобное?

много где

особенно регекспы так любят