А добавьте свой 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 который это тоже делает (с какой-то вероятностью конечно)
Я думаю речь про тот же Jimmer. Jimmer убирает необходимость поддерживать бойлерплейт который ваш плагин радостно помогает генерить. Ну или jOOQ тоже нагенерит сам много и там LLM нужен только чтобы запросы писать. Ну в общем типичное
мы автоматизировали генерацию геттеров и сеттеров!
Указал лицензию
Добавил, результаты хорошие, но в целом не принципиально отличаются от аналогов типо 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 который это тоже делает (с какой-то вероятностью конечно)
Я думаю речь про тот же Jimmer. Jimmer убирает необходимость поддерживать бойлерплейт который ваш плагин радостно помогает генерить. Ну или jOOQ тоже нагенерит сам много и там LLM нужен только чтобы запросы писать. Ну в общем типичное
мы автоматизировали генерацию геттеров и сеттеров!
каких геттеров, у нас Котлин
Есть превью этого джепа? Пример синтаксиса?
Странно тащить ключевое слово ради этого, лучше бы делегаты как в Котлине завезли и можно было бы и lazy делешат сделать (https://youtrack.jetbrains.com/issue/KT-80669/Add-Lazy-implementation-using-JDKs-25-StableValues-API) и много чего еще красивого и DSL-подобного