В скале куда мощнее и интереснее. Тут это просто параметр который берется из скоупа вызова (класс-левел, топ-левел в резолве не участвует, только то что в функции самой) и имплиситно передается. В общем до скаловских имплиситов тут очень далеко
Это вообще не замена DI, разве что если передавать что-то типо ApplicationContext и оттуда сервисы доставать в каждом методе. Почему? Да потому что context "окрашивает" функцию, теперь чтобы вызвать outputMessage нужно коллеру знать про UserService и положить его в контекст. Т.е это не DI
Что же это?
Классная штука для DSL - тут прямо очень много возможностей открывается
Для меня основной юзкейс это компайл-тайм-тред-сейф замена ThreadLocal
Еще вероятно кейсы которые мне не доводилось использовать
Замена ThreadLocal самая приятная, у меня контроллеры завернуты в context(_: UserContext) и через HandlerMethodArgumentResolverUserContext построенный из запроса передается в контроллер, дальше все функции по стеку определяют что им нужен context(_: UserContext) и получаем секьюрити без багов, даже с учетом что мы используем и корутины, и реактор и акторы и у нас библиотека которая используется и со спрингом и без спринга. В общем супер производительный, пуленепробиваемый способ делать секьюрити и транзакции в нашем случае.
Я сейчас развиваю контексты в сторону использования их со всякими @Cached/@Retry, чтобы везде отказаться от неявной передачи/хранения стейта, на явные контексты.
Так что фича очень удобная для написания быстрого и безопасного кода. Особенно актуально в эру ИИ
А добавьте свой DI сюда https://github.com/Heapy/di-comparison Будет куда более информативнее чем звездочки расставленные автором в вакууме. Например в бенчмарке выше получилось что спринг бут это 9мб а у вас 30, хз как вы считаете
Проблема не в том что в них тяжело разобраться, проблема в том что при такой глубине стека многие оптимизации JVM перестают работать и условно можно получить сервис который обработает в два раза меньше запросов да еще и с большой latency
Ну это вы еще spring boot не видили, там любой эксепшен в hello-world это 100 уровней вложенности. Такая цена вот гибкости, не всем походит, мы перестали например много где srping-boot использовать из-за этого
Какова вероятность, что, обнаружив какой-то баг, я смогу попробовать его исправить и отправить PR, а не ждать и надеяться, что мейнтейнеры когда-нибудь сделают это сами? Около нулевая. Именно поэтому в репозитории React'а висят баги от 2014 года — не потому, что их кто-то другой не может исправить, а потому что это фиктивный open-source. Это системная непрозрачность, и она прослеживается во всём, что делает React.
Коротко - чтоб Вы спросили :) А если серьёзно, какая разница какой у них код-стайл? Да потребовалась целая директория, для такого маленького пакета, ну и что? А ничего. Работает этот код в отдельной директории или нет - всё равно, главное чтобы он решал свою задачу. Да и, есть вероятность, что кэш импортов здесь как-то участвует (мб что-то оптимизирует), но не уверен.
Есть ощущение что это как-то связано с react-native и cерверными компонентами
Пример ужасный конечно (это не DI конечно, он просто загрязняет коллера своими зависимостями), но по сути своей context parameter отличная замена thread local / scoped values для того чтобы писать 100% правильно работающий код. В случае с использованием любой многопоточности context parameters единственный способ который на этапе компиляции отловит то что контекст забыли передать. Цена конечно у этого есть в плане того, что контексты попадают в API методов. Но в целом и писать и тестировать это приятно
Я понимаю что Jimmer выглядит не очень понятным, но смотрите что генерирует тот же Jimmer:
entity classes by database tables
dtos
repositories
open api 3.0 crud rest -> из этого можно кодом нагенерить http запросы под любой движок: idea http client, postman, curl, etc
Json schema
В общем суть вы должны понять, это вполне себе конкретная задача, как получить геттеры/сеттеры или распарсить язык, а вы зачем-то хвастаетесь что написали промпт для LLM который это тоже делает (с какой-то вероятностью конечно)
В скале куда мощнее и интереснее. Тут это просто параметр который берется из скоупа вызова (класс-левел, топ-левел в резолве не участвует, только то что в функции самой) и имплиситно передается. В общем до скаловских имплиситов тут очень далеко
Это вообще не замена DI, разве что если передавать что-то типо
ApplicationContextи оттуда сервисы доставать в каждом методе. Почему? Да потому что context "окрашивает" функцию, теперь чтобы вызватьoutputMessageнужно коллеру знать проUserServiceи положить его в контекст. Т.е это не DIЧто же это?
Классная штука для DSL - тут прямо очень много возможностей открывается
Для меня основной юзкейс это компайл-тайм-тред-сейф замена ThreadLocal
Еще вероятно кейсы которые мне не доводилось использовать
Замена
ThreadLocalсамая приятная, у меня контроллеры завернуты вcontext(_: UserContext)и черезHandlerMethodArgumentResolverUserContextпостроенный из запроса передается в контроллер, дальше все функции по стеку определяют что им нуженcontext(_: UserContext)и получаем секьюрити без багов, даже с учетом что мы используем и корутины, и реактор и акторы и у нас библиотека которая используется и со спрингом и без спринга. В общем супер производительный, пуленепробиваемый способ делать секьюрити и транзакции в нашем случае.Я сейчас развиваю контексты в сторону использования их со всякими @Cached/@Retry, чтобы везде отказаться от неявной передачи/хранения стейта, на явные контексты.
Так что фича очень удобная для написания быстрого и безопасного кода. Особенно актуально в эру ИИ
Указал лицензию
Добавил, результаты хорошие, но в целом не принципиально отличаются от аналогов типо koin, kodein
А добавьте свой DI сюда https://github.com/Heapy/di-comparison
Будет куда более информативнее чем звездочки расставленные автором в вакууме.
Например в бенчмарке выше получилось что спринг бут это 9мб а у вас 30, хз как вы считаете
https://manageripgeorgia.atlassian.net/wiki/spaces/FAQ/pages/1199276038/2025+2026
Проблема не в том что в них тяжело разобраться, проблема в том что при такой глубине стека многие оптимизации JVM перестают работать и условно можно получить сервис который обработает в два раза меньше запросов да еще и с большой latency
Ну это вы еще spring boot не видили, там любой эксепшен в hello-world это 100 уровней вложенности. Такая цена вот гибкости, не всем походит, мы перестали например много где srping-boot использовать из-за этого
Ну да, я не вчитывался. Если все-таки посмотреть на сорцы, то аж на третьей страницы после всяких devtools и tests есть такой результат, который как раз похож на реализацию https://github.com/facebook/react/blob/eb2f784e752ba690f032db4c3d87daac77a5a2aa/packages/react-reconciler/src/ReactFiberHooks.js#L3941
Я так понимаю кина не будет?
А в линукс ядре висят баги с 2012 и то потому что судя по всему поиск дальше не идет https://bugzilla.kernel.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&limit=0&order=changeddate%2Cpriority%2Cbug_severity&query_format=advanced
Третья ссылка в результах код клиента https://github.com/facebook/react/blob/eb2f784e752ba690f032db4c3d87daac77a5a2aa/packages/use-sync-external-store/src/useSyncExternalStoreShimClient.js#L25
Четвертая код сервера https://github.com/facebook/react/blob/eb2f784e752ba690f032db4c3d87daac77a5a2aa/packages/use-sync-external-store/src/useSyncExternalStoreShimServer.js#L10
Приведите список аналогов RSC
Автор не знает что существует поиск, я нашел сорцы useSyncExternalStore за минуту прямо не выходя из браузера: https://github.com/search?q=repo%3Afacebook%2Freact useSyncExternalStore&type=code
Еще автор не знает про то, что реакт это не только замена jquery, но очень хитрый рантайм, у которого нет аналогов https://overreacted.io/progressive-json/
Есть ощущение что это как-то связано с react-native и cерверными компонентами
DI не решает проблемы транзакций например либо создает проблемы производительности/оверхед в случае не singleton бинов
Согласен, не видел пока хорошего примера DI на контекстах
Только без scala и не implicit 😉
Scoped Values это скорее coroutineContext
Ближайший аналог просто передавать вручную контекст как параметр везде (что заграмождает код)
Пример ужасный конечно (это не DI конечно, он просто загрязняет коллера своими зависимостями), но по сути своей context parameter отличная замена thread local / scoped values для того чтобы писать 100% правильно работающий код. В случае с использованием любой многопоточности context parameters единственный способ который на этапе компиляции отловит то что контекст забыли передать. Цена конечно у этого есть в плане того, что контексты попадают в API методов. Но в целом и писать и тестировать это приятно
https://github.com/Kotlin/KEEP/issues/367#issuecomment-3299718687
В целом она уже есть, есть только один неприятный баг который должны пофиксить к версии 7 https://github.com/spring-projects/spring-framework/issues/35134
Я понимаю что Jimmer выглядит не очень понятным, но смотрите что генерирует тот же Jimmer:
entity classes by database tables
dtos
repositories
open api 3.0 crud rest -> из этого можно кодом нагенерить http запросы под любой движок: idea http client, postman, curl, etc
Json schema
В общем суть вы должны понять, это вполне себе конкретная задача, как получить геттеры/сеттеры или распарсить язык, а вы зачем-то хвастаетесь что написали промпт для LLM который это тоже делает (с какой-то вероятностью конечно)