-
Notifications
You must be signed in to change notification settings - Fork 696
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
Added the ReadmePreviewViewModel & edited NuGetPackageFileService #6029
Added the ReadmePreviewViewModel & edited NuGetPackageFileService #6029
Conversation
@nkolev92 this is going to a feature branch so I don't think there's a worry about merging. |
...uGet.Clients.Tests/NuGet.PackageManagement.UI.Test/ViewModels/ReadmePreviewViewModelTests.cs
Outdated
Show resolved
Hide resolved
...uGet.Clients.Tests/NuGet.PackageManagement.UI.Test/ViewModels/ReadmePreviewViewModelTests.cs
Outdated
Show resolved
Hide resolved
src/NuGet.Clients/NuGet.PackageManagement.UI/ViewModels/ReadmePreviewViewModel.cs
Show resolved
Hide resolved
src/NuGet.Clients/NuGet.PackageManagement.UI/ViewModels/ReadmePreviewViewModel.cs
Show resolved
Hide resolved
newReadmeValue = readme; | ||
} | ||
} | ||
await NuGetUIThreadHelper.JoinableTaskFactory.SwitchToMainThreadAsync(cancellationToken); |
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.
We shouldn't switch to the main thread at the end of this method.
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 don't think updating properties on a background thread will work with WPF.
Jonatan, what happens if you remove the switch to main thread? I'm guessing either no UI update or an exception?
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.
From what I remember I got an exception when I tried to set the view model properties without switching to the main thread. I can remove it and we can see what happens in the next pr, it looks like the unit test passes either 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.
A better way to handle this is to use the Dispatcher to check if we're on the main thread or to marshal to the main thread.
Explicitly switching to the main thread is expensive and error-prone because it forces this background operation onto the main thread where it will remain, even when returning to the caller.
src/NuGet.Clients/NuGet.PackageManagement.UI/ViewModels/ReadmePreviewViewModel.cs
Outdated
Show resolved
Hide resolved
src/NuGet.Clients/NuGet.PackageManagement.UI/ViewModels/ReadmePreviewViewModel.cs
Outdated
Show resolved
Hide resolved
src/NuGet.Clients/NuGet.PackageManagement.UI/ViewModels/ReadmePreviewViewModel.cs
Outdated
Show resolved
Hide resolved
src/NuGet.Clients/NuGet.PackageManagement.UI/ViewModels/ReadmePreviewViewModel.cs
Outdated
Show resolved
Hide resolved
src/NuGet.Clients/NuGet.PackageManagement.UI/ViewModels/ReadmePreviewViewModel.cs
Outdated
Show resolved
Hide resolved
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 smaller PRs for this effort! I would reword the title since it also updates the file service and not just the VM. Approving with suggestions.
src/NuGet.Clients/NuGet.PackageManagement.UI/ViewModels/ReadmePreviewViewModel.cs
Outdated
Show resolved
Hide resolved
newReadmeValue = readme; | ||
} | ||
} | ||
await NuGetUIThreadHelper.JoinableTaskFactory.SwitchToMainThreadAsync(cancellationToken); |
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 don't think updating properties on a background thread will work with WPF.
Jonatan, what happens if you remove the switch to main thread? I'm guessing either no UI update or an exception?
Assumes.NotNull(readmeUri); | ||
|
||
Stream? stream; | ||
if (IsEmbeddedUri(readmeUri)) |
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 recently changed the Icon algorithm to check for a local file first, then a remote file.
Do you think this is a good opportunity to do that for README? That is, check for the md file in GPF first, and only if not found, go to the remote?
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 don't think that will work for the Readme, I want to decide which source it's being loaded from. We don't want to display README in the browse tab if they aren't available from the remote source.
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 quickly re-read the draft spec and didn't see anything obvious indicating why READMEs should only be downloaded and not read from disk. https://github.com/NuGet/Home/pull/13200/files?short_path=6c7eb8e#diff-6c7eb8e1ec6b63a9782e440a235ee32bc0d10f4b7ec8a718f3d24a53660f679c
Could you elaborate on why "it won't work"? You can see the source that populated the GPF via the .nupkg.metadata file.
We don't want to display README in the browse tab if they aren't available from the remote source.
Great thing to explain the spec. Or if it's already there, please give me a pointer to that.
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.
To clarify the requirement. We only want to display README from local storage in the installed tab. That way if there isn't a remote source setup with README exposed, they won't have as much of a inconsistent README experience in the browse tab.
So I feel like this solution won't work because it's leaving it up to the PackageFileService to determine where to pull the README from, but it doesn't have the context if we're viewing the details from the Browse or Installed tabs
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'm not seeing this explicitly in the Spec. I suggest updating that. I'd like to discuss the design, and the spec would be the best place for that.
...nts.Tests/NuGet.PackageManagement.VisualStudio.Test/Services/NuGetPackageFileServiceTests.cs
Outdated
Show resolved
Hide resolved
7338389
to
8581b86
Compare
04b7b97
to
12ae5e7
Compare
…odels/ReadmePreviewViewModelTests.cs Co-authored-by: Jean-Pierre Briedé <jebriede@microsoft.com>
…odels/ReadmePreviewViewModelTests.cs Co-authored-by: Jean-Pierre Briedé <jebriede@microsoft.com>
8581b86
to
75a56db
Compare
… readme
Bug
Part of: NuGet/Home#12583
Description
Adds a new ViewModel for getting the README contents, leveraging the NuGetPackageFileService to get the file from the package.
PR Checklist
Link to an issue or pull request to update docs if this PR changes settings, environment variables, new feature, etc.