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

Added the ReadmePreviewViewModel & edited NuGetPackageFileService #6029

Merged

Conversation

jgonz120
Copy link
Contributor

… 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

  • Meaningful title, helpful description and a linked NuGet/Home issue
  • Added tests
  • Link to an issue or pull request to update docs if this PR changes settings, environment variables, new feature, etc.

@jgonz120 jgonz120 requested a review from a team as a code owner September 13, 2024 21:46
@nkolev92 nkolev92 added the Merge next release PRs that should not be merged until the dev branch targets the next release label Sep 19, 2024
@jgonz120
Copy link
Contributor Author

@nkolev92 this is going to a feature branch so I don't think there's a worry about merging.

@jgonz120 jgonz120 removed the Merge next release PRs that should not be merged until the dev branch targets the next release label Sep 23, 2024
newReadmeValue = readme;
}
}
await NuGetUIThreadHelper.JoinableTaskFactory.SwitchToMainThreadAsync(cancellationToken);
Copy link
Contributor

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.

Copy link
Contributor

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?

Copy link
Contributor Author

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

Copy link
Contributor

@jebriede jebriede Sep 27, 2024

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.

See: https://stackoverflow.com/questions/590590/making-%20sure-onpropertychanged-is-called-on-ui-thread-in-mvvm-wpf-app

Copy link
Contributor

@donnie-msft donnie-msft left a 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.

newReadmeValue = readme;
}
}
await NuGetUIThreadHelper.JoinableTaskFactory.SwitchToMainThreadAsync(cancellationToken);
Copy link
Contributor

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

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?

Copy link
Contributor Author

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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

Copy link
Contributor

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.

@jgonz120 jgonz120 changed the title Added the ReadmePreviewViewModel Added the ReadmePreviewViewModel & Edited NuGetPackageFileService Sep 27, 2024
@jgonz120 jgonz120 changed the title Added the ReadmePreviewViewModel & Edited NuGetPackageFileService Added the ReadmePreviewViewModel & edited NuGetPackageFileService Sep 27, 2024
@jgonz120 jgonz120 force-pushed the dev-jgonz120-AddReadmeViewmodel branch from 7338389 to 8581b86 Compare October 7, 2024 16:36
@jgonz120 jgonz120 force-pushed the dev-feature-ReadMeRenderingInPMUI branch from 04b7b97 to 12ae5e7 Compare October 7, 2024 16:41
@jgonz120 jgonz120 force-pushed the dev-jgonz120-AddReadmeViewmodel branch from 8581b86 to 75a56db Compare October 7, 2024 16:43
@jgonz120 jgonz120 merged commit 70823bf into dev-feature-ReadMeRenderingInPMUI Oct 7, 2024
28 checks passed
@jgonz120 jgonz120 deleted the dev-jgonz120-AddReadmeViewmodel branch October 7, 2024 20:42
jgonz120 added a commit that referenced this pull request Oct 10, 2024
)

Adds a new ViewModel for getting the README contents, leveraging the NuGetPackageFileService to get the file from the package.

---------

Co-authored-by: Jean-Pierre Briedé <jebriede@microsoft.com>
jgonz120 added a commit that referenced this pull request Oct 21, 2024
)

Adds a new ViewModel for getting the README contents, leveraging the NuGetPackageFileService to get the file from the package.

---------

Co-authored-by: Jean-Pierre Briedé <jebriede@microsoft.com>
jgonz120 added a commit that referenced this pull request Oct 21, 2024
)

Adds a new ViewModel for getting the README contents, leveraging the NuGetPackageFileService to get the file from the package.

---------

Co-authored-by: Jean-Pierre Briedé <jebriede@microsoft.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants