UI: Migrate <ConfigureAwsSecret /> to HDS & TS #27367

andaley · 2024-06-05T17:32:55Z

🛠️ Description

While prototyping WIF work I found a couple improvements that'll make WIF work easier. This pr:

migrates the tabs inside <ConfigureAwsSecret /> to use Hds::Tabs
converts the component to TS
updates tests to use general selectors and dom assertions

🔗 Links

#27342
See WIF UI whimsical

📸 Screenshots

🏗️ How to Build and Test the Change

github-actions · 2024-06-05T17:40:08Z

CI Results:
All Go tests succeeded! ✅

andaley · 2024-06-05T17:40:24Z

ui/tests/acceptance/aws-test.js

@@ -31,39 +37,37 @@ module('Acceptance | aws secret backend', function (hooks) {
    await click('[data-test-secret-backend-configure]');

    assert.strictEqual(currentURL(), `/vault/settings/secrets/configure/${path}`);
-    assert.ok(findAll('[data-test-aws-root-creds-form]').length, 'renders the empty root creds form');


assert.ok --> assert.dom because assert.ok cannot be trusted 🙅

andaley · 2024-06-05T17:41:20Z

ui/tests/acceptance/aws-test.js

-    assert.ok(
-      find('[data-test-flash-message]').textContent.trim(),
-      `The backend configuration saved successfully!`
+    assert.true(


the previous assertions would've passed even if the same flash message rendered, so this guarantees that a fresh message is rendered.

andaley · 2024-06-05T17:43:19Z

ui/app/components/configure-aws-secret.hbs

+  <T.Tab data-test-tab="access-to-aws">
+    Dynamic IAM root credentials
+  </T.Tab>
+  <T.Tab data-test-tab="lease">


one thing to note -- this page was previously using query params to keep track of which tabs were selected. if this is helpful for ensuring users can copy/paste a URL with a tab pre-selected i can totally add that back in, just wanted to make sure it was necessary first. 🙂

I think the new designs Yankun is working on will remove tabs all together. That aside, I think removing queryParams here is okay because given the fact this page never properly transitioned after save I suspect it's not being used as much as we'd hope.

ah, good to know! should i look into fixing the transition?

Two thoughts on the transition:

we make a pr that just fixes the transition and can be backported (so it couldn't depend on any changes here).

we address the transition here or a future pr and don't backport it. Nobody has complained.

I think ideally, we'd do number 1, but only if it was easy to both fix and backport—otherwise, we can proceed with a fix in this aws 1.18.x work.

good point, let's do #1. thanks!

andaley · 2024-06-05T17:44:39Z

ui/app/components/configure-aws-secret.hbs

+  <T.Panel>
+    <form
+      onsubmit={{action
+        "saveRootCreds"


this component was responsible for too much IMO, so i'll be splitting the 2 forms out into their own component in #27368 and #27370 and adding more specific integration tests

I'd say wait for the new designs first. We just spoke in standup about how KVv2 create also makes two network requests on save. I think it's in the same component but rendered conditionally. Also, something to keep in mind, do we need to make new components if they're not consumed elsewhere or is one configuration create component sufficient and separates the concerns clearly?

I'd say wait for the new designs first.

ah mk, if designs are going to change i can hold off, although i do already have PRs ready for them (see links in my first comment) 😅

We just spoke in standup about how KVv2 create also makes two network requests on save. I think it's in the same component but rendered conditionally.

whatcha mean by this? this component is only used when configuring an AWS secret engine. is there something else behind the scenes i'm missing?

do we need to make new components if they're not consumed elsewhere or is one configuration create component sufficient and separates the concerns clearly?

very fair question! there are a couple reasons why i often opt for splitting components up, even if they're not reused:

enforcing separation of concerns: if a component starts to handle multiple responsibilities (e.g., complex logic, numerous conditionals, and various arguments), it's an indicator that it might benefit from being split into smaller, more focused components. this makes each component simpler and easier to understand.

supporting readability and maintainability: when each component has a clear purpose, other developers (or my future self) can more easily understand what it does. this readability makes maintaining and updating the component simpler and less error-prone.

testing (this is usually my biggest motivator): components with too many responsibilities can become hard to test. writing comprehensive tests for a single, monolithic component requires covering a wide range of scenarios, which can be complex and time-consuming. by splitting components, you can create more targeted tests for each component's specific functionality, leading to more reliable and maintainable tests.

whatcha mean by this? this component is only used when configuring an AWS secret engine. is there something else behind the scenes i'm missing?

If we move away from these tabs and have only one view, then this will become a similar scenario to KVv2 create. Chelsea brought this up as example—it's just another create page that makes two network requests and both endpoints have different permission checks because they're different paths—similar to aws configure with /root vs /leases. It was just an example we could turn to if we needed to see how we handled a similar situation.

Yankun is working on the designs today so they should be done soon but I suspect we'll move to one create view with now tabs.

And for splitting up in components, thank you for the thoughts. Testing is a great point, and with that in mind splitting into two components makes sense. I'll check out your current WIP prs and any thoughts and feelings I'll put there, but please feel free to continue on that work.

github-actions · 2024-06-05T17:45:36Z

Build Results:
All builds succeeded! ✅

Monkeychip

A couple of non-blocking comments, more for the next chunk of work.

Monkeychip · 2024-06-05T17:54:02Z

Also, let's change the milestone to 1.18.0. At 1.17.1 it indicates we'll need to backport to 1.17.x and we don't really backport feature changes to minor patches.

andaley added ui pr/no-changelog hashicorp-contributed-pr If the PR is HashiCorp (i.e. not-community) contributed labels Jun 5, 2024

andaley added this to the 1.17.1 milestone Jun 5, 2024

andaley marked this pull request as ready for review June 5, 2024 17:39

andaley requested a review from a team as a code owner June 5, 2024 17:39

andaley commented Jun 5, 2024

View reviewed changes

andaley changed the title ~~UI: migrate configure aws secret hds~~ UI: Migrate <ConfigureAwsSecret /> to HDS & TS Jun 5, 2024

Monkeychip approved these changes Jun 5, 2024

View reviewed changes

andaley modified the milestones: 1.17.1, 1.18.0-rc Jun 5, 2024

Noelle Daley added 4 commits June 6, 2024 09:40

feat: migrate configure-aws-secret to HDS::Tabs

b903912

chore: co-locate configure-aws-secret template

e97081a

chore: convert configure-aws-secret to TS

f21b6b0

tests: fix aws acceptance tests

52af959

andaley force-pushed the ui/migrate-configure-aws-secret-hds branch from 4ea66d5 to 52af959 Compare June 6, 2024 13:42

andaley enabled auto-merge (squash) June 6, 2024 13:43

andaley merged commit 15532cf into main Jun 6, 2024
31 checks passed

andaley deleted the ui/migrate-configure-aws-secret-hds branch June 6, 2024 13:57

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

UI: Migrate <ConfigureAwsSecret /> to HDS & TS #27367

UI: Migrate <ConfigureAwsSecret /> to HDS & TS #27367

andaley commented Jun 5, 2024 •

edited

Loading

github-actions bot commented Jun 5, 2024 •

edited

Loading

andaley Jun 5, 2024

andaley Jun 5, 2024

andaley Jun 5, 2024

Monkeychip Jun 5, 2024

andaley Jun 5, 2024 •

edited

Loading

Monkeychip Jun 5, 2024

andaley Jun 6, 2024

andaley Jun 5, 2024 •

edited

Loading

Monkeychip Jun 5, 2024

andaley Jun 5, 2024

Monkeychip Jun 5, 2024

github-actions bot commented Jun 5, 2024

Monkeychip left a comment

Monkeychip commented Jun 5, 2024

UI: Migrate <ConfigureAwsSecret /> to HDS & TS #27367

UI: Migrate <ConfigureAwsSecret /> to HDS & TS #27367

Conversation

andaley commented Jun 5, 2024 • edited Loading

🛠️ Description

🔗 Links

📸 Screenshots

🏗️ How to Build and Test the Change

github-actions bot commented Jun 5, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

andaley Jun 5, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

andaley Jun 5, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

github-actions bot commented Jun 5, 2024

Monkeychip left a comment

Choose a reason for hiding this comment

Monkeychip commented Jun 5, 2024

andaley commented Jun 5, 2024 •

edited

Loading

github-actions bot commented Jun 5, 2024 •

edited

Loading

andaley Jun 5, 2024 •

edited

Loading

andaley Jun 5, 2024 •

edited

Loading