search

hadashiA / VContainer

The extra fast, minimum code size, GC-free DI (Dependency Injection) library running on Unity Game Engine.
https://vcontainer.hadashikick.jp
MIT License
1.97k stars 172 forks source link

UniTask binding support from method #527

Closed AlonTalmi closed 1 year ago

AlonTalmi commented 1 year ago

What I did:

I added a generic AsyncFuncInstanceProvider : IInstanceProvider And AsyncFuncRegistrationBuilder : RegistrationBuilder

which bind UniTask instead of just T

Then added 2 new extension methods: RegisterAsync which is used to bind UniTask from a method ResolveAsync which return UniTask instead of TInterface

I also added a tests class to prove it works

and lastly wrapped all in VCONTAINER_UNITASK_INTEGRATION define to avoid compilation error in projects without UniTask

Why?

I'm not sure what the best way to tackle async injections in DI without tackling it somehow from the root which would make things unreasonably complex, but I thought maybe supporting UniTask injection from method (which is currently not supported because UniTask is a struct) and adding a ResolveAsync extension will be better the nothing. but @hadashiA, tell me what you think and if I might miss something.

vercel[bot] commented 1 year ago

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
vcontainer ✅ Ready (Inspect) Visit Preview 💬 Add feedback Jun 5, 2023 0:46am
AlonTalmi commented 1 year ago

Left in draft because I realized the same UniTask instance should not be awaited more then once, thinking how to tackle it.

AlonTalmi commented 1 year ago

I also realized this could have been more simply resolved by allowing value types #521

It will render the InstanceProvider and RegistrationBuilder unneeded, I will wait for it to be merged and then fix my PR

AlonTalmi commented 1 year ago

I realized changing the binding type also means other extension methods will be broken as well :/ I'm closing this until I'll make it properly