-
Notifications
You must be signed in to change notification settings - Fork 36
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adds lazy loading support to binding methods #44
Conversation
Inspired from work by @Place1. Adds new Lazy methods that can optionally be called to lazy bind a resolver to an abstract. The resolver will not be called until the first time a resolve call is made. A strong effort was made to not cause regressions or otherwise change the behavior of the existing API. Minor changes were made to how validation occurs and in some situations a more verbose error can be presented earlier in a binding process.
Could you please explain why you need this feature? BTW, the pipeline failed because of decreased test coverage. |
@miladrahimi There's a tradeoff in doing this for sure and I see value in both lazy and non-lazy binding. It's why I felt it was critical to preserve both and not cause regressions in the non-lazy bindings. In our use case we have multiple startup profiles and they have wildly different dependencies. It would be ideal if we could bind most of our dependencies in one place lazily and then only resolve them if a startup profile needs them. Currently we either need conditionals and/or to split bind calls across files to achieve this. For our use case we can tolerate runtime faults, especially if it simplifies development/maintenance of our project. |
I've updated my branch and believe there is 100% line coverage now. |
@miladrahimi do you still have concerns about adding lazy functionality? Is this a direction you'd be comfortable with taking the project? |
I've a question. What is the difference between transient and lazy transient? They both seem the same to me. |
@miladrahimi I wasn't sure if I should implement lazy transient or not. It feels like low value add and could be removed in my opinion. They're almost identical except for one change. Transient will call the resolver function when called, but lazy transient will not. Lazy transient defers calling the resolver until the first resolve. |
Thank you @wirecat. It's merged and release: |
Inspired from work by @Place1. Adds new Lazy methods that can optionally
be called to lazy bind a resolver to an abstract. The resolver will not be
called until the first time a resolve call is made.
A strong effort was made to not cause regressions or otherwise change the
behavior of the existing API. Minor changes were made to how validation
occurs and in some situations a more verbose error can be presented earlier
in a binding process.