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

Check cluster/ns in views + refactor + ui improvements #3623

Merged
merged 22 commits into from
Oct 22, 2021

Conversation

antgamdia
Copy link
Contributor

@antgamdia antgamdia commented Oct 20, 2021

Description of the change

This PR adds a bunch of improvements in the UI side, namely:

Bugs:

  • Avoid duplicated key in AppList view
    • No user-faced mgs, but errors in the console if two apps in different ns have the same name.
  • Clear the state when fetching apps
    • When navigating from the catalog, attempting to deploy sth and then, going back to the installed apps and trying to upgrade something, the values were the ones from the first visited package.
  • Prevent async errors when unmounting some components
    • No user-faced msg, but when navigating, some errors appeared in the console because of a wrong unmount of the component.

Features:

Refactor:

  • Use the package id instead of splitting the name by (/) to get the repo name.
  • Use the availablePkgSummary in the catalog item instead of using a custom data model.
  • Refactor PackageView and DeploymentForm to ensure proper usage of cluster/ns
  • Delete an unused route

Benefits

Avoid aforementioned bugs, new feature and cleaning-up of our code.

Possible drawbacks

Applicable issues

Additional information

Sending the PR as a draft for triggering the CI. Some tests are still pending (like the one for the named versioned upgrade link).
Edit: CI is failing? I still have to check why.

Adding the namespace to the "key" property
should avoid dups when enabling the "allNs" toggle

Signed-off-by: Antonio Gamez Diaz <agamez@vmware.com>
If not, the UpgradeView was loading a formerly fetched package

Signed-off-by: Antonio Gamez Diaz <agamez@vmware.com>
Signed-off-by: Antonio Gamez Diaz <agamez@vmware.com>
Signed-off-by: Antonio Gamez Diaz <agamez@vmware.com>
Signed-off-by: Antonio Gamez Diaz <agamez@vmware.com>
Instead of passing the info in yet another custom type.
However, this file needs another refactor once the opertors are a plugin

Signed-off-by: Antonio Gamez Diaz <agamez@vmware.com>
…luster/ns

This includes:
- Remove the repo from the URL; using the pkg ID instead.
- Remove trailing slash when replacing the version (prev. a bug if manually accessing the url)
- Simplify the useEffect hooks being used.
- Add comments to clarify which cluster/ns is each one.

Signed-off-by: Antonio Gamez Diaz <agamez@vmware.com>
Signed-off-by: Antonio Gamez Diaz <agamez@vmware.com>
Signed-off-by: Antonio Gamez Diaz <agamez@vmware.com>
Signed-off-by: Antonio Gamez Diaz <agamez@vmware.com>
Signed-off-by: Antonio Gamez Diaz <agamez@vmware.com>
Signed-off-by: Antonio Gamez Diaz <agamez@vmware.com>
Copy link
Contributor

@absoludity absoludity left a comment

Choose a reason for hiding this comment

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

+1 when ci passes.

Comment on lines -34 to -45
plugin: c.availablePackageRef?.plugin ?? ({ name: "", version: "" } as Plugin),
id: `package/${c.availablePackageRef?.identifier}/${c.latestVersion?.pkgVersion}`,
name: c.displayName,
icon: c.iconUrl ?? placeholder,
version: c.latestVersion?.pkgVersion ?? "",
description: c.shortDescription,
// TODO(agamez): get the repo name once available
// https://github.com/kubeapps/kubeapps/issues/3165#issuecomment-884574732
repo: {
name: c.availablePackageRef?.identifier.split("/")[0],
namespace: c.availablePackageRef?.context?.namespace,
} as IRepo,
Copy link
Contributor

Choose a reason for hiding this comment

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

It's not clear to me from context how all this data can be removed (or replaced with availablePackageSummary) - unless you've updated elsewhere to populate 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.

I didn't have the chance to write some comments to ease the review, but, yep, of course, I had to update it elsewhere. Particulary, this info is being used in the <InfoCard> that is rendered at PackageCatalogItem.tsx.

Ideally, these components would get simplified to just an AvailablePackageSummaryItem, but currently we sill to differentiate between a package and an operator.
Wherefore I just simply extracted the operator things (namespace, description, etc) back to the OperatorCatalogItem and simplify as much as I could the package item. However, I had to leave some fields (like the name: c.displayName as they were being used in the CatalogItem.

But, at least, we are converging, step by step, in simplifying the UI logic in favor of the new package data model.

Copy link
Contributor

Choose a reason for hiding this comment

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

Excellent. Thanks for the explanation :)

@@ -42,7 +42,7 @@ const testProps: IPackageHeaderProps = {

it("renders a header for the package", () => {
const wrapper = mount(<PackageHeader {...testProps} />);
expect(wrapper.text()).toContain("testrepo/test");
expect(wrapper.text()).toContain("testrepo/foo");
Copy link
Contributor

Choose a reason for hiding this comment

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

What's triggering an expectation change here?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It is a problem with the availablePackageDetail being passed. In fact, I'm fixing it instead of changing the assertion.

Let availablePackageDetail.name be test and availablePackageDetail.availablePackageRef.identifie be testrepo/foo,
before, we were concatening repo+name, that is testrepo/test and, now, we're just using the id, that is testrepo/foo

We just should change the availablePackageDetail.name from "test" to "foo".

Comment on lines -27 to -31
installedAppAvailablePackageDetail: AvailablePackageDetail;
installedAppInstalledPackageDetail: InstalledPackageDetail;
selectedPackage: IPackageState["selected"];
chartsIsFetching: boolean;
error?: Error;
Copy link
Contributor

Choose a reason for hiding this comment

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

So these props stopped being used or moved into state in a previous commit?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, I forgot to remove them when I moved them to the state. Now I'm just passing the version for the fixed upgrade.

@absoludity
Copy link
Contributor

Just noticed (while working on a PR on top of this branch) that the available package title appears to need decoding (guessing it's related here, but let me know if not):
flux-apache

Comment on lines -34 to -45
plugin: c.availablePackageRef?.plugin ?? ({ name: "", version: "" } as Plugin),
id: `package/${c.availablePackageRef?.identifier}/${c.latestVersion?.pkgVersion}`,
name: c.displayName,
icon: c.iconUrl ?? placeholder,
version: c.latestVersion?.pkgVersion ?? "",
description: c.shortDescription,
// TODO(agamez): get the repo name once available
// https://github.com/kubeapps/kubeapps/issues/3165#issuecomment-884574732
repo: {
name: c.availablePackageRef?.identifier.split("/")[0],
namespace: c.availablePackageRef?.context?.namespace,
} as IRepo,
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 didn't have the chance to write some comments to ease the review, but, yep, of course, I had to update it elsewhere. Particulary, this info is being used in the <InfoCard> that is rendered at PackageCatalogItem.tsx.

Ideally, these components would get simplified to just an AvailablePackageSummaryItem, but currently we sill to differentiate between a package and an operator.
Wherefore I just simply extracted the operator things (namespace, description, etc) back to the OperatorCatalogItem and simplify as much as I could the package item. However, I had to leave some fields (like the name: c.displayName as they were being used in the CatalogItem.

But, at least, we are converging, step by step, in simplifying the UI logic in favor of the new package data model.

Comment on lines +26 to 53

// Historically, this tag is used to show the repository a given package is from,
// but each plugin as its own way to describe the repository right now.
let repositoryName;
switch (availablePackageSummary.availablePackageRef?.plugin?.name) {
case PluginNames.PACKAGES_HELM:
repositoryName = availablePackageSummary.availablePackageRef?.identifier.split("/")[0];
break;
// TODO: consider the fluxv2 plugin
default:
// Fallback to the plugin name
repositoryName = availablePackageSummary.availablePackageRef?.plugin?.name;
break;
}

return (
<InfoCard
key={id}
title={decodeURIComponent(name)}
link={link}
info={version || ""}
icon={iconSrc}
description={trimDescription(description)}
tag1Content={<span>{repo.name}</span>}
bgIcon={bgIcon}
key={availablePackageSummary.availablePackageRef?.identifier}
title={decodeURIComponent(availablePackageSummary.displayName)}
link={packageViewLink}
info={availablePackageSummary?.latestVersion?.pkgVersion || ""}
icon={availablePackageSummary.iconUrl || placeholder}
description={trimDescription(availablePackageSummary.shortDescription)}
tag1Content={<span>{repositoryName}</span>}
bgIcon={getPluginIcon(availablePackageSummary.availablePackageRef?.plugin)}
/>
);
}
Copy link
Contributor Author

Choose a reason for hiding this comment

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

It's not clear to me from context how all this data can be removed (or replaced with availablePackageSummary) - unless you've updated elsewhere to populate that.

Here are the changes indeed. I've used this way to extract the repo name; not sure if we would want to include it as part of the API, though.

@@ -42,7 +42,7 @@ const testProps: IPackageHeaderProps = {

it("renders a header for the package", () => {
const wrapper = mount(<PackageHeader {...testProps} />);
expect(wrapper.text()).toContain("testrepo/test");
expect(wrapper.text()).toContain("testrepo/foo");
Copy link
Contributor Author

Choose a reason for hiding this comment

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

It is a problem with the availablePackageDetail being passed. In fact, I'm fixing it instead of changing the assertion.

Let availablePackageDetail.name be test and availablePackageDetail.availablePackageRef.identifie be testrepo/foo,
before, we were concatening repo+name, that is testrepo/test and, now, we're just using the id, that is testrepo/foo

We just should change the availablePackageDetail.name from "test" to "foo".

Comment on lines -27 to -31
installedAppAvailablePackageDetail: AvailablePackageDetail;
installedAppInstalledPackageDetail: InstalledPackageDetail;
selectedPackage: IPackageState["selected"];
chartsIsFetching: boolean;
error?: Error;
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, I forgot to remove them when I moved them to the state. Now I'm just passing the version for the fixed upgrade.

@antgamdia
Copy link
Contributor Author

antgamdia commented Oct 21, 2021

Just noticed (while working on a PR on top of this branch) that the available package title appears to need decoding (guessing it's related here, but let me know if not):

I can't repro it with Helm-direct :S, I'm using the the availablePackageDetail?.availablePackageRef?.identifier, so it shouldn't be encoded at this point, since there is no need for doing so.
Anyway, I'm adding a decodeURIComponent, which should be harmless unless the pkg does contain %-escaped characters, (like %2F), but I can't think of any proper package looking like that)

Signed-off-by: Antonio Gamez Diaz <agamez@vmware.com>
Signed-off-by: Antonio Gamez Diaz <agamez@vmware.com>
Signed-off-by: Antonio Gamez Diaz <agamez@vmware.com>
Signed-off-by: Antonio Gamez Diaz <agamez@vmware.com>
Signed-off-by: Antonio Gamez Diaz <agamez@vmware.com>
Signed-off-by: Antonio Gamez Diaz <agamez@vmware.com>
Signed-off-by: Antonio Gamez Diaz <agamez@vmware.com>
Signed-off-by: Antonio Gamez Diaz <agamez@vmware.com>
@antgamdia antgamdia marked this pull request as ready for review October 21, 2021 14:33
@absoludity
Copy link
Contributor

Just noticed (while working on a PR on top of this branch) that the available package title appears to need decoding (guessing it's related here, but let me know if not):

I can't repro it with Helm-direct :S, I'm using the the availablePackageDetail?.availablePackageRef?.identifier, so it shouldn't be encoded at this point, since there is no need for doing so. Anyway, I'm adding a decodeURIComponent, which should be harmless unless the pkg does contain %-escaped characters, (like %2F), but I can't think of any proper package looking like that)

OK, I'll recheck in my branch (using flux) once this lands.

I'll land this so I can continue and propose mine too. Thanks!

@absoludity absoludity merged commit 3429f6a into vmware-tanzu:master Oct 22, 2021
@antgamdia antgamdia deleted the ui-improvements branch October 25, 2021 09:05
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.

UI: "new package available" link should pre-fill the latest version Review cluster/namespace usage in the UI
2 participants