chore: Sourcebot REST api surface #290
Conversation
|
Caution Review failedThe pull request is closed. WalkthroughThis change reorganizes and modularizes the codebase for search-related functionality in the web package. It removes the previous monolithic implementations of search APIs, types, and schemas from the Changes
Sequence Diagram(s)sequenceDiagram
participant UI
participant SearchAPI
participant Zoekt
participant DB
UI->>SearchAPI: search({ query, matches, ... }, orgId)
SearchAPI->>SearchAPI: transformZoektQuery(query)
alt context: prefix
SearchAPI->>DB: fetch context repositories
DB-->>SearchAPI: repo list or error
SearchAPI->>SearchAPI: build reposet: query
end
SearchAPI->>Zoekt: POST /api/search with transformed query and org header
Zoekt-->>SearchAPI: JSON search response
SearchAPI->>SearchAPI: validate & transform response
SearchAPI-->>UI: SearchResponse or ServiceError
sequenceDiagram
participant UI
participant FileSourceAPI
participant SearchAPI
UI->>FileSourceAPI: getFileSource({ fileName, repository, branch }, orgId)
FileSourceAPI->>SearchAPI: search(query for file, matches=1, whole=true, orgId)
SearchAPI-->>FileSourceAPI: SearchResponse or ServiceError
alt file found
FileSourceAPI-->>UI: { content, language }
else file not found
FileSourceAPI-->>UI: fileNotFound error
end
sequenceDiagram
participant UI
participant ListReposAPI
participant Zoekt
UI->>ListReposAPI: listRepositories(orgId)
ListReposAPI->>Zoekt: POST /api/list with org header
Zoekt-->>ListReposAPI: JSON list response
ListReposAPI->>ListReposAPI: validate & transform response
ListReposAPI-->>UI: ListRepositoriesResponse or ServiceError
Possibly related PRs
Suggested reviewers
Poem
📜 Recent review detailsConfiguration used: CodeRabbit UI ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (3)
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
brendan-kellam
changed the title
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
🔭 Outside diff range comments (1)
packages/web/src/app/[domain]/search/components/filterPanel/index.tsx (1)
173-176:⚠️ Potential issuePotential runtime crash when
repository/languageisundefined.
match[propName]is assumed to be a non-empty string, but neither the type system nor the incoming JSON guarantees this.
If a file object is missinglanguage(fairly common in search APIs) orrepository,key.lengthwill throw.- .map((match) => match[propName]) - .filter((key) => key.length > 0) + .map((match) => match[propName] ?? "") + .filter((key): key is string => key.length > 0)This keeps the pipeline safe while still filtering out empty strings.
Consider tightening theSearchResultFiletype so the compiler can help catch this earlier.
🧹 Nitpick comments (9)
packages/web/src/app/[domain]/connections/quickActions.tsx (1)
405-407: Prefer literal apostrophe for readability and compatibility
The apostrophe in JSX text nodes doesn’t require escaping, and using'may reduce readability and can be unsupported in some HTML parsers. Switching back to a literal'(or using the numeric entity') is sufficient and more compatible.Suggested diff:
- <span>Username to use for authentication. This is only required if you're using an App Password (stored in <Code>token</Code>) for authentication.</span> + <span>Username to use for authentication. This is only required if you're using an App Password (stored in <Code>token</Code>) for authentication.</span>packages/web/src/app/[domain]/components/fileHeader.tsx (1)
1-1: Use a type-only import forRepository
SinceRepositoryis only used as a TypeScript type here, switch to a type-only import to avoid including unneeded runtime code in the bundle:-import { Repository } from "@/features/search/types"; +import type { Repository } from "@/features/search/types";packages/web/src/app/[domain]/search/page.tsx (1)
43-46: Guard against invalid or negativematchesvalues.
parseIntcan yieldNaNor negative numbers (e.g.,matches=-5).
Down-stream logic – particularly the Zoekt API – expects a positive integer.-const _matches = parseInt(useNonEmptyQueryParam(SearchQueryParams.matches) ?? `${DEFAULT_MATCH_COUNT}`); -const matches = isNaN(_matches) ? DEFAULT_MATCH_COUNT : _matches; +const rawMatches = parseInt( + useNonEmptyQueryParam(SearchQueryParams.matches) ?? `${DEFAULT_MATCH_COUNT}`, + 10, +); +const matches = !rawMatches || rawMatches <= 0 ? DEFAULT_MATCH_COUNT : rawMatches;packages/web/src/features/search/searchApi.ts (1)
125-128: Header object can be a constant; current re-assignment is redundant.The temporary
let headerfollowed by immediate overwrite adds noise and defeatsconstsafety.-let header: Record<string, string> = {}; -header = { - "X-Tenant-ID": orgId.toString() -}; +const header = { + "X-Tenant-ID": orgId.toString(), +};packages/web/src/features/search/zoektSchema.ts (1)
20-41: Consider wrapping stats in a Zod object
Right nowzoektSearchResponseStatsis a plain object of Zod validators and is spread into anotherz.object. For consistency and reusability, you may define it as az.object(...)itself:-export const zoektSearchResponseStats = { +export const zoektSearchResponseStats = z.object({ ContentBytesLoaded: z.number(), IndexBytesLoaded: z.number(), … FlushReason: z.number(), -} +});This lets you refer to the stats schema directly (e.g.
zoektSearchResponseStats.parse(...)).packages/web/src/features/search/schemas.ts (4)
3-10: Location schema is clear and typed
locationSchemacaptures byte offset and human-readable coordinates. Consider adding.int().nonnegative()if you want to enforce integer, non-negative constraints.-export const locationSchema = z.object({ +export const locationSchema = z.object({ byteOffset: z.number(), lineNumber: z.number(), column: z.number(), });to
export const locationSchema = z.object({ byteOffset: z.number().int().nonnegative(), lineNumber: z.number().int().min(1), column: z.number().int().min(1), });
22-31: Refine request schema
searchRequestSchemaworks, but you may want to ensurematchesandcontextLinesare integers with sensible bounds:.matches: z.number().int().min(1), .contextLines: z.number().int().min(0).optional(),This will catch invalid floats or negatives early.
33-81: Extract nested schemas for readability
The largesearchResponseSchemais correct but could be easier to maintain if you factored out the file and chunk schemas:const fileNameSchema = z.object({ text: z.string(), matchRanges: z.array(rangeSchema) }); const chunkSchema = z.object({ … }); export const searchResponseSchema = z.object({ zoektStats: …, files: z.array(z.object({ fileName: fileNameSchema, chunks: z.array(chunkSchema), … })), … });This reduces inline nesting and improves discoverability.
83-90: Repository schema is fine
repositorySchemacovers basic repository metadata. Consider adding.nullable()for branches if empty lists should be allowed.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (34)
packages/web/.eslintrc.json(0 hunks)packages/web/package.json(1 hunks)packages/web/src/app/[domain]/browse/[...path]/page.tsx(3 hunks)packages/web/src/app/[domain]/components/fileHeader.tsx(1 hunks)packages/web/src/app/[domain]/components/searchBar/searchSuggestionsBox.tsx(1 hunks)packages/web/src/app/[domain]/components/searchBar/useSuggestionModeAndQuery.ts(1 hunks)packages/web/src/app/[domain]/components/searchBar/useSuggestionsData.ts(5 hunks)packages/web/src/app/[domain]/connections/[id]/page.tsx(0 hunks)packages/web/src/app/[domain]/connections/quickActions.tsx(1 hunks)packages/web/src/app/[domain]/search/components/codePreviewPanel/codePreview.tsx(3 hunks)packages/web/src/app/[domain]/search/components/codePreviewPanel/index.tsx(5 hunks)packages/web/src/app/[domain]/search/components/filterPanel/filter.tsx(0 hunks)packages/web/src/app/[domain]/search/components/filterPanel/index.tsx(6 hunks)packages/web/src/app/[domain]/search/components/searchResultsPanel/codePreview.tsx(3 hunks)packages/web/src/app/[domain]/search/components/searchResultsPanel/fileMatch.tsx(3 hunks)packages/web/src/app/[domain]/search/components/searchResultsPanel/fileMatchContainer.tsx(4 hunks)packages/web/src/app/[domain]/search/components/searchResultsPanel/index.tsx(2 hunks)packages/web/src/app/[domain]/search/page.tsx(7 hunks)packages/web/src/app/api/(client)/client.ts(1 hunks)packages/web/src/app/api/(server)/repos/route.ts(1 hunks)packages/web/src/app/api/(server)/search/route.ts(1 hunks)packages/web/src/app/api/(server)/source/route.ts(1 hunks)packages/web/src/features/entitlements/constants.ts(2 hunks)packages/web/src/features/search/fileSourceApi.ts(1 hunks)packages/web/src/features/search/listReposApi.ts(1 hunks)packages/web/src/features/search/schemas.ts(1 hunks)packages/web/src/features/search/searchApi.ts(1 hunks)packages/web/src/features/search/types.ts(1 hunks)packages/web/src/features/search/zoektSchema.ts(1 hunks)packages/web/src/lib/extensions/searchResultHighlightExtension.ts(2 hunks)packages/web/src/lib/schemas.ts(0 hunks)packages/web/src/lib/server/searchService.ts(0 hunks)packages/web/src/lib/types.ts(1 hunks)packages/web/src/lib/utils.ts(2 hunks)
💤 Files with no reviewable changes (5)
- packages/web/src/app/[domain]/connections/[id]/page.tsx
- packages/web/src/app/[domain]/search/components/filterPanel/filter.tsx
- packages/web/.eslintrc.json
- packages/web/src/lib/server/searchService.ts
- packages/web/src/lib/schemas.ts
🧰 Additional context used
🧬 Code Graph Analysis (8)
packages/web/src/lib/extensions/searchResultHighlightExtension.ts (1)
packages/web/src/features/search/types.ts (1)
SearchResultRange(15-15)
packages/web/src/features/search/listReposApi.ts (4)
packages/web/src/features/search/types.ts (1)
ListRepositoriesResponse(21-21)packages/web/src/lib/serviceError.ts (2)
ServiceError(11-11)invalidZoektResponse(48-65)packages/web/src/features/search/zoektClient.ts (1)
zoektFetch(11-34)packages/web/src/features/search/zoektSchema.ts (1)
zoektListRepositoriesResponseSchema(123-132)
packages/web/src/app/[domain]/search/components/codePreviewPanel/codePreview.tsx (1)
packages/web/src/features/search/types.ts (1)
SearchResultChunk(18-18)
packages/web/src/app/[domain]/search/components/searchResultsPanel/index.tsx (1)
packages/web/src/app/[domain]/search/components/searchResultsPanel/fileMatchContainer.tsx (1)
MAX_MATCHES_TO_PREVIEW(10-10)
packages/web/src/app/[domain]/search/components/searchResultsPanel/fileMatch.tsx (2)
packages/web/src/features/search/types.ts (1)
SearchResultChunk(18-18)packages/web/src/lib/utils.ts (1)
base64Decode(191-194)
packages/web/src/lib/types.ts (1)
packages/web/src/lib/schemas.ts (2)
getVersionResponseSchema(67-69)repositoryQuerySchema(15-29)
packages/web/src/app/[domain]/components/searchBar/useSuggestionsData.ts (2)
packages/web/src/app/[domain]/components/searchBar/searchSuggestionsBox.tsx (1)
Suggestion(22-27)packages/web/src/lib/utils.ts (1)
isServiceError(182-188)
packages/web/src/features/search/types.ts (1)
packages/web/src/features/search/schemas.ts (8)
searchRequestSchema(22-31)searchResponseSchema(33-81)rangeSchema(12-15)locationSchema(3-10)symbolSchema(17-20)listRepositoriesResponseSchema(91-93)fileSourceRequestSchema(95-99)fileSourceResponseSchema(101-104)
🪛 Biome (1.9.4)
packages/web/src/app/[domain]/search/page.tsx
[error] 104-104: Avoid the use of spread (...) syntax on accumulators.
Spread syntax should be avoided on accumulators (like those in .reduce) because it causes a time complexity of O(n^2).
Consider methods such as .splice or .push instead.
(lint/performance/noAccumulatingSpread)
packages/web/src/app/[domain]/components/searchBar/useSuggestionsData.ts
[error] 8-8: Do not shadow the global "Symbol" property.
Consider renaming this variable. It's easy to confuse the origin of variables when they're named after a known global.
(lint/suspicious/noShadowRestrictedNames)
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: build
🔇 Additional comments (78)
packages/web/src/features/entitlements/constants.ts (2)
2-3: ESLint disable for unusedplanLabelsis appropriate
SinceplanLabelsis only leveraged at compile time for itsPlantype and not referenced at runtime, suppressing theno-unused-varsrule here is reasonable.
11-12: ESLint disable for unusedentitlementsis appropriate
Likewise,entitlementsis used solely in a type context (Entitlement) and not at runtime, so the lint suppression is justified.packages/web/src/app/api/(server)/repos/route.ts (1)
3-3: Import path updated forlistRepositories
The refactored import from@/features/search/listReposApialigns with the new feature‐scoped API module. Verify the function signature remains compatible with this route’s usage.packages/web/src/app/[domain]/components/searchBar/searchSuggestionsBox.tsx (1)
278-278: Verify stability ofrefineModeSuggestions
AddingrefineModeSuggestionsto theuseMemodependency array ensures recomputation when it changes. Please confirm thatuseRefineModeSuggestionsreturns a stable (memoized) array; otherwise, each render will trigger the memoized block, negating performance benefits.packages/web/src/app/api/(server)/search/route.ts (2)
3-3: Import path updated forsearch
Switching to the feature‐scoped@/features/search/searchApiis consistent with the refactoring and improves modularity.
8-9: Schema and type imports updated
ThesearchRequestSchemaandSearchRequestare now correctly imported from@/features/search/schemasand@/features/search/types, maintaining consistency and type safety in the new structure.packages/web/src/app/api/(server)/source/route.ts (1)
3-3: Import path updates align with the new feature module structure.The imports have been correctly updated to reference the new paths under the
features/searchdirectory, aligning with the broader refactoring effort to modularize search-related functionality.Also applies to: 8-9
packages/web/src/app/[domain]/components/searchBar/useSuggestionModeAndQuery.ts (1)
72-72: Fixed dependency array to properly react to suggestionModeMappings changes.Adding
suggestionModeMappingsto the dependency array ensures that the memoized values are recalculated when the mappings change, preventing stale data issues in the suggestion mode logic.packages/web/src/lib/extensions/searchResultHighlightExtension.ts (2)
3-3: Updated import path to use new feature module structure.The import for
SearchResultRangehas been correctly updated to reference the new path underfeatures/search/types.
11-13: Property naming convention standardized to camelCase.The property names have been correctly updated from PascalCase to camelCase (
Start→start,End→end,LineNumber→lineNumber,Column→column,ByteOffset→byteOffset), ensuring consistency with the new conventions established in this refactoring.Also applies to: 31-31
packages/web/src/lib/utils.ts (2)
9-10: Imports updated to match new feature module structure.The import for
Repositoryhas been correctly updated to the new path underfeatures/search/types, while keepingRepositoryQueryfrom the existing location. This aligns with the separation of search-specific types into the dedicated feature module.
52-60: Property naming convention standardized to camelCase.Property accesses on the
repoparameter have been updated from PascalCase to camelCase:
RawConfig→rawConfigURL→urlThis ensures consistency with the new camelCase naming conventions established in this refactoring.
packages/web/src/app/[domain]/search/components/searchResultsPanel/codePreview.tsx (2)
5-5: Import path updated to feature-scoped location.The import path has been updated from the general
@/lib/typesto the feature-specific@/features/search/types. This aligns with the broader refactoring to improve code organization through feature-scoped modules.
46-47: Property naming convention changed from PascalCase to camelCase.All property references were updated from PascalCase (e.g.,
Start.ByteOffset,LineNumber) to camelCase (e.g.,start.byteOffset,lineNumber). This change maintains consistent naming conventions across the codebase and aligns with TypeScript best practices.Also applies to: 48-51, 62-68
packages/web/src/app/[domain]/browse/[...path]/page.tsx (3)
4-5: Imports updated to use dedicated API modules.Import paths have been updated to use dedicated API modules (
fileSourceApiandlistReposApi) from the feature-specific directory, improving code organization and modularity.
61-61: Updated repository object access pattern.The repository access pattern has been updated to use the new camelCase properties (
reposandname) instead of the previous PascalCase properties (List.ReposandRepository.Name). This maintains consistency with the new API response structure.
85-85: Updated repo prop to match new data structure.The
repoprop passed to theFileHeadercomponent now uses the direct repository object instead of accessing a nestedRepositoryproperty, aligning with the new flattened data structure.packages/web/src/app/[domain]/search/components/codePreviewPanel/codePreview.tsx (3)
6-6: Updated type import to feature-scoped location.Import updated from the general
@/lib/typesto the feature-specific@/features/search/types, aligning with the broader refactoring effort.
25-25: Type definition updated to match new data structure.The type for
matcheswas changed fromSearchResultFileMatch[]toSearchResultChunk[]to align with the new chunk-based data structure defined in@/features/search/types.
87-87: Property access updated to camelCase naming convention.Access to match ranges has been updated from
match.Rangestomatch.matchRanges, following the camelCase naming convention adopted throughout the codebase.packages/web/src/app/[domain]/search/components/searchResultsPanel/index.tsx (2)
3-3: Types import path updated to feature-scoped location.Import path updated from
@/lib/typesto@/features/search/typesforRepositoryandSearchResultFiletypes, improving code organization through feature-scoped modules.
44-46: Simplified match filtering logic.The code has been simplified to directly slice the
fileMatch.chunksarray instead of using a more complex filtering approach. This makes the code more maintainable and easier to understand while aligning with the new data structure.packages/web/src/app/api/(client)/client.ts (1)
3-18: Import refactoring looks goodThe refactoring of imports to use the new feature-based organization is clean and consistent. Moving search-related types and schemas from
/libto/features/searchfollows good modularization practices and makes the codebase more maintainable.packages/web/src/app/[domain]/search/components/searchResultsPanel/fileMatch.tsx (5)
5-5: Import path update looks goodThe import path has been updated to use the new feature-scoped module structure.
10-10: Prop type updated correctlyThe
matchprop type has been updated to use the newSearchResultChunktype.
20-22: Property access updated to camelCaseThe property access has been correctly updated from
match.Contenttomatch.contentfollowing the new camelCase naming convention.
25-25: Property access updated to camelCaseThe property access has been correctly updated from
match.Rangestomatch.matchRangesfollowing the new camelCase naming convention.
43-45: Property accesses updated to camelCaseThe property accesses have been correctly updated following the new camelCase naming convention:
file.Languagetofile.languagematch.Rangestomatch.matchRangesmatch.ContentStart.LineNumbertomatch.contentStart.lineNumberpackages/web/src/features/search/listReposApi.ts (2)
1-5: Imports look correctThe imports are appropriate for this module, bringing in the necessary error handling utilities, types, and API client.
7-44: Implementation of listRepositories looks goodThe function properly:
- Constructs the request with appropriate parameters and headers
- Handles error responses from the API
- Transforms the response to match the expected schema
- Uses type safety with the
satisfieskeywordThe transformation logic in the parser is clean and handles optional fields appropriately.
packages/web/src/features/search/fileSourceApi.ts (3)
1-6: Imports look correctThe imports are appropriate for this module, bringing in necessary utilities like
escapeStringRegexpfor query safety.
7-9: Good TODO commentThe TODO comment provides valuable context about a better way to implement file content fetching in the future. This will be important for supporting permalinks to specific revisions.
10-42: Implementation of getFileSource looks goodThe function:
- Properly escapes user inputs using
escapeStringRegexpto prevent query injection- Handles optional branch parameter correctly
- Properly handles and forwards service errors
- Returns appropriate errors for file not found cases
- Uses type safety with the
satisfieskeywordThis is a robust implementation that follows security best practices.
packages/web/src/lib/types.ts (3)
2-2: Import path updated to align with code reorganization.The import statement has been simplified to only include schemas that remain in this file, following the migration of search-related schemas to
features/search/schemas.ts.
11-11: Parameter renaming for improved consistency.The
maxMatchDisplayCountparameter was renamed tomatches, making the API more concise while maintaining its semantic meaning.
14-15: Type definitions reorganized.Types now have a more logical layout in the file with
TenancyModeandRepositoryQuerymoved to the bottom, improving code organization.packages/web/src/app/[domain]/search/components/searchResultsPanel/fileMatchContainer.tsx (8)
8-8: Import path updated to use feature-scoped types.The import for
RepositoryandSearchResultFiletypes has been updated to use the new feature-scoped path, aligning with the code reorganization.
35-35: Property access updated to use camelCase.Updated from
ChunkMatches.lengthtochunks.lengthto match the new camelCase naming convention for API responses.
39-40: Property access paths updated to use camelCase.File sorting logic now uses camelCase property paths (
chunks,contentStart.lineNumber) consistent with the new API response schema.
51-56: FileName highlight range logic updated.Logic for determining the file name highlight range now uses the camelCase property paths (
fileName.matchRanges,start.column,end.column), consistent with the schema changes.
60-60: Dependency array updated.Updated the dependency array to use the new property path
file.fileName.matchRangesto ensure proper memoization.
68-68: Property access updated to use camelCase.Updated from
MatchRanges.lengthtomatchRanges.lengthto match the new camelCase naming convention.
75-75: Branch-related property accesses updated.The null check for
file.branchesand its usage in the memoized value calculation have been updated to use camelCase.Also applies to: 79-80
104-105: Repository and fileName properties updated.Updated from
file.Repositorytofile.repositoryand fromfile.FileNametofile.fileName.textto match the new camelCase schema.packages/web/src/app/[domain]/search/components/codePreviewPanel/index.tsx (8)
7-7: Import path updated to use feature-scoped types.The import path for
SearchResultFilehas been updated to use the new feature-scoped directory structure.
29-29: Query key updated to use camelCase properties.The query key array now uses the camelCase property names (
fileName,repository,branches) consistent with the new API response schema.
37-37: Branch extraction logic updated.Branch extraction from
fileMatchnow uses the camelCase property namebranchesconsistent with the schema changes.
40-42: File source fetching parameters updated.Parameters passed to the
fetchFileSourcefunction now use camelCase property paths (fileName.text,repository), consistent with the API schema changes.
46-46: Repository URL template access updated.Access to the repository URL template now uses the camelCase property
repositoryinstead ofRepository.
59-59: Path substitution updated.Path substitution in URL generation now uses the camelCase property path
fileName.textinstead ofFileName.Also applies to: 72-72
81-85: Return object properties updated.The object returned from the query function now uses camelCase property paths (
fileName.text,chunks,language) consistent with the schema changes.
102-102: CodePreview component prop updated.The
repoNameprop passed to theCodePreviewcomponent now uses the camelCase propertyrepositoryinstead ofRepository.packages/web/src/app/[domain]/components/searchBar/useSuggestionsData.ts (8)
43-46: Repository data access pattern updated.The data access pattern for repository suggestions has been updated to use camelCase property
nameinstead of the previous PascalCase property, aligning with the new API response schema.
56-57: Search query parameters updated.The search query parameters now use
matches(previouslymaxMatchDisplayCount) and includecontextLines: 1, aligning with the updated API parameters.
64-66: File data access pattern updated.The data extraction for file suggestions now uses camelCase property paths (
fileName.text) consistent with the schema changes.
76-77: Symbol search query parameters updated.Similar to file search, the symbol search query parameters have been updated to use
matchesandcontextLines: 1.
84-84: Symbol extraction logic updated.The logic to extract symbols from search results has been updated to navigate the new nested structure (files → chunks → symbols) with camelCase property names.
90-90: Symbol map key creation updated.The symbol map key creation now uses camelCase properties (
kind,symbol) consistent with the schema changes.
92-92: Symbol value access updated.The value property in the symbol suggestions now uses the camelCase property
symbolinstead of the previous PascalCase version.
162-162: getSymbolIcon function updated.The switch statement in the
getSymbolIconfunction now uses the camelCase propertykindinstead of the previous PascalCase version.packages/web/src/features/search/searchApi.ts (1)
143-166: Clarify units forzoektStats.duration.
Result.Durationis in nanoseconds, whereas consumers (e.g., telemetry, UI) often expect milliseconds.
Consider normalising here to avoid unit confusion downstream:- zoektStats: { - duration: Result.Duration, + zoektStats: { + durationMs: Math.round(Result.Duration / 1_000_000),and adjust the
SearchResponsetype accordingly.packages/web/src/features/search/zoektSchema.ts (9)
2-2: Import Zod correctly
The import ofzfrom “zod” is appropriate and minimal.
5-12: Validate location schema keys
zoektLocationSchemacorrectly mirrors the Go API’sLocationfields with appropriate types and comments.
14-17: Range schema is accurate
zoektRangeSchemacleanly composes twozoektLocationSchemaobjects forStartandEnd.
43-48: Symbol schema matches API
zoektSymbolSchemacorrectly definesSym,Kind,Parent, andParentKind. Good alignment with the Zoekt API.
51-75: Search response schema structure
zoektSearchResponseSchemaaccurately models the nestedResultobject, including files and their matches. The use of optional fields and.nullable()is appropriate for API variability.
78-87: Repository stats schema is correct
zoektRepoStatsSchemacovers all numeric metrics returned by Zoekt. Types match expected integers.
90-99: Index metadata schema
zoektIndexMetadataSchemacorrectly types versioning and metadata fields. TheLanguageMaprecord is well defined.
103-121: Repository schema completeness
zoektRepositorySchemaincludes all required fields for repository metadata. Use of.nullable()and.optional()aligns with fields that can be absent.
123-132: List repositories response schema
zoektListRepositoriesResponseSchemacorrectly nestsReposandStatsunderList. Matches the Go API’s listing endpoint.packages/web/src/features/search/schemas.ts (6)
1-2: Minimal Zod import
Importing onlyzis clean and follows usual patterns.
12-15: Range schema usage is appropriate
rangeSchemacleanly composes twolocationSchemaentries.
17-20: Symbol schema is minimal
symbolSchemacovers the basic identity of symbols. If you need parent/child hierarchies, you could extend this later.
91-94: List repositories response
listRepositoriesResponseSchemais concise and matches the API response.
95-99: File source request schema
fileSourceRequestSchemais straightforward and correctly typed.
101-104: File source response schema
fileSourceResponseSchemacleanly returns source and language.packages/web/src/features/search/types.ts (2)
1-11: Import of schemas and Zod
Imports are correctly scoped to./schemas. Good separation of concerns.
13-25: Types correctly inferred from schemas
All other types—SearchRequest,SearchResponse,SearchResultRange,SearchResultLocation,SearchResultFile,SearchResultChunk,ListRepositoriesResponse,Repository,FileSourceRequest, andFileSourceResponse—are cleanly inferred and will update automatically with schema changes.
packages/web/src/app/[domain]/components/searchBar/useSuggestionsData.ts
Outdated
Show resolved
Hide resolved
brendan-kellam
changed the title
This PR updates the api surface for
/search, and/reposto use our own schema instead of directly returning the zoekt's schema. The new schemas are very close, with the following minor differences:Some additional things we can do in the future to make the api easier to work with for client:
Summary by CodeRabbit
New Features
Refactor
Bug Fixes
Chores