-
Notifications
You must be signed in to change notification settings - Fork 4k
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
Simplify consumption side of the new async navigation helpers. #59838
Simplify consumption side of the new async navigation helpers. #59838
Conversation
f67d2e5
to
87370b5
Compare
87370b5
to
f67d2e5
Compare
_definitions, | ||
cancellationToken).ConfigureAwait(false); | ||
if (location != null) | ||
await location.NavigateToAsync(new NavigationOptions(PreferProvisionalTab: true, ActivateTab: true), cancellationToken).ConfigureAwait(false); |
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.
note: i don't pass these options down as all callers use this nav value for the TryPresentLocationsAsync calls. so it's just specified inside that instead.
@jasonmalinowski this is ready for review. |
@@ -301,7 +300,7 @@ internal class CodeActionEditHandlerService : ForegroundThreadAffinitizedObject, | |||
{ | |||
var navigationService = workspace.Services.GetRequiredService<IDocumentNavigationService>(); | |||
await navigationService.TryNavigateToPositionAsync( | |||
workspace, navigationOperation.DocumentId, navigationOperation.Position, cancellationToken).ConfigureAwait(false); | |||
this.ThreadingContext, workspace, navigationOperation.DocumentId, navigationOperation.Position, cancellationToken).ConfigureAwait(false); |
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.
teh general concept here is that all the helpers which actually do perform a navigation take a ThreadingCOntext. That way they could, if necessary, switch to a UI thread. This also means taht the helpers are only available to consumer who ahve a threading context and thus live in an 'editor' world where the concepts of navigating actually make sense.
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, interesting way to split that up. I think I like it!
var location = await obj.GetLocationForPositionAsync( | ||
workspace, documentId, position, virtualSpace, cancellationToken).ConfigureAwait(false); | ||
return location != null && | ||
await location.NavigateToAsync(NavigationOptions.Default, cancellationToken).ConfigureAwait(false); |
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.
this is a genuine weird case. the TS code lives at the feature layer, but has hte concept of navigation. if we changes NavigateTo to be sync and require the UI thread, we'd have to introduce some sort of hack (likely through the IWorkspaceThreadingService) to somehow allow it ot move over. I don't have a good idea of what we can do here that isn't hack. Thoughts @jasonmalinowski ?
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.
Is there a reason the TypeScript stuff isn't at the editor features layer?
src/EditorFeatures/Core/Navigation/IDocumentNavigationServiceExtensions.cs
Show resolved
Hide resolved
NavigationOptions.Default, | ||
allowInvalidSpan: _searchResult.NavigableItem.IsStale, | ||
CancellationToken.None)); | ||
_threadingContext.JoinableTaskFactory.Run(async () => |
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.
Hmm, why the await here?
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.
godo catch. no reason will fix.
@@ -301,7 +300,7 @@ internal class CodeActionEditHandlerService : ForegroundThreadAffinitizedObject, | |||
{ | |||
var navigationService = workspace.Services.GetRequiredService<IDocumentNavigationService>(); | |||
await navigationService.TryNavigateToPositionAsync( | |||
workspace, navigationOperation.DocumentId, navigationOperation.Position, cancellationToken).ConfigureAwait(false); | |||
this.ThreadingContext, workspace, navigationOperation.DocumentId, navigationOperation.Position, cancellationToken).ConfigureAwait(false); |
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, interesting way to split that up. I think I like it!
if (location != null && | ||
await location.NavigateToAsync(NavigationOptions.Default, cancellationToken).ConfigureAwait(false)) | ||
if (await navigationService.TryNavigateToSpanAsync( | ||
this.ThreadingContext, editorWorkspace, documentId, resolvedRenameToken.Span, cancellationToken).ConfigureAwait(false)) |
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.
Indenting intentional this way?
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.
yup. i dont' like my arguments aligning with the parent, they are better indented to visually tell tehy're children, not siblings :)
var location = await obj.GetLocationForPositionAsync( | ||
workspace, documentId, position, virtualSpace, cancellationToken).ConfigureAwait(false); | ||
return location != null && | ||
await location.NavigateToAsync(NavigationOptions.Default, cancellationToken).ConfigureAwait(false); |
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.
Is there a reason the TypeScript stuff isn't at the editor features layer?
src/VisualStudio/Core/Impl/SolutionExplorer/SourceGeneratedFileItems/SourceGeneratedFileItem.cs
Show resolved
Hide resolved
Going to merge this in. But address all the feedback in a quick followup as i think it's all relevant. |
:'( |
Followup to #59802.
Continues work on async navigation, removing old helpers.
THe core idea here is that we'd like the INavigableLocation to potentially be synchronous to navigate, indicating that all expensive BG work has already been done, and the only remaining work is a quite opening of the UI to take the user to the actual location. As such, all consumers of it must get the location asynchronously, then switch to the UI as the very last step, then do the actual navigation.
Note; tehre is only one final portion of the code preventing the actual switch rom async to sync here. That's the reentrancy in MAS where we use async to first generate the MAS file, then we try to open it, reentering to call back into navigation to find the doc post open. Once we clean that up, the final swithc can happen.