https://kotlinlang.org logo
Join Slack
Powered by
Just released 0.5.0! <https://github.com/evant/kot...
# kotlin-inject
e
p
Nice 🎉 The native publication seems broken: https://github.com/evant/kotlin-inject/issues/222
d
Tried upgrading, and encountered those new errors with parent/child components, even though it was working well with 0.4.0... is it for sure a mistake in all cases to ignore those errors?
p
Yeah probably they shouldn’t be ignored. Or the warnings are wrong, in that case a reproducer would be top 👍
e
Gonna have to make some big changes due to parents not being able to use child injections, but I'd much rather have the safety of not leaking so 😁
p
Gonna have to make some big changes due to parents not being able to use child injections
Can you give an example? That should still work
e
From the release notes
In other words a parent component can no longer depend on a dependency provided by a child component. Not only does this lead to confusing graphs, but it can lead to memory leaks if the parent component lives longer than the child and ends holding on to that child dependency.
p
But why would you do that in the first place?
e
I was porting concepts from runtime frameworks for Kodein, and it was the only way to get it to work.
It was much easier than restructuring everything in my app/head
p
Still can’t think of a practical example ^^
e
When I update my code I'll try to remember to post the scenario here
e
Oof sorry about that native publication getting messed up. I fixed one issue with it before release but missed that.
p
@evant Are you already onto this?
I couldn’t reproduce it locally so it might be related to that nexus stuff? Is that nexus plugin even necessary?
e
Yeah will take a look either today or tomorrow. I think it's only the mac build? Which is weird.
p
On my mac, publishToMavenLocal creates correct publications
e
And yeah with kotlin multiplatform the nexus plugin is basically required cause otherwise I've run into issues where it will randomly split artifacts across publications
p
Sqldelight seems to do it without the nexus one
e
@Paul Woitaschek I think I have a fix but don't have a kmm project handy at the moment, mind verifying that 0.5.1-SNAPSHOT works now when you get a chance?
p
Yep, building!
Copy code
public override val welcomeScreenViewModelFactory: WelcomeScreenViewModel.Factory
    get() = WelcomeScreenViewModel.Factory(
      creator = { arg0_________________________________ ->
        WelcomeScreenViewModel(
          dispatcherProvider = dispatcherProvider,
          localizer = localizer,
          remoteConfig = remoteConfig,
          tracker = WelcomeTracker(
            tracker = _tracker,
            screenTracker = _screenTracker
          ),
          navigator = arg0_________________________________
        )
      }
    )
😄
e
_______ Oh is it making the names unique across the whole component?
p
Yes. Is that a problem?
e
I mean it'll work but it probably could be improved to take scope into account to make them shorter
p
I’d prefer to leave it like this because it doesn’t cause issues and is simple to read and test. Else we’d need a way more complex test setup and it would make the processor way more complex as well
e
Long identifiers lead to code bloat in the executable, I mean you could use proguard to fix but not everyone is. I really don't think it would be that complicated but yeah not the highest priority
p
Thanks 🎉 Im on vacation now but the renovate PR is all green
8 Views
Open in Slack
PreviousNext
Powered by