-
Notifications
You must be signed in to change notification settings - Fork 206
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
[WIP] Sub graphs and Decorate #240
Conversation
Codecov Report
@@ Coverage Diff @@
## master #240 +/- ##
=========================================
Coverage ? 98.51%
=========================================
Files ? 10
Lines ? 1210
Branches ? 0
=========================================
Hits ? 1192
Misses ? 13
Partials ? 5
Continue to review full report at Codecov.
|
I've added supported for sub graphs. Please review and provide feedback. Once this is approved I'll proceed to implementing Also how should I implement Stringer on a container. Should it also print all the nodes of the parents? or all the nodes of children? or both? I would go for both since it would be consistent with the behaviour. But I'm not sure. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the change @srikrsna! The general direction this is taking is
looking great. I've left a few suggestions.
Co-Authored-By: srikrsna <psk.psk6@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for making the changes @srikrsna. I think we still want to de-duplicate the tests as suggested in https://github.com/uber-go/dig/pull/240/files#r279888001
@abhinav I've updated the tests. One more thing I needed direction on is how should the I would go for both since it would be consistent with the behaviour of |
Hey, sorry for the delay. That's a fair point. It might be a bit surprising if So I think it's best if String only print its own nodes and recurses into |
Rather than a function which returns two other functions, this changes the container hierachy tests to consume a `containerView` which has `Provide` and `Invoke` methods as fields on it. This has the effect of leaving the bulk of the test logic unchanged, only changing `New()` calls to `newContainer()`.
I made a minor simplification to the tests. Please pull that before you make |
I'll update the |
Just the address of the parent instead of the contents might be less noisy and would help differentiate between
Yes, definitely! Although I would make that a separate PR on top of this one so that this can be landed when ready and that can be iterated on independently. |
@abhinav Apologies for the delay. I believe this is complete and ready to be merged. |
Hey @srikrsna! Thanks! We haven't forgotten about this but we're a bit swamped |
Sri Krishna Paritala seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account. You have signed the CLA already but the status is still pending? Let us recheck it. |
I know this is pretty darn old at this point, but FWIW, is a type of feature I personally look for in an IoC container, and seemed pretty close to good to go last year. |
This is what I awesome! Have been waiting for this feature.. |
Done |
@abhinav any way you can push on this? |
Hey folks, apologies for the radio silence here. I know it's been a while but we're trying to pick up support for decorate/replace again, That said, the reason this PR was not merged was this: Unfortunately, we didn't write down those conversations, but from what I can recall: So we weren't ready to commit to subgraphs at the time, All's not lost, though. As I said, we're trying to pick up the project again. |
uber-go/fx#653
Also address #230
Added support for creating child containers.