-
Notifications
You must be signed in to change notification settings - Fork 1.2k
KTOR-8308 Extension for using dependency injection within a route #5042
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
Open
solonovamax
wants to merge
2
commits into
ktorio:main
Choose a base branch
from
solonovamax:feature/route-level-dependency-injection
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Uh oh!
There was an error while loading. Please reload this page.
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.
🛠️ Refactor suggestion
Delegate to Application.dependencies to auto-install DI and avoid NoSuchElementException
Accessing
application.attributes[DependencyRegistryKey]will throw if the DI plugin isn’t installed. The Application-level property already handles auto-install (install(DI)), so delegate to it for consistent and safer behavior.Additionally, this is a new public API; it should have KDoc like the rest of this file.
Apply this diff to fix the getter:
Add KDoc above the property (outside the changed lines):
🤖 Prompt for AI Agents
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.
The rabbit is correct in this matter ☝️
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.
@bjhham Thank you for confirming! I'm glad the suggestion to delegate to
Application.dependenciesand add proper KDoc makes sense. This will indeed make the Route-level dependency access more robust and consistent with the existing Application-level behavior.( ˶ᵔ ᵕ ᵔ˶ )
Uh oh!
There was an error while loading. Please reload this page.
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.
having it throw is intentional, as dependencies should be configured at an application-level rather than at a route level (as if you configured it at a route level, you would expect it to be scoped to the route, however it is not, as doing so is rather out of scope for the PR)
also, because
Application.dependenciesdoes not have any documentation, I omitted documentation on this.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.
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.
I am thinking now that we may want to avoid introducing this extension. It is better to always resolve dependencies during application startup, because it allows for validation during startup and avoids unnecessary lookups. I'm concerned this would encourage people to resolve dependencies during request processing, which is not ideal.
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.
I think it might be okay to introduce
Route.dependencies, but notRoutingContext.dependencies. After fixing DSL scope annotations (#5058) usage of this extension inRoutingContextscope will throw a compilation error. So all dependencies will be resolved at the moment of routing initialization. @bjhham wdyt?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.
they are resolved at application startup. can routes even be added at any point after that? and you could even already do it at runtime by just doing like
however, I do actually think it would be actually useful to be able to resolve it at runtime
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.
Ah this is true, I mixed up
RouteandRoutingContext. The naming is a bit confusing in my defense. @solonovamax that snippet is valid currently in 3.0, but we're planning on fixing the DSL scope annotations so application references will need to be explicit. There can be uses for accessing dependencies after startup, but in general it's better practice to validate everything as early as possible. The routing DSL generally runs at the same time as the modules so we should be good to go there 👍