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

Add display name and priority support to endpoints #7442

Open
wants to merge 11 commits into
base: main
Choose a base branch
from

Conversation

adamint
Copy link
Member

@adamint adamint commented Feb 6, 2025

Description

Adds two optional properties to Url and EndpointAnnotation - namely, DisplayName and Priority, that are used in the dashboard to determine 1) display order, and 2) display name.

Links still show up on the dashboard, just with the text replaced with the display name if set.
image

Additionally, adds a third Display name column to the dashboard that shows the display name of the endpoint if it is set.
(no display names)
image

(pgAdmin has a display name)
image

Also sets the endpoint display name on the CosmosDB data explorer to "Data Explorer".

Fixes #7104

Checklist

  • Is this feature complete?
    • Yes. Ready to ship.
    • No. Follow-up changes expected.
  • Are you including unit tests for the changes and scenario tests if relevant?
    • Yes
    • No
  • Did you add public API?
    • Yes
      • If yes, did you have an API Review for it?
        • Yes
        • No
      • Did you add <remarks /> and <code /> elements on your triple slash comments?
        • Yes
        • No
    • No
  • Does the change make any security assumptions or guarantees?
    • Yes
      • If yes, have you done a threat model and had a security review?
        • Yes
        • No
    • No
  • Does the change require an update in our Aspire docs?

@davidfowl
Copy link
Member

I'm trying to figure out if we should split the visual impact of the endpoint vs the endpoint definition. They should be different annotations.

@adamint
Copy link
Member Author

adamint commented Feb 6, 2025

I'm trying to figure out if we should split the visual impact of the endpoint vs the endpoint definition. They should be different annotations.

Why should they? If display name is a friendly name for the endpoint, that seems like an integral part of the definition itself

@davidfowl
Copy link
Member

This data doesn't go into the manifest right? I am thinking that there's a core annotation that is used for networking and another part of it that is used for display in the dashboard.

@danmoseley danmoseley requested a review from Copilot February 7, 2025 02:10

Choose a reason for hiding this comment

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

Copilot reviewed 12 out of 27 changed files in this pull request and generated no comments.

Files not reviewed (15)
  • src/Aspire.Dashboard/Resources/ControlsStrings.Designer.cs: Language not supported
  • src/Aspire.Dashboard/Resources/ControlsStrings.resx: Language not supported
  • src/Aspire.Dashboard/Resources/xlf/ControlsStrings.cs.xlf: Language not supported
  • src/Aspire.Dashboard/Resources/xlf/ControlsStrings.de.xlf: Language not supported
  • src/Aspire.Dashboard/Resources/xlf/ControlsStrings.es.xlf: Language not supported
  • src/Aspire.Dashboard/Resources/xlf/ControlsStrings.fr.xlf: Language not supported
  • src/Aspire.Dashboard/Resources/xlf/ControlsStrings.it.xlf: Language not supported
  • src/Aspire.Dashboard/Resources/xlf/ControlsStrings.ja.xlf: Language not supported
  • src/Aspire.Dashboard/Resources/xlf/ControlsStrings.ko.xlf: Language not supported
  • src/Aspire.Dashboard/Resources/xlf/ControlsStrings.pl.xlf: Language not supported
  • src/Aspire.Dashboard/Resources/xlf/ControlsStrings.pt-BR.xlf: Language not supported
  • src/Aspire.Dashboard/Resources/xlf/ControlsStrings.ru.xlf: Language not supported
  • src/Aspire.Dashboard/Resources/xlf/ControlsStrings.tr.xlf: Language not supported
  • src/Aspire.Dashboard/Resources/xlf/ControlsStrings.zh-Hans.xlf: Language not supported
  • src/Aspire.Dashboard/Resources/xlf/ControlsStrings.zh-Hant.xlf: Language not supported
Comments suppressed due to low confidence (1)

src/Aspire.Dashboard/Model/ResourceViewModel.cs:330

  • The constructor parameters 'displayName' and 'priority' should be renamed to 'DisplayName' and 'Priority' to match the property names.
public UrlViewModel(string name, Uri url, bool isInternal, string? displayName = null, int? priority = null)
@davidfowl
Copy link
Member

Thinking out loud, maybe it's fine to create a nested display properties on EndpointAnnotion where we store these properties. I don't think we add to the chaos that is part of these methods an maybe we treat these like properties you set with

WithEndpoint("name", e => e.DisplayName = "")

@JamesNK
Copy link
Member

JamesNK commented Feb 7, 2025

What do other people think about having the grid in details showing a name and display name column? It feels like we lose out on the simplicit of a name/value grid.

image


Instead, what about showing the display name as the link text in the value column? The visualizer would open to show the underlying address. That makes the details consistent with what is shown in the grid (which shows the link using the display name), lets endpoints grid still be name/value, and it makes the code simpler.

On the other hand, it makes it more difficult to see the address port in details at a glance, which people might want.

Thoughts?

@davidfowl
Copy link
Member

Not a fan of the 2 columns

@adamint
Copy link
Member Author

adamint commented Feb 7, 2025

What do other people think about having the grid in details showing a name and display name column? It feels like we lose out on the simplicit of a name/value grid.

image

Instead, what about showing the display name as the link text in the value column? The visualizer would open to show the underlying address. That makes the details consistent with what is shown in the grid (which shows the link using the display name), lets endpoints grid still be name/value, and it makes the code simpler.

On the other hand, it makes it more difficult to see the address port in details at a glance, which people might want.

Thoughts?

Yeah, there's a tension between showing all the data and adding more visual complexity.

On the other hand, it makes it more difficult to see the address port in details at a glance, which people might want.

was the reason I initially added the third column - I'd prefer to be able to see the endpoint URL without needing to hover over the value, but don't have a strong opinion here

@adamint
Copy link
Member Author

adamint commented Feb 7, 2025

Thinking out loud, maybe it's fine to create a nested display properties on EndpointAnnotion where we store these properties. I don't think we add to the chaos that is part of these methods an maybe we treat these like properties you set with

WithEndpoint("name", e => e.DisplayName = "")

Yeah I like that idea. Done

@adamint adamint requested a review from drewnoakes February 7, 2025 13:35
@JamesNK
Copy link
Member

JamesNK commented Feb 7, 2025

Add a display name to some endpoints in TestShop. I'll pull the branch and try it out tomorrow.

/// <summary>
/// Gets the display properties for this endpoint.
/// </summary>
public EndpointDisplayProperties DisplayProperties => EndpointAnnotation.DisplayProperties;
Copy link
Member

Choose a reason for hiding this comment

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

Who uses this?

Copy link
Member Author

Choose a reason for hiding this comment

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

ResourceSnapshotBuilder, #239, #246, #253

Copy link
Member

@davidfowl davidfowl left a comment

Choose a reason for hiding this comment

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

Address the breaking change and this is good to go!


public static class ResourceBuilderExtensions
{
public static IResourceBuilder<T> WithModifiedEndpoints<T>(this IResourceBuilder<T> builder, Action<EndpointAnnotation> callback) where T : IResourceWithEndpoints
Copy link
Member

Choose a reason for hiding this comment

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

Do you need this?

Comment on lines +41 to +44
.WithModifiedEndpoints(c =>
{
c.DisplayProperties.DisplayName = "TestShop frontend access";
})
Copy link
Member

@JamesNK JamesNK Feb 7, 2025

Choose a reason for hiding this comment

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

This seems like a bit of a sledge hammer to give names to endpoints from the launch profile.

@davidfowl Do you want to be able to give names to individual endpoints from the launch profile? Is there an existing pattern for enriching EndpointAnnotation instances created from the launch profile with extra values?

Copy link
Member

Choose a reason for hiding this comment

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

I think so yes.

@davidfowl
Copy link
Member

I'd also want to use this in the BicepProvisioner to set the display for the deployment url.

@adamint
Copy link
Member Author

adamint commented Feb 10, 2025

BicepProvisioner

What do you want to be displayed?

@davidfowl
Copy link
Member

#7442 (comment)

Don't block on this.

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.

Add support for "Display Name" for endpoints in the Dashboard
5 participants