Incorrect Labs control's link on WCT Gallery app

[AndrewKeepCoding]

Describe the bug

The links for [LABS] items are incorrect.
For example, the link for the DataTable control is:

https://github.com/CommunityToolkit/Windows/tree/main/components/DataTable

It should be:

https://github.com/CommunityToolkit/Labs-Windows/tree/main/components/DataTable

Steps to reproduce

1. Run the WCT Gallery app.
1. Click any [LABS] control (item) on the Home page
1. Click the [Source code] button

Expected behavior

Go to the corresponding source code

Screenshots

No response

Code Platform

• UWP
• WinAppSDK / WinUI 3
• Web Assembly (WASM)
• Android
• iOS
• MacOS
• Linux / GTK

Windows Build Number

• Windows 10 1809 (Build 17763)
• Windows 10 1903 (Build 18362)
• Windows 10 1909 (Build 18363)
• Windows 10 2004 (Build 19041)
• Windows 10 20H2 (Build 19042)
• Windows 10 21H1 (Build 19043)
• Windows 10 21H2 (Build 19044)
• Windows 10 22H2 (Build 19045)
• Windows 11 21H2 (Build 22000)
• Other (specify)

Other Windows Build number

No response

App minimum and target SDK version

• Windows 10, version 1809 (Build 17763)
• Windows 10, version 1903 (Build 18362)
• Windows 10, version 1909 (Build 18363)
• Windows 10, version 2004 (Build 19041)
• Windows 10, version 2104 (Build 20348)
• Windows 11, version 22H2 (Build 22000)
• Other (specify)

Other SDK version

No response

Visual Studio Version

No response

Visual Studio Build Number

No response

Device form factor

No response

Additional context

No response

Help us help you

Yes, I'd like to be assigned to work on this item.

[michael-hawker]

Related to CommunityToolkit/Tooling-Windows-Submodule#19

This isn't that simple of an issue unfortunately.

The sample app just assumes everything is from one repository, so we don't have configuration per component to tell it otherwise at the moment. So, that's why they point to the wrong place, as we decided later to add in the labs components for discoverability, as people would be asking about them all the time... but the sample app needs a bit more work still.

https://github.com/search?q=repo%3ACommunityToolkit%2FTooling-Windows-Submodule%20ToComponentUri&type=code

Grabbing from the assembly attribute defined by the hosting repo:

https://github.com/CommunityToolkit/Tooling-Windows-Submodule/blob/83dff9fab1be976d2ae4d401f15af9c6b889caeb/CommunityToolkit.App.Shared/Renderers/ToolkitDocumentationRenderer.xaml.cs#L35-L38

We don't really have a great hook at the moment to do a lot of extra custom logic to determine the source of a component (as we build the sample app by just dumping the components from one repo in another vs. having a system that knows about both repos).

And we haven't really wanted to explicitly have to define this for every sample/doc.

Ultimately, as part of the ability for the sample to be skinnable and re-useable for hosting any components and for other projects like the AI Dev Gallery and the WinUI Gallery, we need to have some sort of plugin structure which can provide assets as well as code, which then can get all the source/metadata about the components and transform/provide the proper behavior for these types of scenarios.

[AndrewKeepCoding]

Since each component card from Labs shows a [Labs] yellow tag, I thought we could use it to create the correct URL.

For instance, replacing:

ToolkitDocumentationRenderer.xaml.cs

public static Uri? ToComponentUri(string name) => IsProjectPathValid() ? new Uri($"{ProjectUrl}/tree/main/components/{name}") : null;

with:

public static Uri? ToComponentUri(string name, bool? isExperimental = null)
{
    if (IsProjectPathValid() is not true)
    {
        return null;
    }

    string? url = (isExperimental is null || isExperimental is false)
        ? ProjectUrl
        : ProjectUrl?.Replace("Windows", "Labs-Windows");

    return new Uri($"{url}/tree/main/components/{name}");
}

then use it:

ToolkitDocumentationRenderer.xaml

<behaviors:NavigateToUriAction
    NavigateUri="{x:Bind renderer:ToolkitDocumentationRenderer.ToComponentUri(Metadata.ComponentName, Metadata.IsExperimental), Mode=OneWay}" />

[michael-hawker]

Have a test for this locally. Also needed to update ToPackageUri with a similar pattern to point to the Labs nuget feed root: https://dev.azure.com/dotnet/CommunityToolkit/_artifacts/feed/CommunityToolkit-Labs/NuGet/

[michael-hawker]

@Arlodotexe looks like we have some sort of inconsistencies in the project names and the package names. Like the Labs packages have .Labs. in them, but not all the project files do... this trips up some of how the sample app looks at the metadata to create links.

I think this is tied to a simplification we tried to do a while back for the namespaces, but we still wanted the packages to have Labs or something. And now we're just inconsistent, so I may need to think about how to fix this for the package links.

[michael-hawker]

Ribbon and TitleBar (and maybe others are also mismatched with whether or not they have .Controls. between project name and package.

If we figure out what things should be, we can ensure the sample app is built that way, and then update them in the feed before it goes live.