Hilt Decompose Plugin

[Muhammadali143904]

Hi, i am doing my compose-android native project, and for DI i wanted to use Hilt, but it was very difficult, and in my opinion it is impossible, so i started to create a plugin for arkivanov/Decompose, it will work as ViewModel, and i am started, i learned basic of annotation.process and more, and start to copy with original project(hilt library), at there it has a ViewModel.Provider and Factory, so i hope do to this step by step for Decompose, what is your mean? Could i do this? Have you any idea or method to do this?

[arkivanov]

Hello. Could you explain in more detail what specific problems you are trying to solve by DI frameworks? Maybe you could provide some examples of issues?

But regardless, thanks for sharing the info! Feel free to create whatever is useful for you, and ask any questions about Decompose here. Useful tools could be linked in the documentation website.

[Muhammadali143904]

For example in Hilt we all do by @Inject constructor and some modules and at the end in fragment/activity we call by viewmodels() method. And all creates automative. But in Components(Decompose library instead of ViewModel) we can't call like this, so i want write library where we can call for example componentContext(context, input, output), and other classes like use case it will create own.

It can solved by using Koin, but i want to try to write a library.

So can i start to code a ComponentContext.Provider and Factory?

[arkivanov]

Thanks for the reply. You could publish this as a standalone library. I doubt that this should be part of Decompose project, because there are many DI frameworks available. But if the community will find your library useful, it could be linked in the documentation website.

[Muhammadali143904]

Ok, thank you

[malliaridis]

I analyzed and worked in the last few months with Decompose's project structure (with Compose) as well as with DI libraries. My experience with DI libraries was that testing was made significantly harder, but in Decompose's structure everything can be tested individually or in combinations with ease. In Decompose there is no magic and once you understand the structure and role of every class / interface (there is a steep learning curve), you will very likely enjoy using it without DIs.

I was also thinking about creating a library for simplifying the generation of those "class collections" as module generation or something like that, but aside from various IDE plugins I could think of and of which I am not capable implementing on my own, there was no way I could simplify further the structure without overcomplicating and hiding things (casting unwanted magic).

Therefore, DI libraries like Hilt, Dagger or Koin with Decompose would not add to the code quality in my opinion. And one of the reasons for Decompose is to not have to use DIs at all.

Why Decompose?

• [...]
• Proper dependency injection (DI) and inversion of control (IoC) via constructor

EDIT: But I like the willingness of developing libraries for Decompose. I would definitely try them. 🛩️

[Muhammadali143904]

Ok, thank you, i get it

[Muhammadali143904]

Hi arkivanov, your library(Decompose) doesn't support SavedStateHandler, isn't it?

[arkivanov]

It doesn't, there is StateKeeper for this.

[Muhammadali143904]

Thank you