feat: add global search and dedicated search page#119
feat: add global search and dedicated search page#119it-education-md wants to merge 1 commit intoentrius:testfrom
Conversation
anderdc
left a comment
There was a problem hiding this comment.
I like the outcome of this PR, however there is fair amount of cleanup/abstraction that can be done
| case 'registered': | ||
| return { | ||
| color: STATUS_COLORS.warning, | ||
| bgColor: 'rgba(245, 158, 11, 0.15)', |
There was a problem hiding this comment.
I don't want any hardcoded colors introduced. Please use the theme or perhaps add new colors to the theme (if absolutely necessary)
| @@ -0,0 +1,60 @@ | |||
| import { type Theme } from '@mui/material/styles'; | |||
|
|
|||
| export const headerCellSx = (theme: Theme) => ({ | |||
There was a problem hiding this comment.
Although I like the organization, this file doesn't follow our current pattern of styling. Please leverage the theme or add in-line sx props to components. Then remove this file
There was a problem hiding this comment.
This file contains shared sx props used for tables in multiple tabs component so it removes code duplication.
| rowsPerPage, | ||
| rowsPerPageOptions, | ||
| }) => ( | ||
| <Card elevation={0} sx={tableCardSx}> |
There was a problem hiding this comment.
All these __Tab components follow the same pattern. I believe we can abstract out the core and other reused code to a 'base' component. Then all the tab components can just be child classes of the base component. You should be thinking in terms of OOP/component composition when there is a lot of reused code.
There is no way I'll accept the PR if this is not solved/cleaned up
|
Also there is a fair portion of |
Summary
This PR adds a unified search experience across the website.
It primarily focuses on functional improvement while also keeping the search UI visually aligned with the rest of the website.
/searchpage for full-result explorationThe main value here is simple: users should be able to find the item they want directly, without first knowing where it lives.
Type of Change
Checklist
npm run formatandnpm run lint:fixhave been runnpm run buildpassesWhy This Matters
Today, discovery is fragmented across multiple sections of the website. That makes navigation slower than it should be, especially for users who already know the miner, repository, PR, or issue they want.
New search removes that friction by introducing a single, reliable entry point for finding known entities and moving directly to the right destination.
This matters even more in a data-heavy website. As the volume of miners, repositories, pull requests, and issues grows over time, navigation by browsing alone becomes less efficient.
This makes the website feel:
Approach
1. Search Data Flow
The current search implementation is frontend-driven and intentionally lightweight.
This keeps the current implementation simple and consistent. If search scope or data volume grows materially, the next step would likely be a backend search endpoint rather than more frontend complexity.
2. Search UI/UX
The search experience is intentionally scoped around fast navigation and lightweight comparison.
The table fields:
This keeps search useful as a discovery layer without turning it into a heavier analysis surface.
3. Implementation
The implementation is intentionally split into a few clear responsibilities.
src/pages/search/searchData.tsowns shared search data loading, normalization, matching, ranking, and table-derived datasrc/components/layout/GlobalSearchBar.tsxowns the quick-search dropdown experience and direct result navigationsrc/pages/search/SearchPage.tsxowns full-search state, URL synchronization, tab selection, and paginationsrc/pages/search/own entity-specific table rendering for miners, repositories, pull requests, and issuessrc/pages/search/styles.tscentralizes the shared search-table styling so the tab UIs stay aligned without duplicating presentation logicThis keeps the feature easier to reason about by separating shared search behavior from surface-specific rendering.
Notes
Backto avoid extra UI friction as search adds more navigation paths, while navigation state still preserves return paths when history is unavailableScreenshots