Conversation
Signed-off-by: Efren Lim <elim@linuxfoundation.org>
Signed-off-by: Efren Lim <elim@linuxfoundation.org>
Signed-off-by: Efren Lim <elim@linuxfoundation.org>
Signed-off-by: Efren Lim <elim@linuxfoundation.org>
Signed-off-by: Efren Lim <elim@linuxfoundation.org>
Signed-off-by: Efren Lim <elim@linuxfoundation.org>
Signed-off-by: Efren Lim <elim@linuxfoundation.org>
Signed-off-by: Efren Lim <elim@linuxfoundation.org>
Signed-off-by: Efren Lim <elim@linuxfoundation.org>
Signed-off-by: Efren Lim <elim@linuxfoundation.org>
Signed-off-by: Efren Lim <elim@linuxfoundation.org>
Signed-off-by: Efren Lim <elim@linuxfoundation.org>
Signed-off-by: Efren Lim <elim@linuxfoundation.org>
Signed-off-by: Efren Lim <elim@linuxfoundation.org>
|
Caution Review failedThe pull request is closed. WalkthroughThis change introduces a new review time visualization feature in the project module. It adds a Vue component section that displays review time data based on pull request size, including a progress bar and loading spinner. New computed properties and error handling using a toast service are implemented. A corresponding TypeScript interface for review time metrics is added, along with a utility function to compute maximum values from chart data. Additionally, the progress bar component and its SCSS styles are updated, and mock data with an API endpoint are provided to serve the new feature. Changes
Sequence Diagram(s)sequenceDiagram
participant C as ReviewTimeComponent
participant F as useFetch
participant A as API Endpoint
participant P as ProgressBar
participant T as ToastService
C->>F: Initiate data fetch with route params
F->>A: Request review time data
A-->>F: Return mock review time data
F-->>C: Provide data with status 'success'
alt Status is Success
C->>P: Render progress bar with computed review times
else Status is Error
C->>T: Trigger error toast notification
end
Suggested reviewers
Poem
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
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 (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🔭 Outside diff range comments (1)
frontend/app/components/modules/project/components/development/contributions-outside-work-hours.vue (1)
119-119: 🛠️ Refactor suggestionIncorrect error message text
The error message refers to "social mentions" but the component is for "contributions outside work hours".
- `Error fetching social mentions: ${error.value?.statusMessage}`, + `Error fetching contributions outside work hours: ${error.value?.statusMessage}`,
🧹 Nitpick comments (8)
frontend/app/components/modules/project/components/development/types/review-time-by-pr.types.ts (1)
1-7: Well-structured interface for review time metricsThe
ReviewTimeByPrIteminterface is clear and follows TypeScript best practices. The properties are descriptively named and appropriately typed for representing review time metrics by PR size.Consider adding JSDoc comments for better documentation:
+/** + * Interface representing review time metrics categorized by PR size + */ export interface ReviewTimeByPrItem { + /** ID used for sorting */ sortId: number; + /** Size category (e.g. "1-100 lines") */ lines: string; + /** Number of PRs in this category */ prCount: number; + /** Average time to review PRs in this category */ averageReviewTime: number; + /** Unit for averageReviewTime (e.g. "hours", "days") */ averageReviewTimeUnit: string; }frontend/app/components/uikit/chart/helpers/chart-helpers.ts (1)
31-32: Useful utility function for chart visualizationThe
getMaxValuefunction is a helpful addition for determining the maximum value in chart data, which is often needed for setting scales or visualization parameters. The implementation efficiently usesreduceand handles undefined values with the nullish coalescing operator.One small improvement would be to add JSDoc comments to document the function's purpose, parameters, and return value:
+/** + * Returns the maximum value from the first element of the values array across all chart data items + * @param data - Array of ChartData objects to analyze + * @returns The maximum value found or 0 if array is empty + */ export const getMaxValue = (data: ChartData[]): number => data // .reduce((max, item) => Math.max(max, item.values[0] ?? 0), 0);frontend/server/api/projects/development/review-time-by-pr-size.get.ts (1)
1-21: Add query parameter handling and error managementThis implementation currently returns static mock data without processing the documented query parameters (project, repository, time-period). While this works for demonstration purposes, real implementation should:
- Extract and validate query parameters from the event handler
- Use those parameters to filter or request appropriate data
- Include error handling for invalid parameters or service failures
import { reviewTimeByPr } from '~~/server/mocks/review-time-by-pr.mock'; /** * Frontend expects the data to be in the following format: * [ * { * sortId: number; * lines: string; * prCount: number; * averageReviewTime: number; * averageReviewTimeUnit: string; * } * ] */ /** * Query params: * - project: string * - repository: string - * - time-period: string // This is isn't defined yet, but we'll add '90d', '1y', '5y' for now + * - time-period: string // This isn't defined yet, but we'll add '90d', '1y', '5y' for now */ -export default defineEventHandler(async () => reviewTimeByPr); +export default defineEventHandler(async (event) => { + try { + const query = getQuery(event); + const { project, repository, 'time-period': timePeriod } = query; + + // TODO: When implementing actual API, use these parameters to fetch the data + // For now, return mock data + + return reviewTimeByPr; + } catch (error) { + console.error('Error fetching review time by PR size:', error); + throw createError({ + statusCode: 500, + statusMessage: 'Failed to fetch review time data' + }); + } +});frontend/app/components/modules/project/components/development/types/merge-lead-time.types.ts (1)
3-16: Define specific string literal types for better type safetyThe interfaces are well-structured, but you could enhance type safety by defining specific string literal types for
unitandchangeTypeinstead of using generic strings.import type { Summary } from '~/components/shared/types/summary.types'; +type TimeUnit = 'days' | 'hours' | 'minutes' | 'seconds'; +type ChangeType = 'positive' | 'negative' | 'neutral'; + export interface MergeLeadTimeItem { value: number; - unit: string; - changeType: string; + unit: TimeUnit; + changeType: ChangeType; } export interface MergeLeadTime { summary: Summary; data: { pickup: MergeLeadTimeItem; review: MergeLeadTimeItem; accepted: MergeLeadTimeItem; prMerged: MergeLeadTimeItem; }; }frontend/server/api/projects/development/merge-lead-time.get.ts (1)
1-44: Implement query parameter handling and error managementSimilar to the review time endpoint, this implementation returns static mock data without processing any query parameters. For a production-ready implementation:
- Extract and validate query parameters
- Add proper error handling
- Fix the typo in the documentation comment
import { mergeLeadTime } from '~~/server/mocks/merge-lead-time.mock'; /** * Frontend expects the data to be in the following format: * { * summary: { * current: number; // current value * previous: number; // previous value * percentageChange: number; // percentage change (return as actual percentage ex: 2.3 percent) * changeValue: number; // change value * periodFrom: string; // period from * periodTo: string; // period to * }, * data: { * pickup: { * value: number; // value * unit: string; // unit * changeType: string; // 'positive' or 'negative' * }, * review: { * value: number; // value * unit: string; // unit * changeType: string; // 'positive' or 'negative' * }, * accepted: { * value: number; // value * unit: string; // unit * changeType: string; // 'positive' or 'negative' * }, * prMerged: { * value: number; // value * unit: string; // unit * changeType: string; // 'positive' or 'negative' * } * } * } */ /** * Query params: * - project: string * - repository: string - * - time-period: string // This is isn't defined yet, but we'll add '90d', '1y', '5y' for now + * - time-period: string // This isn't defined yet, but we'll add '90d', '1y', '5y' for now */ -export default defineEventHandler(async () => mergeLeadTime); +export default defineEventHandler(async (event) => { + try { + const query = getQuery(event); + const { project, repository, 'time-period': timePeriod } = query; + + // TODO: When implementing actual API, use these parameters to fetch the data + // For now, return mock data + + return mergeLeadTime; + } catch (error) { + console.error('Error fetching merge lead time:', error); + throw createError({ + statusCode: 500, + statusMessage: 'Failed to fetch merge lead time data' + }); + } +});frontend/server/mocks/review-time-by-pr.mock.ts (1)
1-37: Mark mock data and consider variable time unitsThe mock data is structured well, but there are a couple of improvements:
- Consider using different time units for different PR sizes - smaller PRs might be measured in hours or minutes rather than days
- Add a comment indicating this is mock data for development/testing purposes
+/** + * Mock data for review time by PR size + * This data is for development/testing purposes only and will be replaced by actual API data + */ export const reviewTimeByPr = [ { sortId: 1, lines: '1-9', prCount: 1000, - averageReviewTime: 9.86, - averageReviewTimeUnit: 'days' + averageReviewTime: 236.64, + averageReviewTimeUnit: 'hours' }, { sortId: 2, lines: '10-59', prCount: 1200, - averageReviewTime: 20.96, - averageReviewTimeUnit: 'days' + averageReviewTime: 503.04, + averageReviewTimeUnit: 'hours' }, { sortId: 3, lines: '60-99', prCount: 1100, averageReviewTime: 31.32, averageReviewTimeUnit: 'days' }, { sortId: 4, lines: '100-499', prCount: 1300, averageReviewTime: 42.07, averageReviewTimeUnit: 'days' }, { sortId: 5, lines: '500+', prCount: 900, averageReviewTime: 55.9, averageReviewTimeUnit: 'days' } ];Are the review times realistic? Waiting 9.86 days on average for a small PR with 1-9 lines seems excessive. Consider reviewing these values with the product team to ensure they represent realistic metrics for your development workflow.
frontend/app/components/modules/project/components/development/fragments/merge-lead-item.vue (1)
3-8: Consider extracting magic values to CSS variables.The timeline connector implementation uses hard-coded values like
-top-6,h-6,-ml-[1px]which could make future adjustments challenging.Consider extracting these values to CSS variables for better maintainability:
- <span class="absolute -top-6 left-[50%] h-6 border-l border-neutral-300 border-dashed -ml-[1px]" /> + <span class="absolute -top-6 left-[50%] h-6 border-l border-neutral-300 border-dashed connector-offset" />And define in a style block:
<style scoped> .connector-offset { margin-left: -1px; } </style>frontend/app/components/modules/project/components/development/review-time-by-pull-request-size.vue (1)
68-77: Correct the error message.
The string “Error fetching social mentions” is likely a leftover. Change it to align with the actual API request, for clarity:- `Error fetching social mentions: ${error.value?.statusMessage}`, + `Error fetching review-time-by-pr-size: ${error.value?.statusMessage}`,
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (15)
frontend/app/components/modules/project/components/development/contributions-outside-work-hours.vue(1 hunks)frontend/app/components/modules/project/components/development/fragments/merge-lead-item.vue(1 hunks)frontend/app/components/modules/project/components/development/merge-lead-time.vue(1 hunks)frontend/app/components/modules/project/components/development/review-time-by-pull-request-size.vue(1 hunks)frontend/app/components/modules/project/components/development/types/merge-lead-time.types.ts(1 hunks)frontend/app/components/modules/project/components/development/types/review-time-by-pr.types.ts(1 hunks)frontend/app/components/uikit/chart/helpers/chart-helpers.ts(1 hunks)frontend/app/components/uikit/delta-display/delta-display.vue(2 hunks)frontend/app/components/uikit/delta-display/types/delta-display.types.ts(1 hunks)frontend/app/components/uikit/progress-bar/progress-bar.scss(1 hunks)frontend/app/components/uikit/progress-bar/progress-bar.vue(2 hunks)frontend/server/api/projects/development/merge-lead-time.get.ts(1 hunks)frontend/server/api/projects/development/review-time-by-pr-size.get.ts(1 hunks)frontend/server/mocks/merge-lead-time.mock.ts(1 hunks)frontend/server/mocks/review-time-by-pr.mock.ts(1 hunks)
✅ Files skipped from review due to trivial changes (1)
- frontend/server/mocks/merge-lead-time.mock.ts
🔇 Additional comments (30)
frontend/app/components/uikit/delta-display/types/delta-display.types.ts (1)
12-12: Nice addition of the unit propertyAdding the optional
unitproperty toDeltaDisplayPropsis a good enhancement that increases the component's flexibility. This allows for explicit unit display alongside delta values.frontend/app/components/modules/project/components/development/contributions-outside-work-hours.vue (1)
15-17: Good utilization of the new unit propertyThe addition of
unit="%"to thelfx-delta-displaycomponent correctly implements the newly added property from the DeltaDisplayProps type, making the percentage unit explicit in the display.frontend/app/components/uikit/progress-bar/progress-bar.scss (3)
2-2: Good refactoring of flex properties.The change from
items-stretch justify-betweentoitems-center gap-0.5improves the vertical alignment of elements and adds a consistent gap between progress segments.
4-6: Proper dimension separation.Moving the height specification from the parent to the child elements improves the component's flexibility. This change allows the container to focus on layout while child elements control their own dimensions.
8-9: Well-structured label styling.The new label class follows the project's design system conventions with appropriate text size, color, and spacing. The
whitespace-nowrapproperty prevents awkward label wrapping.frontend/app/components/modules/project/components/development/fragments/merge-lead-item.vue (3)
1-20: Well-structured timeline visualization.The component creates an effective timeline visualization with good spacing, conditional connectors, and clear information hierarchy. The layout is responsive and properly aligns all elements.
14-18: Good dynamic styling based on change type.The value indicator effectively uses color coding and icons to communicate positive or negative changes, enhancing user comprehension at a glance.
26-37: Well-defined props with TypeScript.The component uses proper TypeScript prop definitions with appropriate defaults. This ensures type safety and clear documentation of the component's API.
frontend/app/components/uikit/progress-bar/progress-bar.vue (2)
7-8: Good enhancement of the progress bar component.The addition of optional label display and the ability to hide the empty portion makes this component more versatile. The conditional rendering is implemented correctly.
20-21: Well-defined props with appropriate defaults.The new props are properly typed and have sensible default values. Making the label undefined by default ensures backward compatibility with existing uses of the component.
Also applies to: 24-26
frontend/app/components/uikit/delta-display/delta-display.vue (4)
2-2: Simplified flex container.Removing the gap-1 class simplifies the layout while maintaining the component's structure.
8-12: Good refactoring of display logic.Moving the formatting logic into computed properties rather than having it inline in the template improves readability and maintainability. The template is now cleaner and more focused on structure.
38-43: Well-implemented delta display formatting.The computed property correctly handles the unit display and respects the percentageOnly setting. The formatting is consistent with the component's existing behavior.
45-50: Effective previous value formatting.The computed property properly formats the previous value with the optional unit and respects the hidePreviousValue flag. This makes the component more versatile while maintaining backward compatibility.
frontend/app/components/modules/project/components/development/review-time-by-pull-request-size.vue (6)
6-6: No issues with the paragraph styling.
The added margin bottom class is appropriate, and the text content appears correct.
10-12: Horizontal rule and layout block look fine.
The<hr>and new section markup improve visual separation and structure.
33-41: Imports are properly organized.
All imported modules are relevant and properly namespaced.
42-49: Prop definitions appear correct.
DefaultingtimePeriodto'90d'is a sensible initialization.
51-54: Toast and route usage looks fine.
The references to the toast service and route parameters are coherent.
55-66: Fetch logic is consistent.
The query parameters match the expected endpoint usage, aligning project context and time period.frontend/app/components/modules/project/components/development/merge-lead-time.vue (10)
6-6: Paragraph styling change is acceptable.
The margin bottom class helps spacing. No issues noted.
10-12: Enhanced layout with<hr>and section block is fine.
Separating content visually and structurally is a good practice.
13-15: Displaying days with formatted number is reasonable.
This straightforward approach to showing the summary’s current value is clear.
17-27: Merge lead time items for pickup, review, and accepted look good.
Clean layout and descriptive naming for each stage.
39-49: Imports and helper functions are used correctly.
All imports (e.g.,formatNumber,LfxMergeLeadItem) are relevant and properly instantiated.
51-58: Props handling is correct.
Using'90d'as a default time period remains consistent with other components.
60-63: Toast service and route usage is standard.
No issues spotted in referencing these for user feedback and dynamic routing.
64-67: Fetch call is coherent.
The query string parameters match the expected usage in the backend.
69-71: Computed properties for mergeLeadTime and summary are well-defined.
They neatly parse the fetched data.
73-82: Error watcher is accurate.
The toast message properly reflects a fetching issue for “merge lead time.”
| <div v-if="status === 'success'" class="flex flex-col gap-8 text-neutral-900 text-sm"> | ||
| <div v-for="item in reviewTimeByPr" :key="item.sortId" class="flex flex-col gap-2"> | ||
| <div class="flex flex-row gap-2"> | ||
| <span>{{ item.lines }} lines</span> | ||
| <span class="text-neutral-400">{{ item.prCount }} pull requests</span> | ||
| </div> | ||
| <div class="pr-4"> | ||
| <lfx-progress-bar | ||
| :values="[item.averageReviewTime / maxValue * 100]" | ||
| :label="`${item.averageReviewTime} ${item.averageReviewTimeUnit}`" hide-empty /> | ||
| </div> | ||
| </div> | ||
| </div> | ||
| <lfx-spinner v-else /> |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Handle empty array scenarios to avoid potential division by zero.
If reviewTimeByPr is empty, maxValue becomes -Infinity, leading to invalid progress bar values. Consider a fallback for empty data:
-const maxValue = computed(() => Math.max(...reviewTimeByPr.value.map((item) => item.averageReviewTime)));
+const maxValue = computed(() => {
+ if (!reviewTimeByPr.value?.length) {
+ return 1; // fallback
+ }
+ return Math.max(...reviewTimeByPr.value.map((item) => item.averageReviewTime));
+});| <lfx-merge-lead-item | ||
| title="Merged" description="" icon="thumbs-up" :item-value="mergeLeadTime.data.pickup" | ||
| is-last /> |
There was a problem hiding this comment.
"Merged" item references the wrong data property.
Using mergeLeadTime.data.pickup here appears incorrect. Likely intended to use a merged property.
- :item-value="mergeLeadTime.data.pickup"
+ :item-value="mergeLeadTime.data.prMerged"📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| <lfx-merge-lead-item | |
| title="Merged" description="" icon="thumbs-up" :item-value="mergeLeadTime.data.pickup" | |
| is-last /> | |
| <lfx-merge-lead-item | |
| title="Merged" description="" icon="thumbs-up" :item-value="mergeLeadTime.data.prMerged" | |
| is-last /> |
Signed-off-by: Efren Lim <elim@linuxfoundation.org>
There was a problem hiding this comment.
Actionable comments posted: 3
♻️ Duplicate comments (1)
frontend/app/components/modules/project/components/development/review-time-by-pull-request-size.vue (1)
75-75:⚠️ Potential issueHandle empty array scenarios to avoid potential division by zero.
If
reviewTimeByPris empty,maxValuebecomes-Infinity, leading to invalid progress bar values. Consider adding a fallback for empty data.-const maxValue = computed(() => Math.max(...reviewTimeByPr.value.map((item) => item.averageReviewTime))); +const maxValue = computed(() => { + if (!reviewTimeByPr.value?.length) { + return 1; // fallback + } + return Math.max(...reviewTimeByPr.value.map((item) => item.averageReviewTime)); +});
🧹 Nitpick comments (3)
frontend/server/api/project/[slug]/development/review-time-by-pr-size.get.ts (1)
21-21: Consider using the documented query parameters in the handler.While the current implementation returns mock data without any filtering, the documentation indicates that query parameters like 'project', 'repository', and 'time-period' are expected. In a real implementation, these parameters should be used to filter the data.
-export default defineEventHandler(async () => reviewTimeByPr); +export default defineEventHandler(async (event) => { + const query = getQuery(event); + // In a real implementation, we would use the query parameters to filter the data + // For now, just return the mock data + return reviewTimeByPr; +});frontend/app/components/modules/project/components/development/review-time-by-pull-request-size.vue (2)
27-31: Consider adding aria-label for accessibility.The progress bar component would benefit from an aria-label to improve accessibility for screen readers. This helps users understand what the progress bar represents.
<lfx-progress-bar :values="[item.averageReviewTime / maxValue * 100]" :label="`${item.averageReviewTime} ${item.averageReviewTimeUnit}`" hide-empty + :aria-label="`Average review time: ${item.averageReviewTime} ${item.averageReviewTimeUnit} for pull requests with ${item.lines} lines`" />
28-28: Ensure proper number formatting in the progress bar.The calculation
item.averageReviewTime / maxValue * 100might result in floating-point values with many decimal places. Consider rounding the result to enhance readability.- :values="[item.averageReviewTime / maxValue * 100]" + :values="[Math.round((item.averageReviewTime / maxValue * 100) * 10) / 10]"
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
frontend/app/components/modules/project/components/development/review-time-by-pull-request-size.vue(1 hunks)frontend/app/components/uikit/progress-bar/progress-bar.vue(2 hunks)frontend/server/api/project/[slug]/development/review-time-by-pr-size.get.ts(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- frontend/app/components/uikit/progress-bar/progress-bar.vue
🔇 Additional comments (2)
frontend/server/api/project/[slug]/development/review-time-by-pr-size.get.ts (2)
1-1: Looks good!Correctly importing the mock data for review time by PR size. The mock import is properly structured and follows the project's import pattern.
3-20: Excellent documentation!The JSDoc comments are comprehensive and clearly document both the expected data format and query parameters that the endpoint accepts. This is helpful for other developers who will be working with this API.
| <p class="text-body-2 text-neutral-500 mb-6"> | ||
| Active contributor is an individual performing tasks such as commits, | ||
| issues, or pull requests during the selected time period. | ||
| </p> |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Update description to match component purpose.
The current description discusses "active contributors" which doesn't align with the component's purpose of displaying review time by pull request size. Consider updating the text to describe what this widget actually shows.
- <p class="text-body-2 text-neutral-500 mb-6">
- Active contributor is an individual performing tasks such as commits,
- issues, or pull requests during the selected time period.
- </p>
+ <p class="text-body-2 text-neutral-500 mb-6">
+ This chart shows the average review time for pull requests grouped by size (number of lines).
+ Longer bars indicate longer review times for that size category.
+ </p>📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| <p class="text-body-2 text-neutral-500 mb-6"> | |
| Active contributor is an individual performing tasks such as commits, | |
| issues, or pull requests during the selected time period. | |
| </p> | |
| <p class="text-body-2 text-neutral-500 mb-6"> | |
| This chart shows the average review time for pull requests grouped by size (number of lines). | |
| Longer bars indicate longer review times for that size category. | |
| </p> |
| showToast( | ||
| `Error fetching social mentions: ${error.value?.statusMessage}`, | ||
| ToastTypesEnum.negative, |
There was a problem hiding this comment.
Fix incorrect error message text.
The error message mentions "social mentions" which doesn't match this component's purpose of displaying review times by pull request size. Update the message to be contextually correct.
showToast(
- `Error fetching social mentions: ${error.value?.statusMessage}`,
+ `Error fetching review time data: ${error.value?.statusMessage}`,
ToastTypesEnum.negative,📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| showToast( | |
| `Error fetching social mentions: ${error.value?.statusMessage}`, | |
| ToastTypesEnum.negative, | |
| showToast( | |
| `Error fetching review time data: ${error.value?.statusMessage}`, | |
| ToastTypesEnum.negative, |
| const { data, status, error } = useFetch( | ||
| () => '/api/projects/development/review-time-by-pr-size', | ||
| { | ||
| params: { | ||
| project: route.params.slug, | ||
| repository: route.params.name || '', | ||
| 'time-period': props.timePeriod | ||
| } | ||
| } | ||
| ); |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Verify API endpoint path.
The API endpoint path in useFetch doesn't match the file structure of the API endpoint. The endpoint file is at /api/project/[slug]/development/review-time-by-pr-size.get.ts, but the fetch URL is /api/projects/development/review-time-by-pr-size. Ensure that these paths are aligned.
🏁 Script executed:
#!/bin/bash
# Verify that the API route is correctly registered with Nuxt
# and that it's accessible with the URL specified in useFetch
# Find the API endpoint file from the repository
echo "Checking for API endpoint file:"
fd "review-time-by-pr-size.get.ts" --type file
# Check the server routes configuration to see how the API is exposed
echo "Checking Nuxt server routes configuration:"
fd "server" --type directory
fd "routes.ts|nitro.config.ts" --type file
# Check for related URL references in frontend code
echo "Checking useFetch URLs in frontend code:"
rg "useFetch.*review-time-by-pr-size" --type vueLength of output: 599
Mismatch in API Endpoint Path Detected
The API file is located at:
frontend/server/api/project/[slug]/development/review-time-by-pr-size.get.ts
However, the useFetch call is using:
/api/projects/development/review-time-by-pr-size
Action Required:
- Update the fetch URL to correctly reference the singular path and include the dynamic
[slug]parameter. For example:const { data, status, error } = useFetch( () => `/api/project/${route.params.slug}/development/review-time-by-pr-size`, { params: { repository: route.params.name || '', 'time-period': props.timePeriod } } );
- Verify that this new URL aligns with the intended Nuxt routing conventions.
Signed-off-by: Efren Lim <elim@linuxfoundation.org>
2 participants
Merge PR: #55 first!
In this PR:
Ticket
INS-110
Summary by CodeRabbit
New Features
Styling