feat: add search functionality to views (part 1: Resources)

[shouples]

Summary of Changes

This PR adds a lot of basic functionality for view searching, which is initially available in the Resources view via ctrl+f/cmd+f when the view is focused.

resources-view-search.mov

Follow-on (smaller) PRs will implement this view-search functionality for the Topics and Schemas views.

Any additional details or context that should be provided?

Explanation of behavior

When the user enters a search string through this new <view>.search command, it sets an itemSearchString property on the view provider. This causes two main things to happen:

• getChildren() will now filter any items based on two ideas:

  • the items will directly match or they will have children that match based on their searchableText property
  • if getChildren() was called due to expanding an element, if that element was previously returned as a filtered result, all of its children will also be returned so the user can expand them

• getTreeItem() will now:

  • adjust the *TreeItem's collapsible state depending on whether or not it has children that matched the search string
  • update the resourceUri for any *TreeItem(s) that matched the search string, taking advantage of the (new) FileDecorationProvider and allowing the label(s), description(s) (if available), and a right-justified character to be (theme-)colored differently:

• Since ContainerTreeItem is now "searchable", its children must also now implement ISearchable -- otherwise we end up having a lot of funky Typescript workarounds to make T and ISearchable play nicely together.

Pull request checklist

Please check if your PR fulfills the following (if applicable):

Tests

• Added new
• Updated existing
• Deleted existing

Other

• All new disposables (event listeners, views, channels, etc.) collected as for eventual cleanup?

• Does anything in this PR need to be mentioned in the user-facing CHANGELOG or README?
• Have you validated this change locally by packaging and installing the extension .vsix file?

  gulp clicktest

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

Files not reviewed (7)

• package.json: Language not supported
• src/commands/extra.ts: Evaluated as low risk
• src/context/values.ts: Evaluated as low risk
• src/viewProviders/resources.ts: Evaluated as low risk
• src/models/schemaRegistry.ts: Evaluated as low risk
• src/models/main.ts: Evaluated as low risk
• src/models/environment.ts: Evaluated as low risk

Comments suppressed due to low confidence (1)

src/models/kafkaCluster.ts:21

• Ensure that the searchableText method is covered by tests to validate its behavior.

searchableText(): string {

[shouples]

Unrelated to this PR; came up doing a search for "Schema Registry" label usage and can be removed since it's a lowercase version of what we already have

[shouples]

Unrelated to this PR; TS hollering that the TEST_CCLOUD_ENVIRONMENT.id wasn't an EnvironmentID branded string type

[jlrobins]

Yeah, am unsure why we're notified about these in a trickle.

Copilot reviewed 5 out of 19 changed files in this pull request and generated no comments.

Files not reviewed (14)

• package.json: Language not supported
• src/models/schemaRegistry.ts: Evaluated as low risk
• src/commands/extra.ts: Evaluated as low risk
• src/viewProviders/resources.test.ts: Evaluated as low risk
• tests/unit/testResources/kafkaCluster.ts: Evaluated as low risk
• src/viewProviders/collapsing.test.ts: Evaluated as low risk
• src/context/values.ts: Evaluated as low risk
• CHANGELOG.md: Evaluated as low risk
• src/emitters.ts: Evaluated as low risk
• src/models/environment.ts: Evaluated as low risk
• src/models/kafkaCluster.ts: Evaluated as low risk
• src/models/schema.ts: Evaluated as low risk
• src/models/main.ts: Evaluated as low risk
• src/viewProviders/resources.ts: Evaluated as low risk

[shouples]

If we didn't provide a tooltip for our searchable items already, this is where we could parse the query of a (view) Uri to extract the search string (and any other info) to dynamically generate the decoration. Not necessary/applicable for now.

[jlrobins]

Is this supposed to always ensure that the new id value changes?

[shouples]

Yep, it just needs to change from the "without search" id being used, due to the odd behavior we've seen in the past when dynamically adjusting collapsible states and not changing the id like with the "Confluent Cloud" container between sign-in/sign-out:

vscode/src/viewProviders/resources.ts

Lines 430 to 431 in 8591d90

	// XXX: adjust the ID to ensure the collapsible state is correctly updated in the UI
	cloudContainerItem.id = `ccloud-connected-${EXTENSION_VERSION}`;

[jlrobins]

It would seem that the id would keep growing, if, say, someone does a search starting from the search button, then does one through the command palate, etc.

Probably inconsequential, however.

[jlrobins]

Works great! Love the UI and snappiness.

Only minor nits can be 1) ignored, 2) touched up in future, 3) done up front.

[jlrobins]

Probably overkill as a Set. Not like going to have any actual duplicates pushed into it, and is only ultimately used to determine size/count of matches. Could be a ResourceViewProviderData[] ?

[shouples]

Yeah, I went back and forth on this a bit -- agreed we should never add duplicates if this were an array of the provider's data type. Is a slightly easier mental model to know the matches would never be duplicated and the count displayed as the view message would be accurate, but I don't think we'd see much (if any) performance benefit of a Set over an array.

[jlrobins]

If the view being searched made sure to lowercase searchStr before the looped calls into itemMatchesSearch() and / or traverseMatches(), then whole milliseconds would be saved in not repeatedly lowercasing searchStr.

The truly squirrelbrained would make a branded type for lowercased strings, but that's a hairy tail too far, innit? Or isn't it?

[shouples]

True, but would then force all callers to make sure it was .toLowerCase() which could make this more fragile

[jlrobins]

Yeah, am unsure why we're notified about these in a trickle.