UI: Migrate <ConfigureAwsSecret /> to HDS & TS

[andaley]

🛠️ 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]

CI Results:
All Go tests succeeded! ✅

[andaley]

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

[andaley]

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

[andaley]

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. 🙂

[Monkeychip]

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.

[andaley]

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

[Monkeychip]

Two thoughts on the transition:

1. we make a pr that just fixes the transition and can be backported (so it couldn't depend on any changes here).
2. 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.

[andaley]

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

[andaley]

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

[Monkeychip]

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?

[andaley]

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:

1. 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.

2. 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.

3. 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.

[Monkeychip]

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]

Build Results:
All builds succeeded! ✅

[Monkeychip]

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

[Monkeychip]

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.