В
можно. пару лет как юзаем
Вот с таким опытом уже не поспоришь) Спасибо.
Size: a a a
2020 July 24
DS
@yiiliveext говорит, что prod-конфиги ею нельзя собирать. Уж не знаю, почему.
Где я такое говорил?)
В
Он в проде не юзается)
здесь
Д
DS
здесь
Цитата?
В
Цитата?
Я на нее ответил
DS
В
Не юзается = не используется. Или у тебя есть другой вариант перевода слова use?
В
Пойду-ка я налью чаю :) А то конструктив как-то сошел на нет.
AV
> Зачем коммитить конфиги скомпилированные?
мы так не делаем. но в принципе, думаю, можно.
аналогично как
мы так не делаем. но в принципе, думаю, можно.
аналогично как
composer.lockDS
Не юзается = не используется. Или у тебя есть другой вариант перевода слова use?
не используется и нельзя использовать - это разные вещи) ты даже можешь каждый запрос ребилдить конфиги на проде
В
Да я вообще погорячился. Прошу у всех прощения. Недосып стал нормой, к сожалению.
DS
> Зачем коммитить конфиги скомпилированные?
мы так не делаем. но в принципе, думаю, можно.
аналогично как
мы так не делаем. но в принципе, думаю, можно.
аналогично как
composer.lockПомнится @samdark здесь именно этот вариант освещал
В
https://github.com/yiisoft/yii-event/issues/2 - я тут немного переосмыслил все и подумал, что было бы здорово придумать сервис, который умеет проверять на
isCallable и, вероятно, превращать [service, method] в callable. И не целиком конфиг, а отдельный элемент. В других местах вполне переиспользуемо.В
не используется и нельзя использовать - это разные вещи) ты даже можешь каждый запрос ребилдить конфиги на проде
желательно - где-нибудь посреди обработки запроса)
DS
https://github.com/yiisoft/yii-event/issues/2 - я тут немного переосмыслил все и подумал, что было бы здорово придумать сервис, который умеет проверять на
isCallable и, вероятно, превращать [service, method] в callable. И не целиком конфиг, а отдельный элемент. В других местах вполне переиспользуемо.Ну я помню что есть в роутере еще кроме ивентов, но там все же проверка без контейнера. И тут вопрос, а реально ли нам нужна возможность юзать айди сервиса в листенерах? Я так вижу, что это как минимум интерфейсы, так что тут разные кейсы.
https://github.com/yiisoft/router/blob/master/src/Route.php#L250
https://github.com/yiisoft/router/blob/master/src/Route.php#L250
В
Я твердо уверен, что нужна. Представь себе проект с 200 листенеров. Это вполне нормально для монолитного проекта с 5+ лет развития. Все обработчики будут выглядеть как
(event) => [$container->get('service'), 'method']($event), т.к. это позволяет одновременно и использовать все преимущества di, и делать конфиг быстрым (куда быстрее, чем создание 200 объектов).В
Это ненормально, заставлять юзера писать в конфиге такие обертки, когда нам не составит труда сделать их в рантайме без потери производительности
DS
Это ненормально, заставлять юзера писать в конфиге такие обертки, когда нам не составит труда сделать их в рантайме без потери производительности
Так он и сейчас их не пишет. Мой вопрос был в
vs
[RealClass::class, 'method']
vs
['serviceName', 'method']
В
Так он и сейчас их не пишет. Мой вопрос был в
vs
[RealClass::class, 'method']
vs
['serviceName', 'method']
А чем они кардинально различаются? DI (по крайней мере, наша версия) абсолютно одинаково обработает оба варианта.