будет в теле генератора - это захлямляет код. function-tree более явный, хотя у меня не совсем он. Я встречал определение functions waterflow, поправь, если есть более точные определения. Смысл в том - что бы изолировать любой логический узел или обработчик в отдельную сущность - это позволяет читать код легче, а писать продуманней (т.к., в идеале, нужно придумывать название для каждого узла \ обработчика - это проясняет)
2) У меня всего 2 апи, фактически: goal и middleware - это очень просто и понятно, при этом меня поражает функциональность и, опять же, простота мидлвар. Тот же DI, что я приводил выше, делать - элементарно. А как это делать с генераторами?
2) обычным аргументом ЕСЛИ нужно - фишка инициальных (саги) интерпретаторов в том, что там не нужен DI, вся мокабельная логика в интерпретаторе - в случае с терминальных интерпретаторов (санки) мы все получаем из аргументов
1) я согласен про functions waterflow, но в бизнес-логике это очевидное усложнение
Обсуждают сегодня