Skip to content
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

Merged

Conversation

CyrusNajmabadi
Copy link
Member

@CyrusNajmabadi CyrusNajmabadi commented Mar 1, 2022

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.

@CyrusNajmabadi CyrusNajmabadi changed the base branch from main to release/dev17.3 March 6, 2022 04:53
@CyrusNajmabadi CyrusNajmabadi changed the base branch from release/dev17.3 to main March 6, 2022 04:55
@CyrusNajmabadi CyrusNajmabadi changed the base branch from main to release/dev17.3 March 6, 2022 04:56
_definitions,
cancellationToken).ConfigureAwait(false);
if (location != null)
await location.NavigateToAsync(new NavigationOptions(PreferProvisionalTab: true, ActivateTab: true), cancellationToken).ConfigureAwait(false);
Copy link
Member Author

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.

@CyrusNajmabadi CyrusNajmabadi marked this pull request as ready for review March 6, 2022 05:23
@CyrusNajmabadi CyrusNajmabadi requested review from a team as code owners March 6, 2022 05:23
@CyrusNajmabadi
Copy link
Member Author

@jasonmalinowski this is ready for review.

@CyrusNajmabadi CyrusNajmabadi changed the title Async navigation5 Simplify consumption side of the new async navigation helpers. Mar 6, 2022
@@ -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);
Copy link
Member Author

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.

Copy link
Member

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);
Copy link
Member Author

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 ?

Copy link
Member

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?

NavigationOptions.Default,
allowInvalidSpan: _searchResult.NavigableItem.IsStale,
CancellationToken.None));
_threadingContext.JoinableTaskFactory.Run(async () =>
Copy link
Member

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?

Copy link
Member Author

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);
Copy link
Member

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))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indenting intentional this way?

Copy link
Member Author

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);
Copy link
Member

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?

@CyrusNajmabadi
Copy link
Member Author

Going to merge this in. But address all the feedback in a quick followup as i think it's all relevant.

@CyrusNajmabadi
Copy link
Member Author

Is there a reason the TypeScript stuff isn't at the editor features layer?

:'(

@CyrusNajmabadi CyrusNajmabadi merged commit 4f046ca into dotnet:release/dev17.3 Mar 8, 2022
@CyrusNajmabadi CyrusNajmabadi deleted the asyncNavigation5 branch March 8, 2022 00:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants