@davydovanton class TransferMedicationToPharmasy include Dry::Transaction(container: Application) step :read_user, with: 'operations.read_user' step :generate, with: 'operations.generate_pdf' step :send_to_s3, with: 'operations.send_to_s3' step :send_fax, with: 'operations.send_fax' end чота вот это сильно напоминает старое доброе процедурное программирование

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

ну а так да - это тупо последовательное выполнение кода

а вот как в паскале писал procedure x begin procedure y; procedure z; end вот это я помню

и главный вопрос, что в этом плохого?

а вот как в паскале писал procedure x begin procedure y; procedure z; end вот это я помню

а в руби ты так не пишешь? :)

вот именно так стараюсь не писать

почему? что тебя не устраивает в таком подходе?

ну как минимум запись вида Worker.perform User.save(...) это тоже процедурный код

ну worker и user тут откуда-то взялись

ну это просто тебе пример

а в первом примере там просто step_x, step_y

почти из реального кода

а в первом примере там просто step_x, step_y

да, в который пробрасываются данные из предыдущего шага

ну вот это не видно, потому и не нравится

это единсвтенное, что тебе не нравится? :)

yep

ну, тебе ничто не мешает использовать fmap для этих же целий

или любой другой способ зачейнить вызовы функций/методов

https://github.com/akitaonrails/chainable_methods

Кто юзал?

Есть ли смысл?)

https://github.com/akitaonrails/chainable_methods

выглядит сложно

пока не попробуешь - не поймешь :)

Ну да. Антон, чем dry-* лучше интеракторов? Точнее гема этого, хотел начать пользоваться

да ни чем

Ну ты на днях что то писал

я же написал, что у интеракторов есть конкретная проблема. когда их 2+ - сложно чейнить

и нужно писать кучу проверок

лишних

ну и по сути dry-* и интеракторы - это разные вещи :)

Просто запомнилось, что ты избавился от него вроде dry-conteiner или что то типа того, просто их не знаю толком, мб криво читал)

У меня возникла ситуация, когда есть некоторые модели которые создаются и обновляются в нескольких местах: внешнее api, обмен с соседним продуктом и web интерфейс. Создаются везде по разному, из примерно одинакового списка параметров. Мне это не нравилось и я переписвал все на интеракторы. Пока заметил несколько вещей: 1) Какой-то очень кривой контекст, я его по факту не использую почти. 2) Нудобно чейнить, как уже сказали. 3) Нет валидации параметров контекста удобной

Просто запомнилось, что ты избавился от него вроде dry-conteiner или что то типа того, просто их не знаю толком, мб криво читал)

dry-transaction

в итоге я теперь думаю все переписать на dry-transactions с dry-validation и посмотреть что мне больше понравится

У меня возникла ситуация, когда есть некоторые модели которые создаются и обновляются в нескольких местах: внешнее api, обмен с соседним продуктом и web интерфейс. Создаются везде по разному, из примерно одинакового списка параметров. Мне это не нравилось и я переписвал все на интеракторы. Пока заметил несколько вещей: 1) Какой-то очень кривой контекст, я его по факту не использую почти. 2) Нудобно чейнить, как уже сказали. 3) Нет валидации параметров контекста удобной

интеракторы ничего не должны знать про валидации

ты можешь сделать несколько dry-v схем и пробрасывать их в интерактор

и там уже валидировать

Просто запомнилось, что ты избавился от него вроде dry-conteiner или что то типа того, просто их не знаю толком, мб криво читал)

dry-c это вообще о другом и я пока не писал про это :)

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

валдиации, потом транзакции

а в интеракторах надо либо свое писать, либо еще какие-то сторонние вещи спользовать

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

валдиации, потом транзакции

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

конечно

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

да, потому что это о другом :)

ты же не ожидаешь, что сервис объект будет что-то про валидацию знать?

точнее не правильно выразился

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

about computer science from the best universities and institutions

точно так же ты можешшь в транзакцию засунуть интерактор и его использовать

т.е. это вещи, которые делают свои специфические обязаности

я вообще жду, что если у меня есть некий объект - контекст, то неплохо бы иметь что-то типа context.valid?

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

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

я даже подумывал этот самый context переписать, но потом решил, что получу хромой аналог двух кусков драя )

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

сорри, что врываюсь в ваш умный разговор с тупым вопросом, но что означает "чейнить"?

цепочки последовательные из методов составлять

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

или дойти до конца

собственно что мешает использоать что-то в таком духе: Interactor.new(validation_scheme, payload).call def call if validation_schema.call(payload) else end end

типа rescue где-то по середине?

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

я не предлагаю валидировать контекст внутри интерактора, при помощи интератора,

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

типа rescue где-то по середине?

не совсем

и который я уже скармливаю интератору

ERROR: S client not available

примерно так

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

Interactor.new(validation_scheme, payload).call

вчера как раз думал об этом, что мешает в dry-transaction одним из шагов юзать схему dry-validation?

или вы не об этом?

простой пример: symbolize(get_params(user))

это можно по разному записать в разных языках

или вы не об этом?

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

вчера как раз думал об этом, что мешает в dry-transaction одним из шагов юзать схему dry-validation?

ничего не мешает, да

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

ну транзакция =!= интерактор

тебе придется писать сервис объект, который будет монаду возвращать

специально для транзакции

это можно по разному записать в разных языках

git br --merged | grep -v master | xargs git br -d пример чистки веток )

собственно, сейчас у меня проект онли плэйн рельса (проект маленький), хочу вынести всё в dry-transactions и не вижу где я могу словить проблемы

есть чего опасаться?

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

Вот вы говорите коллбеки стараться не юзать. А условные коллбеки совем зашквар как я понимаю?

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

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

в этом поинт

но не стоит путать транзакцию и интерактор

Вот вы говорите коллбеки стараться не юзать. А условные коллбеки совем зашквар как я понимаю?

это как?

Расскажите, почему колбэки юзать нельзя? Речь же идет о всяких before_create и так далее Это же так удобно

Расскажите, почему колбэки юзать нельзя? Речь же идет о всяких before_create и так далее Это же так удобно

я уже пару раз писал об этом

Расскажите, почему колбэки юзать нельзя? Речь же идет о всяких before_create и так далее Это же так удобно

это иногда опасно )

если коротко, то причин много: 1. тестировать сложно 2. нет контроля, какой из колбэков выполняется 3. сложно мокать 4. колбэки вызываются не явно, дебажить код такой сложно 5. из-за предыдущего пункта ты можешь забыть о колбэке и поесть проблем

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

1. сложно читать код, ты не понимаешь от куда переменная взялась, если ты не знаешь о колбэке 2. обычно их 2+ и тут начинается веселье. как ты будешь уверен, какой выполнится первым? 3. чаще всего в колбэках мутируют данные или же письма шлют, это в свою очередь: 3.1 пиздец сложно тестировать 3.2 увеличивает связанность между частями системы, что приводит к куче проблем 3.3 почему не взять адекватное прямолинейное решение проблемы, отдельно от модели например? но почему-то всем срать и все пихается в модель/контроллер и прочее. 4. дебаг системы, в которой дохуя колбэков - отличное время препроваждения, я настоятельно рекомендую попробовать

вот

на самом деле ещё можно сказать, что валидации на моделях писать плохо и опасно

Ну иногда не избежать же. Вопрос у меня только в том вызывать коллбек всегда и проверять условие уже в методе который этим коллбеком вызывается, или вызывать коллбек в зависимости от этого условия.

но это вообще разрыв шаблона

на самом деле ещё можно сказать, что валидации на моделях писать плохо и опасно

ужас какой