Пацаны, а кто тут евангелист dry? (@davydovanton)

Решил я тут попользовать dry-validation для обработки параметров в контроллере. Вопрос в том, а где предлагается производить трансформацию параметров? Например:

На вход приходит {price: 100, ...}
Интерактор ожидает на входе {price_from: 100, ... }

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

А каким образом предлагается проводить трансформацию? Ещё одна прослойка между контрактом и бизнес-логикой?

Всем привет.
Возник такой вопрос, можно ли как-то вызывать метод перед вызовом методов класса, не модифицируя сам класс?

def new_method
method
method_2
end

Не подойдет?

Точно таким же, каким бы она проводилась без dry-v

Без dry-v я бы сделал это внутри контракта, но они предлагают делать это за пределами

Понятно, что я могу сделать, меня интересует их философия в данном случае

Dry-v нужен для валидации. Все.
Не для того что бы ключи перетасовывать.

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

ну валидации всякие бывают, да. не забывай, что в dry-v ещё есть часть с приведением типов

Приведение типов цэ не манипуляции с ключами

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

вообще, стоит взять transproc, который уже https://github.com/dry-rb/dry-transformer, и просто воткнуть его как следующий шаг после валидации

типа

raw_validated_params = yield Contract.call(input)
validated_params = transformer.call(raw_validated_params)

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

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

Вот типо такого


https://github.com/davydovanton/rubyjobs.dev/tree/master/lib/vacancies/mappers

Как видишь, драй тут вообще не нужен

Да не, понятно, что драй тут не нужен. Можешь пояснить логику, почему dry предлагает делать это не в самом контракте?

а как эта логика вписывается в идею контракта? я вот это не понял сейчас

Контракт же производит coercion. Трансформация тут ничем не отличается от неё концептуально