refactor(ui): fetch results on submit instead of on type

[MatteoGabriele]

• Merges the two search boxes on the homepage and header.
• Changes the update to occur on submit rather than on typing. This reduces requests to the registry API, minimizes router updates to the input value, which can cause issues like missing letters, and prevents empty responses when results are available.
• Fixes a minor accessibility issue where focus could get stuck on the hidden search form button in the header.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
npmx.dev	Ready	Preview, Comment	Feb 7, 2026 3:38pm

2 Skipped Deployments

Project	Deployment	Actions	Updated (UTC)
docs.npmx.dev	Ignored	Preview	Feb 7, 2026 3:38pm
npmx-lunaria	Ignored		Feb 7, 2026 3:38pm

[codecov]

Codecov Report

❌ Patch coverage is 52.63158% with 18 lines in your changes missing coverage. Please review.
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
app/components/SearchBox.vue	65.21%	8 Missing ⚠️
app/components/AppHeader.vue	45.45%	4 Missing and 2 partials ⚠️
app/pages/index.vue	0.00%	2 Missing and 2 partials ⚠️

📢 Thoughts on this report? Let us know!

[coderabbitai]

📝 Walkthrough

Walkthrough

This pull request refactors the search functionality by consolidating and relocating the search component logic. A new generic SearchBox component is introduced to replace the Header-specific SearchBox, which is removed. The AppHeader component is updated to handle search query synchronisation with the URL via a debounced handler and route watcher. The home page search submission is simplified. Test files are updated to reference the new SearchBox component and unified search input selector.

Possibly related PRs

• feat: polish ui #971: Modifies header search UI in the same files (AppHeader.vue and Header/SearchBox.vue), applying UI/style tweaks alongside the refactoring of search component structure.

Suggested reviewers

• danielroe

🚥 Pre-merge checks | ✅ 1

✅ Passed checks (1 passed)

Check name	Status	Explanation
Description check	✅ Passed	The pull request description accurately describes the changeset: merging two search boxes, changing updates from typing to submit, and fixing an accessibility issue.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 2

🧹 Nitpick comments (2)

app/components/SearchBox.vue (1)

77-93: Remove inline focus-visible utility from the <button> element.

The button at line 79 uses focus-visible:outline-accent/70, but project convention is to rely on the global rule in main.css for buttons and selects. Based on learnings: "individual buttons or selects in Vue components should not rely on inline focus-visible utility classes like focus-visible:outline-accent/70."

♻️ Proposed fix

          <button
            type="submit"
-           class="absolute hidden `@xs`:block group inset-ie-2.5 font-mono text-sm transition-[background-color,transform] duration-200 active:scale-95 focus-visible:outline-accent/70"
+           class="absolute hidden `@xs`:block group inset-ie-2.5 font-mono text-sm transition-[background-color,transform] duration-200 active:scale-95"

app/components/AppHeader.vue (1)

33-42: Consider extracting duplicated search-navigation logic into a composable.

handleSearchSubmit is identical in both index.vue and AppHeader.vue. A shared composable (e.g., useSearchNavigation) would reduce duplication and ensure consistent behaviour if the navigation logic changes.

[danielroe]

would you check the e2e tests? they test a lot of functionality that has changed, so I expect they need to be updated....

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (1)

app/components/SearchBox.vue (1)

74-90: Remove inline focus-visible utility from the submit button.

The submit button applies focus-visible:outline-accent/70 as an inline utility class. The project applies focus-visible styling for button and select elements globally via main.css. Per-element inline utilities on buttons should be avoided to keep styling consistent and maintainable.

Proposed fix

          <button
            type="submit"
-           class="absolute hidden `@xs`:block group inset-ie-2.5 font-mono text-sm transition-[background-color,transform] duration-200 active:scale-95 focus-visible:outline-accent/70"
+           class="absolute hidden `@xs`:block group inset-ie-2.5 font-mono text-sm transition-[background-color,transform] duration-200 active:scale-95"

Based on learnings: "In the npmx.dev project, focus-visible styling for buttons and selects is applied globally via main.css… individual buttons or selects in Vue components should not rely on inline focus-visible utility classes like focus-visible:outline-accent/70."

[ghostdevv]

I noticed that when I search for something that has an exact match, I press enter to trigger the search I see the results for half a second then I get taken to the package because of the exact match

Changes the update to occur on submit rather than on typing. This reduces requests to the registry API, minimizes router updates to the input value, which can cause issues like missing letters, and prevents empty responses when results are available.

it would be nice if it was throttled (as you're typing it searches every N seconds), but I understand that it may be tricky with the whole navigation between pages and such.

[ghostdevv]

what's the difference in nuxt between the router.push that was happening before, and this?

[MatteoGabriele]

In this case, I think either option would work.
Previously, this component had no route handling, so I copy-pasted the function from the homepage, as they serve the same purpose. I didn't check whether it was navigateTo or router.push, since they essentially perform the same action. I believe navigateTo is a helper function that can also be used on the server side.

[MatteoGabriele]

@ghostdevv I see that "exact" behaviour as well now.
I'm going to review that part of the logic because, now that we always press enter, that functionality might no longer be working as expected.

[MatteoGabriele]

@ghostdevv I've removed the "Enter to exact" functionality since we now use Enter to actually search. What do you think?
Not sure what you meant by the throttling part, since we now work on submit instead of on-type.
thanks for your help

[ghostdevv]

I just wonder if we can't solve the search issue without sacrificing on enter to exact or the results updating as you type... like the registry requests is annoying but can be fine tuned/cached I think and is worth it for the user experience, and the other issues should be solvable 🤔 wdyt?

Not sure what you meant by the throttling part, since we now work on submit instead of on-type.

just as an alternative to debounce which has a nicer UX - but it only matters if we can fix the underlying problems

[MatteoGabriele]

@ghostdevv I have re-implemented an update-on-type feature, but instead of using a watcher, I am now debouncing the search input update so it is not linked to the route update. It seems to be working better, avoiding the weird update loop we had before. I also re-enabled the enter key functionality.

Let me know what you think of this version.

PS: The index still uses the Enter key to prevent accidental page change while typing, which could cause loss of focus or characters, or a disruptive experience.