осталось перевести его на аннотации или придумать че поудобнее тегов)

хз я все выходные разбирался с разными вариантами как формы херачить на реакте в стиле ангуляра...

последние 4 часа перехерачиваю формы на formik... не до графкюэлей мне...

хз я все выходные разбирался с разными вариантами как формы херачить на реакте в стиле ангуляра...

хз, че там в ангуларе сейчас

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

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

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

альтернатива... хм...

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

в этом случае у тебя на все аргументы и на все структуры были бы типы в php

но.... ты не можешь graphl типы в php выразить полностью)

а так придется где-то соответствие ресолверам описывать. аннотации в этом плане лучше всего подходят

ну у меня из идей было только по названиям методов + первому тайпхинту (который source) но это сугубо для моего кейса подходит потому скорее всего задавлю свое буэ на аннотации и приделаю их

главное что бы компайл пасс это все собирал и валидировал на предмет соответствия схемы (что все определено и что ты не забыл ничего()

хм, тоже идея

ну у меня из идей было только по названиям методов + первому тайпхинту (который source) но это сугубо для моего кейса подходит потому скорее всего задавлю свое буэ на аннотации и приделаю их

да я тож такой вариант думал

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

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

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

по идее скаляры юзаются только для трансформации значений (и валидации оных)

их просто регаешь как типы и все

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

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

их просто регаешь как типы и все

ну вот я именно для трансформации хочу, всякие Money и Date по дефолту оно в json перегоняется, кажись ну и я не доковырял до конца то, используется ли для них встроенный в webonyx TypeRegistry

ну вот я именно для трансформации хочу, всякие Money и Date по дефолту оно в json перегоняется, кажись ну и я не доковырял до конца то, используется ли для них встроенный в webonyx TypeRegistry

вроде юзаются, сча наверняка не скажу но я свои типы регал

у меня есть мэпы всякие и т.д. которые graphql пока не умеет

клуб поклонников комманд баса подскажите, законно ли вообще делать декораторы или мидлваре для команд? например: $command = new OrderCommand(); $middleware = new Middleware(new ClientDecorator(), new ProductsInvoiceDecorator()); $middleware->apply($command); прост у меня есть сомнения, насколько это явно и на сколько можно выстрелить ногу с сайд эффектами

мммм, а можешь объяснить, чего ты хочешь добиться?

типа мидлвары конкретно под команду?

Делали, делаем и будем делать

типа мидлвары конкретно под команду?

да

прост у меня есть несколько экшенов

ну у меня мидлвары тоьлко на шине пока что) под команды не делаю

Так вроде про шину и вопрос... не?

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

ну мидлвара на команду это больше похоже на кучку декораторов (по твоему примеру) но для начала лучше дослушать тебя)

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

ну и там дальше похожая цепочка кейсов

хернёй попахивает

хернёй попахивает

вот и того и спрашиваю

ну т.е. мы саги заменяем декораторами)

угу, попахивает сама идея вроде бы и ничего, но фактически ты выносишь в эти самые декораторы/мидлвары бизнес-логику а это не ня

я у себя почти сознательно убрал возможность использовать мидлвары. Просто выпилил к херам. и чёт как-то не жалею от слова совсем. 1 чёрт так и не придумал чё в них пихать)

я у себя почти сознательно убрал возможность использовать мидлвары. Просто выпилил к херам. и чёт как-то не жалею от слова совсем. 1 чёрт так и не придумал чё в них пихать)

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

флоу распиши

у тебя синхронщина?

у тебя синхронщина?

изыйди, не мешай вербовать агентов

изыйди, не мешай вербовать агентов

я хочу спасти его от потерянного на синхронные саги времени

я хочу спасти его от потерянного на синхронные саги времени

аа) ну это да, стрёмная затея)

я кстати осилил статейку которую ты скидывал. Ребята молодцы

у тебя синхронщина?

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

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

? пока что я один тут наркоман)

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

? пока что я один тут наркоман)

https://cdn.igromania.ru/mnt/news/0/0/1/e/1/a/71013/6b40a266b579fa46_848x477.jpg

я кстати осилил статейку которую ты скидывал. Ребята молодцы

И мне, и мне скиньте

И мне, и мне скиньте

https://habr.com/company/oleg-bunin/blog/418235/

но ты вряд ли чёт новое там найдёшь

просто полистать должно быть интересно)

Читал, имхо ребята ушли куда-то не туда

Или расписано не корректно

Что именно смутило?

Что у них отеделно у правление и логика саг

Ну, в целом оправдано. У тебя так-то оно тоже разделено, пускай и менее явно

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

А что нужно допилить?

поддержку 3.4 symfony ;)

поддержку 3.4 symfony ;)

Нет, спасибо :)

флоу распиши

ох...сложна) в общем, покупка подписок 1) кастомер может из разных мест UI может - купить, продлить, проапгрейдить подписку и тп, в результате этого формируется invoice. Много правил, в одном случае нужно взять существующего кастомера, в одном его подписку, в другом нужно определить страну и тд, но результатом этого всегда будет invoice. 2) Дальше этот invoice передается на процессинг через разные payment gateway, у каждого под капотом свой флоу (переходы, 3d штуки и тп), гейтвей также выбирается на основе разных правил - страна, аб тест и тп. 3) Есть флоу, что в случае ошибок, нужно откатиться до выбора payment gateway и переключится на другой 4) И результатом успешно оплаченного invoice-a есть подписка

звучит знакомо)

3 саги, на вскидку

ну и вишенка, что это уже все сделано

ERROR: S client not available

ну если сделано, в чём вопрос)

ну если сделано, в чём вопрос)

yii2

ты понял?)

ифами

yii2

эм, я знал что не нужно было с тобой разговаривать)

ифами

хуифами

хуифами

эффектно

"хм.. добавлю ка еще один иф..."

эм, я знал что не нужно было с тобой разговаривать)

ну теперь вопрос выкидывать yii2

как платёжки сделаны? с поддержкой нескольких методов оплаты в рамках 1 инвойса? или 1 инвойс = 1 платёж?

и планомерно разгребать говно

ну типа можно ли твои товары оплатить равными долями в киви и вебмани

как платёжки сделаны? с поддержкой нескольких методов оплаты в рамках 1 инвойса? или 1 инвойс = 1 платёж?

1 инвойс = 1 успешный платеж + n-e количетсво retry

инвойс -> платёж -> N транзакций?

инвойс -> платёж -> N транзакций?

да

тогда сага по разбору с кастомерами (возможно даже 2), сага по инвойсу и сага по платежу (одна на всех)

ну типа можно ли твои товары оплатить равными долями в киви и вебмани

нет, только один

ну и общая по всей этой хератени

назовём её чекаутом)

назовём её чекаутом)

ну допустим

а когда допишешь, пойдёшь за закладками :)

она покрывает все кейсы подписок? - покупка, апгрейд и тп

или под каждый кейс своя сага?

ну у подписок свой флоу, свои нюансы)

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

там ещё отдельная развлекуха будет, если у тебя есть рекуренты)

ну типа подписку неплохо было бы и обновлять)

там ещё отдельная развлекуха будет, если у тебя есть рекуренты)

всмысле?

все, я понял)

я сперва подумал, не в контексте платежей

всмысле?

В смысле как рекуренты реализованы?)

Имплементация саг на основе какой-то либы делаете?