Conversation
tenkus47
commented
Jun 8, 2026
- Removed the TextSearchItem and TitleSearchResponse types as they were no longer needed.
- Updated the searchTitles function to directly fetch data without checking for minimum title length.
- Adjusted the SourceSelectorSheet component to remove dependency on MIN_TITLE_SEARCH_LENGTH and simplified source selection logic.
- Removed the TextSearchItem and TitleSearchResponse types as they were no longer needed. - Updated the searchTitles function to directly fetch data without checking for minimum title length. - Adjusted the SourceSelectorSheet component to remove dependency on MIN_TITLE_SEARCH_LENGTH and simplified source selection logic.
Confidence Score: 3/5Two independent behavioral regressions — a likely runtime crash when rendering title search results and an unexplained HTTP method change in fetchTextDetails — should be resolved before merging. The direct use of titleData as an array breaks sources.map() if the API still returns a response envelope, causing an immediate crash on the title-search path. Separately, silently flipping fetchTextDetails from GET to POST will return 405 errors if the server route only handles GET. Both regressions sit on active user-facing flows. src/components/api/searchApi.ts (GET→POST change and missing return type) and src/components/ui/molecules/webuddhist-source/SourceSelectorSheet.tsx (unsafe titleData || [] array assumption) both need a second look. Reviews (1): Last reviewed commit: "refactor(searchApi): simplify title sear..." | Re-trigger Greptile |
| const sources = searchOnlyTitles | ||
| ? titleData || [] | ||
| : multilingualData?.sources || []; |
There was a problem hiding this comment.
The
titleData variable holds whatever the API returns — previously it was a TitleSearchResponse wrapper with a .texts array, accessed via titleData?.texts. Now titleData is used directly as if it is an array, but if the /api/v1/texts/title-search endpoint still returns a paginated envelope (e.g. { texts: [...], has_more: ... }), sources will be a plain object. Calling sources.map(...) (line 177) and sources.length === 0 (line 158) will then throw TypeError: sources.map is not a function at runtime. Even if the endpoint now returns a flat array, the function's implicit any return type provides no compile-time guard against future shape regressions.
| const sources = searchOnlyTitles | |
| ? titleData || [] | |
| : multilingualData?.sources || []; | |
| const sources = searchOnlyTitles | |
| ? (Array.isArray(titleData) ? titleData : titleData?.texts ?? []) | |
| : multilingualData?.sources || []; |
| const { data } = await axiosInstance.post(`/api/v1/texts/${textId}/details`, { | ||
| ...(contentId && { content_id: contentId }), | ||
| ...(segmentId && { segment_id: segmentId }), | ||
| direction, | ||
| size, | ||
| }); |
There was a problem hiding this comment.
fetchTextDetails was silently changed from a GET to a POST. A GET → POST switch is a breaking change if the server-side route only handles GET for this endpoint. This will silently fail with a 405 or wrong-method error. The PR description does not mention this change, which makes it easy to miss during review.
| const { data } = await axiosInstance.post(`/api/v1/texts/${textId}/details`, { | |
| ...(contentId && { content_id: contentId }), | |
| ...(segmentId && { segment_id: segmentId }), | |
| direction, | |
| size, | |
| }); | |
| const { data } = await axiosInstance.get(`/api/v1/texts/${textId}/details`, { | |
| params: { | |
| ...(contentId && { content_id: contentId }), | |
| ...(segmentId && { segment_id: segmentId }), | |
| direction, | |
| size, | |
| }, | |
| }); |
| }; | ||
|
|
||
| export type { SearchCommon }; | ||
| export type { SearchCommon }; No newline at end of file |
There was a problem hiding this comment.
Four files in this PR are missing a trailing newline. This will produce noisy diffs in future git operations and typically triggers linter/editor warnings. The same issue appears in
SourceDetail.tsx, SourceSelectorSheet.tsx, and sourceItem.tsx.
| export type { SearchCommon }; | |
| export type { SearchCommon }; |
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!