refactor(events): replace month-based filtering with DateRangePicker #6353
Conversation
|
No significant changes currently retry |
Our Pull Request Approval ProcessThis PR will be reviewed according to our: Your PR may be automatically closed if:
Thanks for contributing! |
WalkthroughReplaces month/year controls with a DateRangePicker-driven Changes
Sequence Diagram(s)sequenceDiagram
actor User
participant DateRangePicker
participant EventsComponent
participant ApolloClient
participant GraphQLServer
participant EventCalendar
User->>DateRangePicker: select preset or set start/end dates
DateRangePicker->>EventsComponent: set dateRange(startDate, endDate)
EventsComponent->>EventsComponent: computeCalendarFromStartDate(startDate)
EventsComponent->>ApolloClient: query events with startDate/endDate
ApolloClient->>GraphQLServer: execute query
GraphQLServer-->>ApolloClient: return events
ApolloClient-->>EventsComponent: deliver results
EventsComponent->>EventCalendar: render with calendarMonth/calendarYear and events
EventCalendar-->>User: display updated calendar
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Caution Pre-merge checks failedPlease resolve all errors before merging. Addressing warnings is optional.
❌ Failed checks (2 errors, 1 warning, 1 inconclusive)
✅ Passed checks (4 passed)
✨ 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. Comment |
![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
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/screens/UserPortal/Events/Events.tsx (1)
1-45: Update TSDoc to reflect refactored implementation.The TSDoc comment is outdated and must be updated to accurately describe the component:
- Line 2: Still refers to
`events`(lowercase) but the function is nowEvents(capitalized).- Lines 18-19: Documents state variables
startAt,endAtthat no longer exist; they have been replaced bydateRange.- Missing documentation: The new
dateRangestate andDateRangePickerintegration are not mentioned.- Lines 92-100: The computed
calendarMonthandcalendarYearvalues are not documented.As per coding guidelines (§4 Documentation & Comments) and retrieved learnings, TSDoc on exported components must be accurate and complete.
📝 Proposed TSDoc updates
/** - * The `events` component is responsible for managing and displaying events for a user portal. + * The `Events` component is responsible for managing and displaying events for a user portal. * It includes functionality for creating, viewing, and managing events within an organization. * * @remarks * - Utilizes Apollo Client for GraphQL queries and mutations. * - Integrates with `react-bootstrap` for UI components and modals. * - Uses `dayjs` for date and time manipulation. * - Includes localization support via `react-i18next`. * * Dependencies: * - `EventCalendar`: Displays events in a calendar view. * - `EventHeader`: Provides controls for calendar view and event creation. - * - `DatePicker` and `TimePicker`: Used for selecting event dates and times. + * - `DateRangePicker`: Used for selecting arbitrary event date ranges. + * - `EventForm`: Form component for event creation with validation. * * State: - * - `events`: List of events fetched from the server. - * - `eventTitle`, `eventDescription`, `eventLocation`: Input fields for event details. - * - `startAt`, `endAt`: Start and end dates for the event. - * - `startTime`, `endTime`: Start and end times for the event. - * - `isPublic`, `isRegisterable`, `isRecurring`, `isAllDay`: Event configuration flags. + * - `dateRange`: Selected date range with `startDate` and `endDate` controlling event queries. * - `viewType`: Current calendar view type (e.g., month, week). * - `createEventModal`: Controls visibility of the event creation modal. - * - `createChatCheck`: Determines if a chat should be created for the event. + * - `formResetKey`: Key used to reset the event form after successful creation. + * + * Computed Values: + * - `calendarMonth`: Derived from `dateRange.startDate` for calendar display. + * - `calendarYear`: Derived from `dateRange.startDate` for calendar display. * * Methods: - * - `createEvent`: Handles the creation of a new event by submitting a GraphQL mutation. + * - `handleCreateEvent`: Handles the creation of a new event by submitting a GraphQL mutation. * - `toggleCreateEventModal`: Toggles the visibility of the event creation modal. - * - `handleEventTitleChange`, `handleEventLocationChange`, `handleEventDescriptionChange`: - * Update respective state variables when input fields change. + * - `showInviteModal`: Opens the event creation modal. * - `handleChangeView`: Updates the calendar view type. * * Hooks: * - `useQuery`: Fetches events and organization details. * - `useMutation`: Executes the event creation mutation. * - `useLocalStorage`: Retrieves user details from local storage. - * - `useEffect`: Updates the event list when query data changes. + * - `useEffect`: Handles error logging for event query failures (rate-limit aware). * * @returns The rendered events component. * * @example * ```tsx * <Events /> * ``` */
🤖 Fix all issues with AI agents
In @src/screens/UserPortal/Events/Events.spec.tsx:
- Around line 1618-1622: The test contains an unnecessary blind await wait() at
the end of the spec (after the waitFor that asserts calendar-view-type text), so
either remove that await wait() entirely or replace it with a targeted
waitFor/assertion that verifies the actual condition you relied on; if the blank
wait is truly required for flakiness, add a concise comment above the await
wait() explaining why the delay is needed so future readers know it’s
intentional.
- Around line 1727-1729: The test creates an InMemoryCache with addTypename:
false which deviates from other tests; either add a brief inline comment above
the cache instantiation in the CREATOR_NULL_MOCKS test explaining why typename
addition must be disabled for this scenario (e.g., to match mocked responses
that omit __typename) or remove the addTypename: false option to use the default
cache behavior so the test is consistent with the rest of the suite; locate the
InMemoryCache instantiation referenced as InMemoryCache({ addTypename: false })
in the CREATOR_NULL_MOCKS test and apply one of these two changes.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
⛔ Files ignored due to path filters (1)
docs/docs/auto-docs/screens/UserPortal/Events/Events/functions/default.mdis excluded by!**/docs/docs/**
📒 Files selected for processing (2)
src/screens/UserPortal/Events/Events.spec.tsxsrc/screens/UserPortal/Events/Events.tsx
🧰 Additional context used
📓 Path-based instructions (3)
**/*.{ts,tsx}
📄 CodeRabbit inference engine (Custom checks)
Zero TypeScript errors: Run pnpm run typecheck and must pass without errors or warnings
Files:
src/screens/UserPortal/Events/Events.tsxsrc/screens/UserPortal/Events/Events.spec.tsx
**/*
⚙️ CodeRabbit configuration file
**/*: Conduct a comprehensive review and reevaluate all resolved and dismissed items.VALIDATION FRAMEWORK
1. Test Coverage & Quality
1.1 Test File Requirements
For each modified source file with logic or UI:
- ✅ Test file exists:
*.spec.tsx,*.spec.ts,*.test.tsx, or*.test.ts- ✅ Test file colocated with component (same directory)
- ✅ Test file updated to reflect source changes
- ✅ Target ≥95% code coverage for new/modified code
- ✅ List specific line numbers lacking test coverage
1.2 Test Quality Standards
✅ Framework Compliance (Vitest + React Testing Library):
- Use
vi.mock()for mocking (notjest.mock())- Use
describe(),it(),test()for structure- Use
@testing-library/reactqueries (getByRole, getByText, etc.)- Use
@testing-library/user-eventfor interactions✅ Coverage Completeness - All scenarios tested:
- Success paths with valid data
- Error scenarios (network failures, GraphQL errors, validation errors)
- Edge cases (empty data, null/undefined, boundary values)
- Loading and pending states
- User interactions and state changes
✅ Mock Quality:
- GraphQL:
MockedProviderorStaticMockLink- Realistic, comprehensive mock data
- Proper cleanup (reset mocks, clear timers)
✅ Test Structure:
- Isolated tests (no execution order dependency)
- No disabled tests (
*.skip) without documented reason + linked issue- Proper async utilities (
waitFor,act)- Shard-compatible (12-shard strategy, no shared state, <30s timeout)
2. Code Quality & Implementation
2.1 TypeScript Standards
- ✅ No
anytype without JSDoc justification- ✅ Proper typing for:
- Component props (interface declarations)
- Function parameters and return types
- GraphQL variables and responses
- State and context
- ✅ No
@ts-ignorewithout explanation- ✅ Zero TypeScript compilation errors
2.2 React & GraphQL Implementation
- ✅ React Best Practices:
- Fu...
Files:
src/screens/UserPortal/Events/Events.tsxsrc/screens/UserPortal/Events/Events.spec.tsx
**/*.{test,spec}.{ts,tsx}
📄 CodeRabbit inference engine (Custom checks)
Test coverage must be ≥95% for modified files. Run: pnpm run test:coverage and verify coverage/coverage-summary.json shows no files below threshold
Files:
src/screens/UserPortal/Events/Events.spec.tsx
🧠 Learnings (7)
📚 Learning: 2025-12-26T20:34:53.912Z
Learnt from: MuhammadUmar7195
Repo: PalisadoesFoundation/talawa-admin PR: 5847
File: src/screens/UserPortal/Volunteer/Invitations/Invitations.tsx:243-243
Timestamp: 2025-12-26T20:34:53.912Z
Learning: In PalisadoesFoundation/talawa-admin, whenever you modify a file (e.g., for migrations, tests, or feature changes), replace inline color attributes like color="grey" with Bootstrap utility classes (e.g., className="text-secondary") to satisfy the CSS-Policy-Check CI. This is a general compliance guideline, not scope creep, and should be applied to all affected TSX files during reviews. Steps: 1) Find inline color attributes in JSX/TSX. 2) Replace with appropriate Bootstrap text/color utility classes. 3) Ensure the visual outcome remains the same. 4) Run CI checks to confirm the policy passes.
Applied to files:
src/screens/UserPortal/Events/Events.tsxsrc/screens/UserPortal/Events/Events.spec.tsx
📚 Learning: 2026-01-06T16:39:41.033Z
Learnt from: Jashan32
Repo: PalisadoesFoundation/talawa-admin PR: 6199
File: src/shared-components/ProfileForm/ProfileForm.tsx:0-0
Timestamp: 2026-01-06T16:39:41.033Z
Learning: When refactoring or consolidating components (e.g., talawa-admin), remove helper functions that were copied from old files but are not used in the new implementation. Before exporting utilities, verify there are real usages across the codebase (search usages, remove dead code, and keep only necessary exports) to improve maintainability and reduce bundle size.
Applied to files:
src/screens/UserPortal/Events/Events.tsxsrc/screens/UserPortal/Events/Events.spec.tsx
📚 Learning: 2026-01-07T09:08:09.150Z
Learnt from: adityai0
Repo: PalisadoesFoundation/talawa-admin PR: 6202
File: src/components/EventManagement/EventAgendaItems/EventAgendaItems.tsx:4-13
Timestamp: 2026-01-07T09:08:09.150Z
Learning: In the talawa-admin repository, document comments with TSDoc in all TSX files. Do not use JSDoc. Write non-standard tags like component and requires as plain text (no leading @). Use standard TSDoc tags such as param, remarks, returns, and example with the leading @. This guideline applies to all TSX components (e.g., src/components/.../*.tsx).
Applied to files:
src/screens/UserPortal/Events/Events.tsxsrc/screens/UserPortal/Events/Events.spec.tsx
📚 Learning: 2025-12-21T08:59:37.942Z
Learnt from: rawadhossain
Repo: PalisadoesFoundation/talawa-admin PR: 5287
File: src/shared-components/Recurrence/CustomRecurrenceModal.spec.tsx:78-84
Timestamp: 2025-12-21T08:59:37.942Z
Learning: In talawa-admin test files, ensure each spec file uses an explicit vi.clearAllMocks() in an afterEach block to guarantee test isolation. This should be present even if a global cleanup exists in vitest.setup.ts, as the linter enforces per-file hygiene. Apply this guideline to all spec files (e.g., src/**/*.spec.tsx) to satisfy ESLint/Vitest requirements and prevent bleed-over between tests.
Applied to files:
src/screens/UserPortal/Events/Events.spec.tsx
📚 Learning: 2025-12-27T11:22:41.191Z
Learnt from: rawadhossain
Repo: PalisadoesFoundation/talawa-admin PR: 5782
File: src/screens/Leaderboard/Leaderboard.spec.tsx:342-370
Timestamp: 2025-12-27T11:22:41.191Z
Learning: In test files that render screens with shared components (e.g., src/screens/Leaderboard/Leaderboard.spec.tsx), verify integration behavior by asserting the screen renders correctly in different scenarios (e.g., search results) without asserting the internal ARIA attributes, text, or icons of the shared component. Rely on the shared component's own tests to cover accessibility and presentation details. This keeps tests focused on higher-level behavior and interactions.
Applied to files:
src/screens/UserPortal/Events/Events.spec.tsx
📚 Learning: 2026-01-08T18:48:10.364Z
Learnt from: abhishekblue
Repo: PalisadoesFoundation/talawa-admin PR: 6260
File: src/screens/AdminPortal/OrganizationPeople/OrganizationPeople.spec.tsx:337-339
Timestamp: 2026-01-08T18:48:10.364Z
Learning: In tests that exercise Apollo Client queries (e.g., talawa-admin tests under src/screens/.../OrganizationPeople.spec.tsx), avoid using vi.useFakeTimers() because Apollo's internal promise resolution can be disrupted by mocked timers, causing timeouts. Use real timers with explicit waits (for example, await act(async () => { await new Promise(r => setTimeout(r, DURATION)); })) when testing components that fetch data via Apollo. If you must use timers, prefer real timers for the relevant test and flush promises deterministically. Replace or remove useFakeTimers in such tests and rely on actual time passage or proper promise flushing to ensure reliable Apollo-driven data fetching tests.
Applied to files:
src/screens/UserPortal/Events/Events.spec.tsx
📚 Learning: 2025-12-27T11:22:19.556Z
Learnt from: rawadhossain
Repo: PalisadoesFoundation/talawa-admin PR: 5782
File: src/screens/Leaderboard/Leaderboard.spec.tsx:299-329
Timestamp: 2025-12-27T11:22:19.556Z
Learning: In talawa-admin test files (e.g., src/screens/Leaderboard/Leaderboard.spec.tsx), prefer separate explicit test cases for keyboard navigation interactions (Enter key, Space key) instead of consolidating them with test.each()/parameterization. This improves readability, documents each keyboard interaction path clearly, and makes failures easier to diagnose when specific key handling regresses. Apply this pattern to similarly structured spec files by keeping individual tests for each key interaction rather than combining them into a single parameterized test.
Applied to files:
src/screens/UserPortal/Events/Events.spec.tsx
🧬 Code graph analysis (2)
src/screens/UserPortal/Events/Events.tsx (1)
src/shared-components/DateRangePicker/DateRangePicker.tsx (1)
DateRangePicker(74-231)
src/screens/UserPortal/Events/Events.spec.tsx (1)
src/GraphQl/Queries/Queries.ts (1)
GET_ORGANIZATION_EVENTS_USER_PORTAL_PG(596-667)
🔇 Additional comments (9)
src/screens/UserPortal/Events/Events.spec.tsx (3)
646-712: LGTM: Dynamic mock dates align with DateRangePicker logic.The refactored
CREATOR_NULL_MOCKSnow computesmockStartDateandmockEndDatedynamically usingdayjs().startOf('month')anddayjs().endOf('month'), matching the date range logic introduced in the source component. The mock properly extends the event node with anorganizationfield and tests the fallback behavior whencreatorisnull.
1046-1049: LGTM: Migrated to data-testid selectors for reliability.Tests now use
data-testidattributes (eventStartAt,eventEndAt) instead of label-based queries for date inputs. This approach is more reliable and aligns with testing best practices, as it decouples tests from label text changes and reduces brittleness.Also applies to: 1268-1274, 1288-1289, 1372-1378, 1390-1390
1746-1758: LGTM: Proper testing of creator fallback with explicit timeout.The test correctly verifies that when
creatorisnull, the event data mapping applies the fallback{ id: '', name: '' }. The use ofwaitForwith an explicit 5-second timeout ensures the test waits for the EventCalendar mock to render the JSON data. The JSON parsing approach is appropriate for verifying the data passed to the calendar component.src/screens/UserPortal/Events/Events.tsx (6)
73-73: LGTM: DateRangePicker integration follows correct patterns.The
DateRangePickeris imported fromshared-components/DateRangePicker/DateRangePicker(Line 73) following the correct import pattern. The component usage (Lines 287-292) properly bindsvalue={dateRange}andonChange={setDateRange}with appropriate props for presets and test IDs.Also applies to: 287-292
75-75: LGTM: Function name follows PascalCase convention.The function name is correctly capitalized to
Events(wasevents), following the proper naming convention for React components. Note that the TSDoc at the top of the file (Line 2) still refers to the lowercaseeventsand needs updating.
84-100: LGTM: Proper state management with computed calendar values.The
dateRangestate (Lines 84-90) is correctly typed withDate | nulland initialized to the current month boundaries. The computedcalendarMonthandcalendarYear(Lines 92-100) useReact.useMemowith proper dependencies (dateRange.startDate) and provide sensible fallbacks when the date isnull.
112-117: LGTM: Query variables correctly handle nullable date ranges.The GraphQL query variables now derive
startAtandendAtfromdateRange.startDateanddateRange.endDate, normalizing them to day boundaries withstartOf('day')andendOf('day'). The ternary operators correctly handlenulldates, matching the PR objective to support arbitrary date ranges.
250-250: LGTM: Correct useEffect dependency array.Adding
tto the dependency array ensures the effect re-runs if the translation function changes (e.g., language switch). This follows React hooks best practices.
302-304: LGTM: EventCalendar receives computed calendar values.The
EventCalendarcomponent now receivescurrentMonth={calendarMonth}andcurrentYear={calendarYear}derived from the date range, andonMonthChange={() => {}}is a no-op since month changes are now controlled by theDateRangePicker. This preserves compatibility withEventCalendarwhile refactoring date logic.
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In @src/screens/UserPortal/Events/Events.spec.tsx:
- Around line 646-712: The mocks use incorrect GraphQL variable names causing
mismatches: update every mock request for GET_ORGANIZATION_EVENTS_USER_PORTAL_PG
(including MOCKS, CREATOR_NULL_MOCKS, ERROR_MOCKS, RATE_LIMIT_MOCKS and the
other mock definitions) to rename the variables object keys from startAt ->
startDate and endAt -> endDate (leave values like mockStartDate/mockEndDate or
computed dayjs values unchanged); ensure each request.variables uses
first/after/includeRecurring etc. unchanged but with startDate and endDate so
the mock signatures match the query variables.
In @src/screens/UserPortal/Events/Events.tsx:
- Around line 111-116: In Events.tsx update the GraphQL variables to match the
query by renaming the keys passed to the Apollo call from startAt/endAt to
startDate/endDate; specifically change the object properties that currently read
startAt: dateRange.startDate ?
dayjs(dateRange.startDate).startOf('day').toISOString() : null and endAt:
dateRange.endDate ? dayjs(dateRange.endDate).endOf('day').toISOString() : null
to startDate: ... and endDate: ..., so the variables match the
GET_ORGANIZATION_EVENTS_USER_PORTAL_PG query.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (2)
src/screens/UserPortal/Events/Events.spec.tsxsrc/screens/UserPortal/Events/Events.tsx
🧰 Additional context used
📓 Path-based instructions (3)
**/*.{ts,tsx}
📄 CodeRabbit inference engine (Custom checks)
Zero TypeScript errors: Run pnpm run typecheck and must pass without errors or warnings
Files:
src/screens/UserPortal/Events/Events.tsxsrc/screens/UserPortal/Events/Events.spec.tsx
**/*
⚙️ CodeRabbit configuration file
**/*: Conduct a comprehensive review and reevaluate all resolved and dismissed items.VALIDATION FRAMEWORK
1. Test Coverage & Quality
1.1 Test File Requirements
For each modified source file with logic or UI:
- ✅ Test file exists:
*.spec.tsx,*.spec.ts,*.test.tsx, or*.test.ts- ✅ Test file colocated with component (same directory)
- ✅ Test file updated to reflect source changes
- ✅ Target ≥95% code coverage for new/modified code
- ✅ List specific line numbers lacking test coverage
1.2 Test Quality Standards
✅ Framework Compliance (Vitest + React Testing Library):
- Use
vi.mock()for mocking (notjest.mock())- Use
describe(),it(),test()for structure- Use
@testing-library/reactqueries (getByRole, getByText, etc.)- Use
@testing-library/user-eventfor interactions✅ Coverage Completeness - All scenarios tested:
- Success paths with valid data
- Error scenarios (network failures, GraphQL errors, validation errors)
- Edge cases (empty data, null/undefined, boundary values)
- Loading and pending states
- User interactions and state changes
✅ Mock Quality:
- GraphQL:
MockedProviderorStaticMockLink- Realistic, comprehensive mock data
- Proper cleanup (reset mocks, clear timers)
✅ Test Structure:
- Isolated tests (no execution order dependency)
- No disabled tests (
*.skip) without documented reason + linked issue- Proper async utilities (
waitFor,act)- Shard-compatible (12-shard strategy, no shared state, <30s timeout)
2. Code Quality & Implementation
2.1 TypeScript Standards
- ✅ No
anytype without JSDoc justification- ✅ Proper typing for:
- Component props (interface declarations)
- Function parameters and return types
- GraphQL variables and responses
- State and context
- ✅ No
@ts-ignorewithout explanation- ✅ Zero TypeScript compilation errors
2.2 React & GraphQL Implementation
- ✅ React Best Practices:
- Fu...
Files:
src/screens/UserPortal/Events/Events.tsxsrc/screens/UserPortal/Events/Events.spec.tsx
**/*.{test,spec}.{ts,tsx}
📄 CodeRabbit inference engine (Custom checks)
Test coverage must be ≥95% for modified files. Run: pnpm run test:coverage and verify coverage/coverage-summary.json shows no files below threshold
Files:
src/screens/UserPortal/Events/Events.spec.tsx
🧠 Learnings (7)
📚 Learning: 2025-12-26T20:34:53.912Z
Learnt from: MuhammadUmar7195
Repo: PalisadoesFoundation/talawa-admin PR: 5847
File: src/screens/UserPortal/Volunteer/Invitations/Invitations.tsx:243-243
Timestamp: 2025-12-26T20:34:53.912Z
Learning: In PalisadoesFoundation/talawa-admin, whenever you modify a file (e.g., for migrations, tests, or feature changes), replace inline color attributes like color="grey" with Bootstrap utility classes (e.g., className="text-secondary") to satisfy the CSS-Policy-Check CI. This is a general compliance guideline, not scope creep, and should be applied to all affected TSX files during reviews. Steps: 1) Find inline color attributes in JSX/TSX. 2) Replace with appropriate Bootstrap text/color utility classes. 3) Ensure the visual outcome remains the same. 4) Run CI checks to confirm the policy passes.
Applied to files:
src/screens/UserPortal/Events/Events.tsxsrc/screens/UserPortal/Events/Events.spec.tsx
📚 Learning: 2026-01-06T16:39:41.033Z
Learnt from: Jashan32
Repo: PalisadoesFoundation/talawa-admin PR: 6199
File: src/shared-components/ProfileForm/ProfileForm.tsx:0-0
Timestamp: 2026-01-06T16:39:41.033Z
Learning: When refactoring or consolidating components (e.g., talawa-admin), remove helper functions that were copied from old files but are not used in the new implementation. Before exporting utilities, verify there are real usages across the codebase (search usages, remove dead code, and keep only necessary exports) to improve maintainability and reduce bundle size.
Applied to files:
src/screens/UserPortal/Events/Events.tsxsrc/screens/UserPortal/Events/Events.spec.tsx
📚 Learning: 2026-01-07T09:08:09.150Z
Learnt from: adityai0
Repo: PalisadoesFoundation/talawa-admin PR: 6202
File: src/components/EventManagement/EventAgendaItems/EventAgendaItems.tsx:4-13
Timestamp: 2026-01-07T09:08:09.150Z
Learning: In the talawa-admin repository, document comments with TSDoc in all TSX files. Do not use JSDoc. Write non-standard tags like component and requires as plain text (no leading @). Use standard TSDoc tags such as param, remarks, returns, and example with the leading @. This guideline applies to all TSX components (e.g., src/components/.../*.tsx).
Applied to files:
src/screens/UserPortal/Events/Events.tsxsrc/screens/UserPortal/Events/Events.spec.tsx
📚 Learning: 2025-12-21T08:59:37.942Z
Learnt from: rawadhossain
Repo: PalisadoesFoundation/talawa-admin PR: 5287
File: src/shared-components/Recurrence/CustomRecurrenceModal.spec.tsx:78-84
Timestamp: 2025-12-21T08:59:37.942Z
Learning: In talawa-admin test files, ensure each spec file uses an explicit vi.clearAllMocks() in an afterEach block to guarantee test isolation. This should be present even if a global cleanup exists in vitest.setup.ts, as the linter enforces per-file hygiene. Apply this guideline to all spec files (e.g., src/**/*.spec.tsx) to satisfy ESLint/Vitest requirements and prevent bleed-over between tests.
Applied to files:
src/screens/UserPortal/Events/Events.spec.tsx
📚 Learning: 2025-12-27T11:22:41.191Z
Learnt from: rawadhossain
Repo: PalisadoesFoundation/talawa-admin PR: 5782
File: src/screens/Leaderboard/Leaderboard.spec.tsx:342-370
Timestamp: 2025-12-27T11:22:41.191Z
Learning: In test files that render screens with shared components (e.g., src/screens/Leaderboard/Leaderboard.spec.tsx), verify integration behavior by asserting the screen renders correctly in different scenarios (e.g., search results) without asserting the internal ARIA attributes, text, or icons of the shared component. Rely on the shared component's own tests to cover accessibility and presentation details. This keeps tests focused on higher-level behavior and interactions.
Applied to files:
src/screens/UserPortal/Events/Events.spec.tsx
📚 Learning: 2026-01-08T18:48:10.364Z
Learnt from: abhishekblue
Repo: PalisadoesFoundation/talawa-admin PR: 6260
File: src/screens/AdminPortal/OrganizationPeople/OrganizationPeople.spec.tsx:337-339
Timestamp: 2026-01-08T18:48:10.364Z
Learning: In tests that exercise Apollo Client queries (e.g., talawa-admin tests under src/screens/.../OrganizationPeople.spec.tsx), avoid using vi.useFakeTimers() because Apollo's internal promise resolution can be disrupted by mocked timers, causing timeouts. Use real timers with explicit waits (for example, await act(async () => { await new Promise(r => setTimeout(r, DURATION)); })) when testing components that fetch data via Apollo. If you must use timers, prefer real timers for the relevant test and flush promises deterministically. Replace or remove useFakeTimers in such tests and rely on actual time passage or proper promise flushing to ensure reliable Apollo-driven data fetching tests.
Applied to files:
src/screens/UserPortal/Events/Events.spec.tsx
📚 Learning: 2025-12-27T11:22:19.556Z
Learnt from: rawadhossain
Repo: PalisadoesFoundation/talawa-admin PR: 5782
File: src/screens/Leaderboard/Leaderboard.spec.tsx:299-329
Timestamp: 2025-12-27T11:22:19.556Z
Learning: In talawa-admin test files (e.g., src/screens/Leaderboard/Leaderboard.spec.tsx), prefer separate explicit test cases for keyboard navigation interactions (Enter key, Space key) instead of consolidating them with test.each()/parameterization. This improves readability, documents each keyboard interaction path clearly, and makes failures easier to diagnose when specific key handling regresses. Apply this pattern to similarly structured spec files by keeping individual tests for each key interaction rather than combining them into a single parameterized test.
Applied to files:
src/screens/UserPortal/Events/Events.spec.tsx
🔇 Additional comments (9)
src/screens/UserPortal/Events/Events.spec.tsx (3)
1618-1640: LGTM: Proper async handling for view type changes.The addition of
waitForwrappers and explicitwait()calls ensures the UI state settles before assertions, which is the correct approach when testing Apollo-driven components.
1728-1760: LGTM: Proper InMemoryCache configuration for testing raw data mapping.The
addTypename: falseconfiguration is correctly used to test raw data mapping without Apollo's type augmentation. The test properly verifies the creator fallback behavior with appropriate timeouts.
1046-1049: EventForm correctly passes required data-testid props to DatePicker components—no changes needed.Verification confirms that
src/shared-components/EventForm/EventForm.tsxproperly passesdata-testid="eventStartAt"anddata-testid="eventEndAt"to the DatePicker components, matching the selectors used in the test file (lines 1046-1049, 1268-1289, 1372-1390).src/screens/UserPortal/Events/Events.tsx (6)
1-44: LGTM: Comprehensive and accurate TSDoc documentation.The TSDoc comment follows talawa-admin conventions correctly, using standard tags (@remarks, @returns, @example) with @ prefix and non-standard tags (Dependencies, State, Methods, Hooks) as plain text. The documentation accurately reflects all the changes including DateRangePicker integration and date-range driven logic.
74-74: LGTM: Component name properly capitalized.The component name is correctly changed from
events()toEvents(), following React component naming conventions (PascalCase).
83-99: LGTM: Proper state management and memoization for date range.The
dateRangestate is correctly structured withstartDateandendDate, and the derivedcalendarMonthandcalendarYearvalues are properly memoized with sensible null handling defaults.
233-249: LGTM: Proper effect dependencies and error handling.The effect correctly includes both
eventDataErrorandtin its dependency array, and properly handles rate-limit errors with selective suppression.
72-72: LGTM: Proper DateRangePicker integration following component architecture.The DateRangePicker is correctly imported from
shared-components/DateRangePicker/DateRangePicker(line 72) and properly integrated with correct props, following the reusable component architecture guidelines. The component is wired to the dateRange state with appropriate test ID and preset functionality enabled.Also applies to: 286-291
294-304: LGTM: EventCalendar properly integrated with date-range driven logic.The EventCalendar receives derived
calendarMonthandcalendarYearvalues from the dateRange state, withonMonthChangeas a no-op since the calendar is now controlled by the DateRangePicker. This approach correctly maintains backward compatibility with EventCalendar's props while implementing the new date-range driven behavior.
|
Please:
|
|
thanks for the review and checklist @palisadoes . I'll work through these and push the fixes tomorrow. appreciate the guidance. |
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (3)
src/screens/UserPortal/Events/Events.tsx (1)
56-56: Replace restrictedModalimport withBaseModalfrom shared-components.Per coding guidelines §3.4, direct imports of
Modalfromreact-bootstrapare prohibited. Replace withBaseModalfromshared-components/BaseModal/instead.The current Modal implementation at lines 306-334 can be refactored to use
BaseModalwith:
show={createEventModal}andonHide={toggleCreateEventModal}(unchanged)titleprop for the modal header titledataTestId="createEventModal"for testing- Content in the children prop (replaces Modal.Body)
BaseModal is designed to wrap react-bootstrap Modal with a standardized, accessible interface. Examples in the BaseModal component show the required API.
src/screens/UserPortal/Events/Events.spec.tsx (2)
286-291: Missing integration test forDateRangePickerinteraction in Events component.While
DateRangePickerhas comprehensive unit tests (20 tests inDateRangePicker.spec.tsx),Events.spec.tsxlacks tests verifying:
- User interaction with the
DateRangePickercomponent on the Events screen (viaevents-date-rangetest ID)- Query refetch with new
startDate/endDatevalues when date range changes- Preset range button functionality (
showPresets={true})This gap affects integration test coverage for the date-filtering feature.
350-360: Remove unused month-change mock that will never be matched.This mock (lines 342-360) expects a query with specific May/June 2023 dates when the month changes, but the Events component passes a no-op handler
onMonthChange={() => {}}to DateRangePicker (Events.tsx line 301), so no date state update or GraphQL query is triggered when the month button is clicked. The test at line 1642 only verifies the button exists; it doesn't verify that a new query is made. Either remove this mock or implement month-change date range updates in the component.
🤖 Fix all issues with AI agents
In @src/screens/UserPortal/Events/Events.tsx:
- Around line 301-303: The onMonthChange prop passed to EventCalendar is a no-op
(() => {}) which is confusing; either remove the prop if EventCalendar's
onMonthChange is optional or replace it with a brief inline comment explaining
it's intentionally a no-op because DateRangePicker now controls the date range;
locate the EventCalendar usage where currentMonth={calendarMonth} and
currentYear={calendarYear} are set and either delete the onMonthChange prop or
add a one-line comment referencing DateRangePicker controlling the date to
clarify the design choice.
- Around line 286-291: The DateRangePicker is showing no preset buttons because
only showPresets is passed; add a presets prop with an array of IDateRangePreset
objects (e.g., create a const datePresets with entries like 'today', 'thisWeek',
'thisMonth' each implementing key, label, and getRange returning
startDate/endDate using dayjs().startOf(...).toDate()/endOf(...).toDate()), then
pass presets={datePresets} into the DateRangePicker alongside the existing
value={dateRange} and onChange={setDateRange} so the preset buttons render and
populate the picker.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (2)
src/screens/UserPortal/Events/Events.spec.tsxsrc/screens/UserPortal/Events/Events.tsx
🧰 Additional context used
📓 Path-based instructions (3)
**/*.{ts,tsx}
📄 CodeRabbit inference engine (Custom checks)
Zero TypeScript errors: Run pnpm run typecheck and must pass without errors or warnings
Files:
src/screens/UserPortal/Events/Events.tsxsrc/screens/UserPortal/Events/Events.spec.tsx
**/*
⚙️ CodeRabbit configuration file
**/*: Conduct a comprehensive review and reevaluate all resolved and dismissed items.VALIDATION FRAMEWORK
1. Test Coverage & Quality
1.1 Test File Requirements
For each modified source file with logic or UI:
- ✅ Test file exists:
*.spec.tsx,*.spec.ts,*.test.tsx, or*.test.ts- ✅ Test file colocated with component (same directory)
- ✅ Test file updated to reflect source changes
- ✅ Target ≥95% code coverage for new/modified code
- ✅ List specific line numbers lacking test coverage
1.2 Test Quality Standards
✅ Framework Compliance (Vitest + React Testing Library):
- Use
vi.mock()for mocking (notjest.mock())- Use
describe(),it(),test()for structure- Use
@testing-library/reactqueries (getByRole, getByText, etc.)- Use
@testing-library/user-eventfor interactions✅ Coverage Completeness - All scenarios tested:
- Success paths with valid data
- Error scenarios (network failures, GraphQL errors, validation errors)
- Edge cases (empty data, null/undefined, boundary values)
- Loading and pending states
- User interactions and state changes
✅ Mock Quality:
- GraphQL:
MockedProviderorStaticMockLink- Realistic, comprehensive mock data
- Proper cleanup (reset mocks, clear timers)
✅ Test Structure:
- Isolated tests (no execution order dependency)
- No disabled tests (
*.skip) without documented reason + linked issue- Proper async utilities (
waitFor,act)- Shard-compatible (12-shard strategy, no shared state, <30s timeout)
2. Code Quality & Implementation
2.1 TypeScript Standards
- ✅ No
anytype without JSDoc justification- ✅ Proper typing for:
- Component props (interface declarations)
- Function parameters and return types
- GraphQL variables and responses
- State and context
- ✅ No
@ts-ignorewithout explanation- ✅ Zero TypeScript compilation errors
2.2 React & GraphQL Implementation
- ✅ React Best Practices:
- Fu...
Files:
src/screens/UserPortal/Events/Events.tsxsrc/screens/UserPortal/Events/Events.spec.tsx
**/*.{test,spec}.{ts,tsx}
📄 CodeRabbit inference engine (Custom checks)
Test coverage must be ≥95% for modified files. Run: pnpm run test:coverage and verify coverage/coverage-summary.json shows no files below threshold
Files:
src/screens/UserPortal/Events/Events.spec.tsx
🧠 Learnings (7)
📚 Learning: 2025-12-26T20:34:53.912Z
Learnt from: MuhammadUmar7195
Repo: PalisadoesFoundation/talawa-admin PR: 5847
File: src/screens/UserPortal/Volunteer/Invitations/Invitations.tsx:243-243
Timestamp: 2025-12-26T20:34:53.912Z
Learning: In PalisadoesFoundation/talawa-admin, whenever you modify a file (e.g., for migrations, tests, or feature changes), replace inline color attributes like color="grey" with Bootstrap utility classes (e.g., className="text-secondary") to satisfy the CSS-Policy-Check CI. This is a general compliance guideline, not scope creep, and should be applied to all affected TSX files during reviews. Steps: 1) Find inline color attributes in JSX/TSX. 2) Replace with appropriate Bootstrap text/color utility classes. 3) Ensure the visual outcome remains the same. 4) Run CI checks to confirm the policy passes.
Applied to files:
src/screens/UserPortal/Events/Events.tsxsrc/screens/UserPortal/Events/Events.spec.tsx
📚 Learning: 2026-01-06T16:39:41.033Z
Learnt from: Jashan32
Repo: PalisadoesFoundation/talawa-admin PR: 6199
File: src/shared-components/ProfileForm/ProfileForm.tsx:0-0
Timestamp: 2026-01-06T16:39:41.033Z
Learning: When refactoring or consolidating components (e.g., talawa-admin), remove helper functions that were copied from old files but are not used in the new implementation. Before exporting utilities, verify there are real usages across the codebase (search usages, remove dead code, and keep only necessary exports) to improve maintainability and reduce bundle size.
Applied to files:
src/screens/UserPortal/Events/Events.tsxsrc/screens/UserPortal/Events/Events.spec.tsx
📚 Learning: 2026-01-07T09:08:09.150Z
Learnt from: adityai0
Repo: PalisadoesFoundation/talawa-admin PR: 6202
File: src/components/EventManagement/EventAgendaItems/EventAgendaItems.tsx:4-13
Timestamp: 2026-01-07T09:08:09.150Z
Learning: In the talawa-admin repository, document comments with TSDoc in all TSX files. Do not use JSDoc. Write non-standard tags like component and requires as plain text (no leading @). Use standard TSDoc tags such as param, remarks, returns, and example with the leading @. This guideline applies to all TSX components (e.g., src/components/.../*.tsx).
Applied to files:
src/screens/UserPortal/Events/Events.tsxsrc/screens/UserPortal/Events/Events.spec.tsx
📚 Learning: 2025-12-21T08:59:37.942Z
Learnt from: rawadhossain
Repo: PalisadoesFoundation/talawa-admin PR: 5287
File: src/shared-components/Recurrence/CustomRecurrenceModal.spec.tsx:78-84
Timestamp: 2025-12-21T08:59:37.942Z
Learning: In talawa-admin test files, ensure each spec file uses an explicit vi.clearAllMocks() in an afterEach block to guarantee test isolation. This should be present even if a global cleanup exists in vitest.setup.ts, as the linter enforces per-file hygiene. Apply this guideline to all spec files (e.g., src/**/*.spec.tsx) to satisfy ESLint/Vitest requirements and prevent bleed-over between tests.
Applied to files:
src/screens/UserPortal/Events/Events.spec.tsx
📚 Learning: 2025-12-27T11:22:41.191Z
Learnt from: rawadhossain
Repo: PalisadoesFoundation/talawa-admin PR: 5782
File: src/screens/Leaderboard/Leaderboard.spec.tsx:342-370
Timestamp: 2025-12-27T11:22:41.191Z
Learning: In test files that render screens with shared components (e.g., src/screens/Leaderboard/Leaderboard.spec.tsx), verify integration behavior by asserting the screen renders correctly in different scenarios (e.g., search results) without asserting the internal ARIA attributes, text, or icons of the shared component. Rely on the shared component's own tests to cover accessibility and presentation details. This keeps tests focused on higher-level behavior and interactions.
Applied to files:
src/screens/UserPortal/Events/Events.spec.tsx
📚 Learning: 2026-01-08T18:48:10.364Z
Learnt from: abhishekblue
Repo: PalisadoesFoundation/talawa-admin PR: 6260
File: src/screens/AdminPortal/OrganizationPeople/OrganizationPeople.spec.tsx:337-339
Timestamp: 2026-01-08T18:48:10.364Z
Learning: In tests that exercise Apollo Client queries (e.g., talawa-admin tests under src/screens/.../OrganizationPeople.spec.tsx), avoid using vi.useFakeTimers() because Apollo's internal promise resolution can be disrupted by mocked timers, causing timeouts. Use real timers with explicit waits (for example, await act(async () => { await new Promise(r => setTimeout(r, DURATION)); })) when testing components that fetch data via Apollo. If you must use timers, prefer real timers for the relevant test and flush promises deterministically. Replace or remove useFakeTimers in such tests and rely on actual time passage or proper promise flushing to ensure reliable Apollo-driven data fetching tests.
Applied to files:
src/screens/UserPortal/Events/Events.spec.tsx
📚 Learning: 2025-12-27T11:22:19.556Z
Learnt from: rawadhossain
Repo: PalisadoesFoundation/talawa-admin PR: 5782
File: src/screens/Leaderboard/Leaderboard.spec.tsx:299-329
Timestamp: 2025-12-27T11:22:19.556Z
Learning: In talawa-admin test files (e.g., src/screens/Leaderboard/Leaderboard.spec.tsx), prefer separate explicit test cases for keyboard navigation interactions (Enter key, Space key) instead of consolidating them with test.each()/parameterization. This improves readability, documents each keyboard interaction path clearly, and makes failures easier to diagnose when specific key handling regresses. Apply this pattern to similarly structured spec files by keeping individual tests for each key interaction rather than combining them into a single parameterized test.
Applied to files:
src/screens/UserPortal/Events/Events.spec.tsx
🧬 Code graph analysis (2)
src/screens/UserPortal/Events/Events.tsx (1)
src/shared-components/DateRangePicker/DateRangePicker.tsx (1)
DateRangePicker(74-231)
src/screens/UserPortal/Events/Events.spec.tsx (1)
src/GraphQl/Queries/Queries.ts (1)
GET_ORGANIZATION_EVENTS_USER_PORTAL_PG(596-667)
🔇 Additional comments (8)
src/screens/UserPortal/Events/Events.tsx (2)
83-99: LGTM! Date range state and derived values are well implemented.The
dateRangestate is properly initialized to the current month boundaries usingdayjs. ThecalendarMonthandcalendarYearare correctly derived usinguseMemowith appropriate fallbacks whenstartDateis null.
111-116: LGTM! Query variables correctly use startDate/endDate.The GraphQL query variables properly format the dates using
dayjs().startOf('day')andendOf('day')with ISO string conversion. This aligns with theGET_ORGANIZATION_EVENTS_USER_PORTAL_PGquery schema which expectsstartDate: DateTimeandendDate: DateTimeparameters.src/screens/UserPortal/Events/Events.spec.tsx (6)
240-241: LGTM! Mock variables correctly updated to usestartDate/endDate.The mock request variables now use
startDateandendDatewhich aligns with the updatedGET_ORGANIZATION_EVENTS_USER_PORTAL_PGquery schema and the component's new date range implementation.
646-712: LGTM! CREATOR_NULL_MOCKS refactored with dynamic date computation.The IIFE pattern correctly computes
mockStartDateandmockEndDatedynamically to match the component's initial state. IncludingMOCKS[1]ensures the month-change mock is available. The mock data properly tests the creator fallback scenario.
1046-1055: LGTM! Test selectors updated to usedata-testidattributes.The selectors correctly use
getByTestId('eventStartAt')andgetByTestId('eventEndAt')which align with the new date picker implementation inEventForm.
1618-1639: LGTM! Added proper wait for state settling after no-op view change.The added
waitForblock and subsequentawait wait()ensure the UI state settles properly before asserting the view type remains unchanged. This improves test stability.
1728-1731: LGTM! InMemoryCache withaddTypename: falseis appropriate for this test.Disabling
__typenameensures the raw data mapping test correctly verifies the creator fallback behavior without Apollo's type augmentation interfering.
757-760: LGTM! Test cleanup follows best practices.The
afterEachblock properly clears localStorage and resets all mocks withvi.clearAllMocks(), ensuring test isolation as per learnings.
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Fix all issues with AI agents
In @src/screens/UserPortal/Events/Events.spec.tsx:
- Around line 1973-1978: Add a unit test to cover the non-null branch of
computeCalendarFromStartDate by passing a concrete Date instance (e.g., new
Date(2025, 5, 15)) and asserting the returned month and year match that date
(expect(month).toBe(5) and expect(year).toBe(2025)); place the test alongside
the existing null-startDate test in Events.spec.tsx so both branches of
computeCalendarFromStartDate are verified.
- Around line 1897-1929: The test "Should filter events when DateRangePicker
preset is selected" only checks UI state; update it to assert that the Events
component actually refetched/filtered data after clicking the preset by either
(a) verifying the mocked GraphQL query handler was invoked with the expected
date range variables (compute thisWeekStart/thisWeekEnd via dayjs) or (b)
asserting the rendered event list/output (e.g., an event-data-json/test id or
the Events list DOM) changed to match the expected filtered results after
clicking the thisWeekButton (test id 'events-date-range-preset-thisWeek');
ensure you compute the expected ISO date range and wait for the refetch/update
before asserting.
In @src/screens/UserPortal/Events/Events.tsx:
- Around line 131-148: The exported function computeCalendarFromStartDate lacks
TSDoc; add a TSDoc comment immediately above the function that describes the
function purpose, documents the startDate parameter (Date | null) and its
behavior when null, and documents the returned object shape ({ month: number;
year: number }) including what month and year represent; ensure the comment is
in standard TSDoc format for exported functions so consumers and tests see the
documentation.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (2)
src/screens/UserPortal/Events/Events.spec.tsxsrc/screens/UserPortal/Events/Events.tsx
🧰 Additional context used
📓 Path-based instructions (3)
**/*.{ts,tsx}
📄 CodeRabbit inference engine (Custom checks)
Zero TypeScript errors: Run pnpm run typecheck and must pass without errors or warnings
Files:
src/screens/UserPortal/Events/Events.tsxsrc/screens/UserPortal/Events/Events.spec.tsx
**/*
⚙️ CodeRabbit configuration file
**/*: Conduct a comprehensive review and reevaluate all resolved and dismissed items.VALIDATION FRAMEWORK
1. Test Coverage & Quality
1.1 Test File Requirements
For each modified source file with logic or UI:
- ✅ Test file exists:
*.spec.tsx,*.spec.ts,*.test.tsx, or*.test.ts- ✅ Test file colocated with component (same directory)
- ✅ Test file updated to reflect source changes
- ✅ Target ≥95% code coverage for new/modified code
- ✅ List specific line numbers lacking test coverage
1.2 Test Quality Standards
✅ Framework Compliance (Vitest + React Testing Library):
- Use
vi.mock()for mocking (notjest.mock())- Use
describe(),it(),test()for structure- Use
@testing-library/reactqueries (getByRole, getByText, etc.)- Use
@testing-library/user-eventfor interactions✅ Coverage Completeness - All scenarios tested:
- Success paths with valid data
- Error scenarios (network failures, GraphQL errors, validation errors)
- Edge cases (empty data, null/undefined, boundary values)
- Loading and pending states
- User interactions and state changes
✅ Mock Quality:
- GraphQL:
MockedProviderorStaticMockLink- Realistic, comprehensive mock data
- Proper cleanup (reset mocks, clear timers)
✅ Test Structure:
- Isolated tests (no execution order dependency)
- No disabled tests (
*.skip) without documented reason + linked issue- Proper async utilities (
waitFor,act)- Shard-compatible (12-shard strategy, no shared state, <30s timeout)
2. Code Quality & Implementation
2.1 TypeScript Standards
- ✅ No
anytype without JSDoc justification- ✅ Proper typing for:
- Component props (interface declarations)
- Function parameters and return types
- GraphQL variables and responses
- State and context
- ✅ No
@ts-ignorewithout explanation- ✅ Zero TypeScript compilation errors
2.2 React & GraphQL Implementation
- ✅ React Best Practices:
- Fu...
Files:
src/screens/UserPortal/Events/Events.tsxsrc/screens/UserPortal/Events/Events.spec.tsx
**/*.{test,spec}.{ts,tsx}
📄 CodeRabbit inference engine (Custom checks)
Test coverage must be ≥95% for modified files. Run: pnpm run test:coverage and verify coverage/coverage-summary.json shows no files below threshold
Files:
src/screens/UserPortal/Events/Events.spec.tsx
🧠 Learnings (7)
📚 Learning: 2025-12-26T20:34:53.912Z
Learnt from: MuhammadUmar7195
Repo: PalisadoesFoundation/talawa-admin PR: 5847
File: src/screens/UserPortal/Volunteer/Invitations/Invitations.tsx:243-243
Timestamp: 2025-12-26T20:34:53.912Z
Learning: In PalisadoesFoundation/talawa-admin, whenever you modify a file (e.g., for migrations, tests, or feature changes), replace inline color attributes like color="grey" with Bootstrap utility classes (e.g., className="text-secondary") to satisfy the CSS-Policy-Check CI. This is a general compliance guideline, not scope creep, and should be applied to all affected TSX files during reviews. Steps: 1) Find inline color attributes in JSX/TSX. 2) Replace with appropriate Bootstrap text/color utility classes. 3) Ensure the visual outcome remains the same. 4) Run CI checks to confirm the policy passes.
Applied to files:
src/screens/UserPortal/Events/Events.tsxsrc/screens/UserPortal/Events/Events.spec.tsx
📚 Learning: 2026-01-06T16:39:41.033Z
Learnt from: Jashan32
Repo: PalisadoesFoundation/talawa-admin PR: 6199
File: src/shared-components/ProfileForm/ProfileForm.tsx:0-0
Timestamp: 2026-01-06T16:39:41.033Z
Learning: When refactoring or consolidating components (e.g., talawa-admin), remove helper functions that were copied from old files but are not used in the new implementation. Before exporting utilities, verify there are real usages across the codebase (search usages, remove dead code, and keep only necessary exports) to improve maintainability and reduce bundle size.
Applied to files:
src/screens/UserPortal/Events/Events.tsxsrc/screens/UserPortal/Events/Events.spec.tsx
📚 Learning: 2026-01-07T09:08:09.150Z
Learnt from: adityai0
Repo: PalisadoesFoundation/talawa-admin PR: 6202
File: src/components/EventManagement/EventAgendaItems/EventAgendaItems.tsx:4-13
Timestamp: 2026-01-07T09:08:09.150Z
Learning: In the talawa-admin repository, document comments with TSDoc in all TSX files. Do not use JSDoc. Write non-standard tags like component and requires as plain text (no leading @). Use standard TSDoc tags such as param, remarks, returns, and example with the leading @. This guideline applies to all TSX components (e.g., src/components/.../*.tsx).
Applied to files:
src/screens/UserPortal/Events/Events.tsxsrc/screens/UserPortal/Events/Events.spec.tsx
📚 Learning: 2025-12-21T08:59:37.942Z
Learnt from: rawadhossain
Repo: PalisadoesFoundation/talawa-admin PR: 5287
File: src/shared-components/Recurrence/CustomRecurrenceModal.spec.tsx:78-84
Timestamp: 2025-12-21T08:59:37.942Z
Learning: In talawa-admin test files, ensure each spec file uses an explicit vi.clearAllMocks() in an afterEach block to guarantee test isolation. This should be present even if a global cleanup exists in vitest.setup.ts, as the linter enforces per-file hygiene. Apply this guideline to all spec files (e.g., src/**/*.spec.tsx) to satisfy ESLint/Vitest requirements and prevent bleed-over between tests.
Applied to files:
src/screens/UserPortal/Events/Events.spec.tsx
📚 Learning: 2025-12-27T11:22:41.191Z
Learnt from: rawadhossain
Repo: PalisadoesFoundation/talawa-admin PR: 5782
File: src/screens/Leaderboard/Leaderboard.spec.tsx:342-370
Timestamp: 2025-12-27T11:22:41.191Z
Learning: In test files that render screens with shared components (e.g., src/screens/Leaderboard/Leaderboard.spec.tsx), verify integration behavior by asserting the screen renders correctly in different scenarios (e.g., search results) without asserting the internal ARIA attributes, text, or icons of the shared component. Rely on the shared component's own tests to cover accessibility and presentation details. This keeps tests focused on higher-level behavior and interactions.
Applied to files:
src/screens/UserPortal/Events/Events.spec.tsx
📚 Learning: 2026-01-08T18:48:10.364Z
Learnt from: abhishekblue
Repo: PalisadoesFoundation/talawa-admin PR: 6260
File: src/screens/AdminPortal/OrganizationPeople/OrganizationPeople.spec.tsx:337-339
Timestamp: 2026-01-08T18:48:10.364Z
Learning: In tests that exercise Apollo Client queries (e.g., talawa-admin tests under src/screens/.../OrganizationPeople.spec.tsx), avoid using vi.useFakeTimers() because Apollo's internal promise resolution can be disrupted by mocked timers, causing timeouts. Use real timers with explicit waits (for example, await act(async () => { await new Promise(r => setTimeout(r, DURATION)); })) when testing components that fetch data via Apollo. If you must use timers, prefer real timers for the relevant test and flush promises deterministically. Replace or remove useFakeTimers in such tests and rely on actual time passage or proper promise flushing to ensure reliable Apollo-driven data fetching tests.
Applied to files:
src/screens/UserPortal/Events/Events.spec.tsx
📚 Learning: 2025-12-27T11:22:19.556Z
Learnt from: rawadhossain
Repo: PalisadoesFoundation/talawa-admin PR: 5782
File: src/screens/Leaderboard/Leaderboard.spec.tsx:299-329
Timestamp: 2025-12-27T11:22:19.556Z
Learning: In talawa-admin test files (e.g., src/screens/Leaderboard/Leaderboard.spec.tsx), prefer separate explicit test cases for keyboard navigation interactions (Enter key, Space key) instead of consolidating them with test.each()/parameterization. This improves readability, documents each keyboard interaction path clearly, and makes failures easier to diagnose when specific key handling regresses. Apply this pattern to similarly structured spec files by keeping individual tests for each key interaction rather than combining them into a single parameterized test.
Applied to files:
src/screens/UserPortal/Events/Events.spec.tsx
🧬 Code graph analysis (2)
src/screens/UserPortal/Events/Events.tsx (2)
src/types/shared-components/DateRangePicker/interface.ts (1)
IDateRangePreset(52-56)src/shared-components/DateRangePicker/DateRangePicker.tsx (1)
DateRangePicker(74-231)
src/screens/UserPortal/Events/Events.spec.tsx (2)
src/GraphQl/Queries/Queries.ts (1)
GET_ORGANIZATION_EVENTS_USER_PORTAL_PG(596-667)src/screens/UserPortal/Events/Events.tsx (2)
Events(150-414)computeCalendarFromStartDate(131-148)
🔇 Additional comments (10)
src/screens/UserPortal/Events/Events.tsx (3)
159-196: LGTM!The
dateRangestate implementation with nullable typing and defensive fallback is well-designed. TheuseMemooptimization forcalendarMonth/calendarYearis appropriate, and the query variable transformation correctly converts dates to ISO strings with proper null handling.
359-379: LGTM!The
DateRangePickerintegration is well-implemented with proper props. TheEventCalendarcorrectly receives derivedcurrentMonth/currentYearvalues, and the no-oponMonthChangehandler is appropriate since date range is now controlled by the picker.
307-323: LGTM!Adding
tto the dependency array is correct since it's used within the effect for error handling. The rate-limit error suppression logic is well-structured with multiple variation checks.src/screens/UserPortal/Events/Events.spec.tsx (7)
231-244: LGTM!The mock variables correctly use
startDateandendDateto match the updated query structure inEvents.tsx. The date calculations are consistent with the component's default initialization.
646-712: LGTM!The refactored
CREATOR_NULL_MOCKScorrectly uses an IIFE to compute dynamic date values and tests the null creator fallback path. The test at lines 1713-1748 properly validates this scenario withInMemoryCache({ addTypename: false })to simulate raw data mapping.
1034-1043: LGTM!The update to use
data-testidselectors (eventStartAt,eventEndAt) instead of label-based queries is appropriate and provides more stable test selectors.
1493-1548: LGTM!The
localStoragekey usage ('role') correctly aligns with how theEventscomponent retrieves the user role viagetItem('role'). Both administrator and regular user role tests are properly configured.
1605-1627: LGTM!The added
waitForblocks and explicitwait()calls improve test stability by ensuring the UI settles after state changes. This follows testing best practices for async React components.
745-748: LGTM!The
afterEachblock properly clearslocalStorageand mocks to ensure test isolation. This follows the learned pattern requiring explicitvi.clearAllMocks()in each spec file.
1-40: LGTM!The imports are well-organized and all appear to be used. The test file properly imports
computeCalendarFromStartDatefrom the component module to enable direct unit testing of the exported helper.
devxpsh
force-pushed
the
refactor/events-date-range-picker-5179
branch
from
76bb61d to
351e6e6
Compare
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Fix all issues with AI agents
In @src/screens/UserPortal/Events/Events.tsx:
- Around line 82-99: The exported function computeCalendarFromStartDate is
missing TSDoc; add a TSDoc block immediately above the function that documents
the function purpose, includes an @param for startDate (Date | null) describing
that null causes use of the current date, and an @returns describing the
returned object shape { month: number; year: number } and what the numbers
represent (0-based month and full year). Ensure the comment is a proper /** ...
*/ TSDoc placed directly above computeCalendarFromStartDate so linters and
consumers pick it up.
- Around line 107-160: The date preset labels referenced in the datePresets
array (keys: presetToday, presetThisWeek, presetThisMonth, presetNext7Days,
presetNext30Days, presetNextMonth) are missing from localization files; add
these six translation entries with appropriate translations to each
public/locales/{en,es,fr,hi,zh}/translation.json so t('presetToday') etc.
resolve correctly across all locales, keeping key names identical to those used
in the datePresets definition.
- Around line 382-385: The inline no-op onMonthChange={() => {}} is re-created
every render; extract it to a stable reference (e.g., const noop =
useCallback(() => {}, []) inside the component or a module-level const noop = ()
=> {}) and pass that instead to the EventCalendar/DateRangePicker prop so
onMonthChange uses reference-stable noop while keeping DateRangePicker
controlling calendarMonth/calendarYear.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (7)
public/locales/en/common.jsonpublic/locales/es/common.jsonpublic/locales/fr/common.jsonpublic/locales/hi/common.jsonpublic/locales/zh/common.jsonsrc/screens/UserPortal/Events/Events.spec.tsxsrc/screens/UserPortal/Events/Events.tsx
🧰 Additional context used
📓 Path-based instructions (3)
**/*
⚙️ CodeRabbit configuration file
**/*: Conduct a comprehensive review and reevaluate all resolved and dismissed items.VALIDATION FRAMEWORK
1. Test Coverage & Quality
1.1 Test File Requirements
For each modified source file with logic or UI:
- ✅ Test file exists:
*.spec.tsx,*.spec.ts,*.test.tsx, or*.test.ts- ✅ Test file colocated with component (same directory)
- ✅ Test file updated to reflect source changes
- ✅ Target ≥95% code coverage for new/modified code
- ✅ List specific line numbers lacking test coverage
1.2 Test Quality Standards
✅ Framework Compliance (Vitest + React Testing Library):
- Use
vi.mock()for mocking (notjest.mock())- Use
describe(),it(),test()for structure- Use
@testing-library/reactqueries (getByRole, getByText, etc.)- Use
@testing-library/user-eventfor interactions✅ Coverage Completeness - All scenarios tested:
- Success paths with valid data
- Error scenarios (network failures, GraphQL errors, validation errors)
- Edge cases (empty data, null/undefined, boundary values)
- Loading and pending states
- User interactions and state changes
✅ Mock Quality:
- GraphQL:
MockedProviderorStaticMockLink- Realistic, comprehensive mock data
- Proper cleanup (reset mocks, clear timers)
✅ Test Structure:
- Isolated tests (no execution order dependency)
- No disabled tests (
*.skip) without documented reason + linked issue- Proper async utilities (
waitFor,act)- Shard-compatible (12-shard strategy, no shared state, <30s timeout)
2. Code Quality & Implementation
2.1 TypeScript Standards
- ✅ No
anytype without JSDoc justification- ✅ Proper typing for:
- Component props (interface declarations)
- Function parameters and return types
- GraphQL variables and responses
- State and context
- ✅ No
@ts-ignorewithout explanation- ✅ Zero TypeScript compilation errors
2.2 React & GraphQL Implementation
- ✅ React Best Practices:
- Fu...
Files:
public/locales/zh/common.jsonpublic/locales/hi/common.jsonsrc/screens/UserPortal/Events/Events.spec.tsxsrc/screens/UserPortal/Events/Events.tsxpublic/locales/fr/common.jsonpublic/locales/en/common.jsonpublic/locales/es/common.json
**/*.{test,spec}.{ts,tsx}
📄 CodeRabbit inference engine (Custom checks)
Test coverage must be ≥95% for modified files. Run: pnpm run test:coverage and verify coverage/coverage-summary.json shows no files below threshold
Files:
src/screens/UserPortal/Events/Events.spec.tsx
**/*.{ts,tsx}
📄 CodeRabbit inference engine (Custom checks)
Zero TypeScript errors: Run pnpm run typecheck and must pass without errors or warnings
Files:
src/screens/UserPortal/Events/Events.spec.tsxsrc/screens/UserPortal/Events/Events.tsx
🧠 Learnings (7)
📚 Learning: 2025-12-21T08:59:37.942Z
Learnt from: rawadhossain
Repo: PalisadoesFoundation/talawa-admin PR: 5287
File: src/shared-components/Recurrence/CustomRecurrenceModal.spec.tsx:78-84
Timestamp: 2025-12-21T08:59:37.942Z
Learning: In talawa-admin test files, ensure each spec file uses an explicit vi.clearAllMocks() in an afterEach block to guarantee test isolation. This should be present even if a global cleanup exists in vitest.setup.ts, as the linter enforces per-file hygiene. Apply this guideline to all spec files (e.g., src/**/*.spec.tsx) to satisfy ESLint/Vitest requirements and prevent bleed-over between tests.
Applied to files:
src/screens/UserPortal/Events/Events.spec.tsx
📚 Learning: 2025-12-27T11:22:41.191Z
Learnt from: rawadhossain
Repo: PalisadoesFoundation/talawa-admin PR: 5782
File: src/screens/Leaderboard/Leaderboard.spec.tsx:342-370
Timestamp: 2025-12-27T11:22:41.191Z
Learning: In test files that render screens with shared components (e.g., src/screens/Leaderboard/Leaderboard.spec.tsx), verify integration behavior by asserting the screen renders correctly in different scenarios (e.g., search results) without asserting the internal ARIA attributes, text, or icons of the shared component. Rely on the shared component's own tests to cover accessibility and presentation details. This keeps tests focused on higher-level behavior and interactions.
Applied to files:
src/screens/UserPortal/Events/Events.spec.tsx
📚 Learning: 2026-01-08T18:48:10.364Z
Learnt from: abhishekblue
Repo: PalisadoesFoundation/talawa-admin PR: 6260
File: src/screens/AdminPortal/OrganizationPeople/OrganizationPeople.spec.tsx:337-339
Timestamp: 2026-01-08T18:48:10.364Z
Learning: In tests that exercise Apollo Client queries (e.g., talawa-admin tests under src/screens/.../OrganizationPeople.spec.tsx), avoid using vi.useFakeTimers() because Apollo's internal promise resolution can be disrupted by mocked timers, causing timeouts. Use real timers with explicit waits (for example, await act(async () => { await new Promise(r => setTimeout(r, DURATION)); })) when testing components that fetch data via Apollo. If you must use timers, prefer real timers for the relevant test and flush promises deterministically. Replace or remove useFakeTimers in such tests and rely on actual time passage or proper promise flushing to ensure reliable Apollo-driven data fetching tests.
Applied to files:
src/screens/UserPortal/Events/Events.spec.tsx
📚 Learning: 2025-12-26T20:34:53.912Z
Learnt from: MuhammadUmar7195
Repo: PalisadoesFoundation/talawa-admin PR: 5847
File: src/screens/UserPortal/Volunteer/Invitations/Invitations.tsx:243-243
Timestamp: 2025-12-26T20:34:53.912Z
Learning: In PalisadoesFoundation/talawa-admin, whenever you modify a file (e.g., for migrations, tests, or feature changes), replace inline color attributes like color="grey" with Bootstrap utility classes (e.g., className="text-secondary") to satisfy the CSS-Policy-Check CI. This is a general compliance guideline, not scope creep, and should be applied to all affected TSX files during reviews. Steps: 1) Find inline color attributes in JSX/TSX. 2) Replace with appropriate Bootstrap text/color utility classes. 3) Ensure the visual outcome remains the same. 4) Run CI checks to confirm the policy passes.
Applied to files:
src/screens/UserPortal/Events/Events.spec.tsxsrc/screens/UserPortal/Events/Events.tsx
📚 Learning: 2026-01-06T16:39:41.033Z
Learnt from: Jashan32
Repo: PalisadoesFoundation/talawa-admin PR: 6199
File: src/shared-components/ProfileForm/ProfileForm.tsx:0-0
Timestamp: 2026-01-06T16:39:41.033Z
Learning: When refactoring or consolidating components (e.g., talawa-admin), remove helper functions that were copied from old files but are not used in the new implementation. Before exporting utilities, verify there are real usages across the codebase (search usages, remove dead code, and keep only necessary exports) to improve maintainability and reduce bundle size.
Applied to files:
src/screens/UserPortal/Events/Events.spec.tsxsrc/screens/UserPortal/Events/Events.tsx
📚 Learning: 2026-01-07T09:08:09.150Z
Learnt from: adityai0
Repo: PalisadoesFoundation/talawa-admin PR: 6202
File: src/components/EventManagement/EventAgendaItems/EventAgendaItems.tsx:4-13
Timestamp: 2026-01-07T09:08:09.150Z
Learning: In the talawa-admin repository, document comments with TSDoc in all TSX files. Do not use JSDoc. Write non-standard tags like component and requires as plain text (no leading @). Use standard TSDoc tags such as param, remarks, returns, and example with the leading @. This guideline applies to all TSX components (e.g., src/components/.../*.tsx).
Applied to files:
src/screens/UserPortal/Events/Events.spec.tsxsrc/screens/UserPortal/Events/Events.tsx
📚 Learning: 2025-12-27T11:22:19.556Z
Learnt from: rawadhossain
Repo: PalisadoesFoundation/talawa-admin PR: 5782
File: src/screens/Leaderboard/Leaderboard.spec.tsx:299-329
Timestamp: 2025-12-27T11:22:19.556Z
Learning: In talawa-admin test files (e.g., src/screens/Leaderboard/Leaderboard.spec.tsx), prefer separate explicit test cases for keyboard navigation interactions (Enter key, Space key) instead of consolidating them with test.each()/parameterization. This improves readability, documents each keyboard interaction path clearly, and makes failures easier to diagnose when specific key handling regresses. Apply this pattern to similarly structured spec files by keeping individual tests for each key interaction rather than combining them into a single parameterized test.
Applied to files:
src/screens/UserPortal/Events/Events.spec.tsx
🧬 Code graph analysis (1)
src/screens/UserPortal/Events/Events.spec.tsx (1)
src/screens/UserPortal/Events/Events.tsx (2)
Events(101-411)computeCalendarFromStartDate(82-99)
🔇 Additional comments (24)
public/locales/zh/common.json (1)
234-242: LGTM!The
userEventspreset translations are correctly added with proper Chinese translations and valid JSON structure. Key naming is consistent across all locale files.public/locales/hi/common.json (1)
234-242: LGTM!The
userEventspreset translations are correctly added with appropriate Hindi translations and valid JSON structure. Key naming is consistent with other locales.public/locales/es/common.json (1)
234-242: LGTM!The
userEventspreset translations are correctly added with appropriate Spanish translations and valid JSON structure. Key naming is consistent with other locales.public/locales/en/common.json (1)
234-242: LGTM!The
userEventspreset translations are correctly added with clear English labels and valid JSON structure. This serves as the base locale and all key names are properly structured under theuserEventsnamespace.public/locales/fr/common.json (1)
234-242: LGTM!The
userEventspreset translations are correctly added with appropriate French translations and valid JSON structure. Key naming is consistent with other locales.src/screens/UserPortal/Events/Events.tsx (6)
165-179: Date range state and derived calendar values are well-structured.The defensive comment at lines 172-175 explains the null handling rationale. The
useMemofor derivingcalendarMonthandcalendarYearfromdateRange.startDateis efficient and correct.
191-196: Query variables correctly derive from dateRange state.The startDate/endDate are properly formatted to ISO strings with
startOf('day')andendOf('day')respectively. Null handling is in place for both values.
313-329: Error effect should includetin the dependency array and does so correctly.The error handling logic properly checks for rate-limit errors and suppresses them. The dependency array correctly includes both
eventDataErrorandt.
387-406: BaseModal usage is compliant with restricted import policy.The replacement of react-bootstrap Modal with
BaseModalfromshared-componentsaligns with the coding guidelines. The EventForm integration withformResetKeyfor resetting after creation is a good pattern.
366-372: DateRangePicker integration is correct and uses shared-components.The DateRangePicker is properly imported from
shared-components/DateRangePicker/DateRangePickerand configured with presets. ThedataTestIdprop enables testing.
78-80: Interface import follows correct pattern.The
IDateRangePresetinterface is correctly imported from the types directory as per coding guidelines.src/screens/UserPortal/Events/Events.spec.tsx (13)
19-21: Good: Import ofcomputeCalendarFromStartDateenables unit testing of the exported helper.The import is correctly placed and enables direct testing of the utility function.
240-241: Mock variables correctly updated to usestartDate/endDate.The mocks have been properly updated to match the new query variable names in the component.
Also applies to: 350-360, 540-541, 568-569
646-712: CREATOR_NULL_MOCKS IIFE is well-structured but could use a comment.The IIFE pattern keeps mock date generation self-contained. The inclusion of
MOCKS[1]at line 710 reuses the month-change mock, which is appropriate.
745-748: Good:vi.clearAllMocks()is present in afterEach.This follows the retrieved learning requiring explicit mock cleanup per test file for proper test isolation.
803-807: Modal close test uses keyboard escape instead of internal button.This aligns with the commit message "fix modal close test to avoid internal button dependency" and makes the test more resilient to implementation changes.
1032-1035: Test selectors updated to newdata-testidattributes.The selectors
eventStartAtandeventEndAtmatch the expected component implementation.
1895-2031: New test for DateRangePicker preset selection is comprehensive.The test:
- Creates a mock for "This Week" date range
- Clicks the preset button
- Verifies
aria-pressedstate- Validates event data filtering
- Checks input values match expected dates
This provides good coverage for the preset functionality.
2033-2073: Test for manual date range change covers the interaction path.The test verifies that manually changing the date inputs updates the displayed values correctly.
2075-2087: Unit tests forcomputeCalendarFromStartDatecover both branches.Both null input (current date fallback) and specific date input are tested. The assertions correctly verify month (0-indexed) and year values.
719-725: Thewaithelper uses real timers withact, which is appropriate for Apollo tests.Per the retrieved learning,
vi.useFakeTimers()should be avoided with Apollo Client tests. This helper correctly uses real timers with properactwrapping.
1713-1716: InMemoryCache withaddTypename: falseis appropriate for testing raw data mapping.This configuration is intentional for the creator-null test case to simulate raw data without Apollo's type augmentation.
1603-1624: Test for null view type change includes explicit wait for UI settling.The addition of
await wait()at line 1620 ensures the no-op view change completes before assertion. This addresses potential timing issues.
1491-1492: localStorage key change is consistent. The simplification fromTalawa-admin_roletoroleis correctly applied in both the component'sgetItem('role')call (line 215 of Events.tsx) and the test setup at lines 1491–1492 and 1520–1521. No references to the old key remain.
| // Define date presets using translations (inside component to access t) | ||
| const datePresets: IDateRangePreset[] = React.useMemo( | ||
| () => [ | ||
| { | ||
| key: 'today', | ||
| label: t('presetToday'), | ||
| getRange: () => ({ | ||
| startDate: dayjs().startOf('day').toDate(), | ||
| endDate: dayjs().endOf('day').toDate(), | ||
| }), | ||
| }, | ||
| { | ||
| key: 'thisWeek', | ||
| label: t('presetThisWeek'), | ||
| getRange: () => ({ | ||
| startDate: dayjs().startOf('week').toDate(), | ||
| endDate: dayjs().endOf('week').toDate(), | ||
| }), | ||
| }, | ||
| { | ||
| key: 'thisMonth', | ||
| label: t('presetThisMonth'), | ||
| getRange: () => ({ | ||
| startDate: dayjs().startOf('month').toDate(), | ||
| endDate: dayjs().endOf('month').toDate(), | ||
| }), | ||
| }, | ||
| { | ||
| key: 'next7Days', | ||
| label: t('presetNext7Days'), | ||
| getRange: () => ({ | ||
| startDate: dayjs().startOf('day').toDate(), | ||
| endDate: dayjs().add(7, 'days').endOf('day').toDate(), | ||
| }), | ||
| }, | ||
| { | ||
| key: 'next30Days', | ||
| label: t('presetNext30Days'), | ||
| getRange: () => ({ | ||
| startDate: dayjs().startOf('day').toDate(), | ||
| endDate: dayjs().add(30, 'days').endOf('day').toDate(), | ||
| }), | ||
| }, | ||
| { | ||
| key: 'nextMonth', | ||
| label: t('presetNextMonth'), | ||
| getRange: () => ({ | ||
| startDate: dayjs().add(1, 'month').startOf('month').toDate(), | ||
| endDate: dayjs().add(1, 'month').endOf('month').toDate(), | ||
| }), | ||
| }, | ||
| ], | ||
| [t], | ||
| ); |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check if translation keys exist in all locale files
KEYS=("presetToday" "presetThisWeek" "presetThisMonth" "presetNext7Days" "presetNext30Days" "presetNextMonth")
LOCALES=("en" "es" "fr" "hi" "zh")
echo "Checking for translation keys in all locale files..."
echo ""
missing_keys=()
found_all=true
for locale in "${LOCALES[@]}"; do
locale_file="public/locales/$locale/translation.json"
if [ ! -f "$locale_file" ]; then
echo "❌ MISSING FILE: $locale_file"
found_all=false
continue
fi
echo "=== Checking $locale/translation.json ==="
locale_missing=0
for key in "${KEYS[@]}"; do
if grep -q "\"$key\"" "$locale_file"; then
echo "✅ Found: $key"
else
echo "❌ MISSING: $key in $locale"
missing_keys+=("$key:$locale")
locale_missing=$((locale_missing + 1))
found_all=false
fi
done
echo ""
done
if [ "$found_all" = true ]; then
echo "✅ All translation keys found in all locales!"
exit 0
else
echo "❌ Missing keys summary:"
for item in "${missing_keys[@]}"; do
echo " - $item"
done
exit 1
fiRepository: PalisadoesFoundation/talawa-admin
Length of output: 1984
Add missing translation keys to all locale files
The date preset labels use translation keys (presetToday, presetThisWeek, presetThisMonth, presetNext7Days, presetNext30Days, presetNextMonth) that are not present in any locale file (en, es, fr, hi, zh). These keys must be added to public/locales/{locale}/translation.json for all five languages before this PR can be approved.
🤖 Prompt for AI Agents
In @src/screens/UserPortal/Events/Events.tsx around lines 107 - 160, The date
preset labels referenced in the datePresets array (keys: presetToday,
presetThisWeek, presetThisMonth, presetNext7Days, presetNext30Days,
presetNextMonth) are missing from localization files; add these six translation
entries with appropriate translations to each
public/locales/{en,es,fr,hi,zh}/translation.json so t('presetToday') etc.
resolve correctly across all locales, keeping key names identical to those used
in the datePresets definition.
| onMonthChange={() => {}} // No-op: DateRangePicker controls date range | ||
| currentMonth={calendarMonth} | ||
| currentYear={calendarYear} | ||
| /> |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
No-op onMonthChange callback should be documented or extracted.
The inline no-op arrow function () => {} is recreated on every render. While this is minor, consider extracting it to a stable reference if EventCalendar performs reference equality checks.
♻️ Optional: Extract no-op callback
+const noopMonthChange = React.useCallback(() => {}, []);
+
// In the return:
<EventCalendar
viewType={viewType}
eventData={events}
refetchEvents={refetch}
orgData={orgData}
userRole={userRole}
userId={userId}
- onMonthChange={() => {}} // No-op: DateRangePicker controls date range
+ onMonthChange={noopMonthChange} // No-op: DateRangePicker controls date range
currentMonth={calendarMonth}
currentYear={calendarYear}
/>🤖 Prompt for AI Agents
In @src/screens/UserPortal/Events/Events.tsx around lines 382 - 385, The inline
no-op onMonthChange={() => {}} is re-created every render; extract it to a
stable reference (e.g., const noop = useCallback(() => {}, []) inside the
component or a module-level const noop = () => {}) and pass that instead to the
EventCalendar/DateRangePicker prop so onMonthChange uses reference-stable noop
while keeping DateRangePicker controlling calendarMonth/calendarYear.
There was a problem hiding this comment.
Actionable comments posted: 6
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/screens/UserPortal/Events/Events.tsx (1)
375-385: Calendar navigation regression risk:EventCalendaronMonthChangeis now a no-op.If
EventCalendarrelies ononMonthChange+currentMonth/currentYearfor navigation, the “next/prev month” UI will stop working. Recommend wiringonMonthChangeto updatedateRangeto that month to preserve the prior UX.Proposed fix (keep calendar navigation working by updating dateRange)
<EventCalendar viewType={viewType} eventData={events} refetchEvents={refetch} orgData={orgData} userRole={userRole} userId={userId} - onMonthChange={() => {}} // No-op: DateRangePicker controls date range + onMonthChange={(month, year) => { + // month assumed 0-indexed (align with Date.getMonth / dayjs().month()). + const start = dayjs(new Date(year, month, 1)).startOf('month').toDate(); + const end = dayjs(new Date(year, month, 1)).endOf('month').toDate(); + setDateRange({ startDate: start, endDate: end }); + }} currentMonth={calendarMonth} currentYear={calendarYear} />
🤖 Fix all issues with AI agents
In @src/screens/UserPortal/Events/Events.spec.tsx:
- Around line 2002-2004: The test currently asserts the shared DateRangePicker
internal ARIA state via
expect(thisWeekButton).toHaveAttribute('aria-pressed','true'); remove that
assertion and instead verify the screen-level effect of selecting "This Week":
assert that the events query was invoked with the expected date-range parameters
(or that the mocked fetch/GraphQL call received the correct variables) and/or
assert that the expected events for that range are rendered (e.g., check for
specific event titles or counts). Keep DateRangePicker ARIA behavior to its own
unit tests; here focus on effects (query variables or rendered event output) and
reference the thisWeekButton interaction that triggers them.
- Around line 2075-2080: The test can flake at month/year boundaries because
computeCalendarFromStartDate(null) uses the current time; fix by capturing a
single "now" primitive and deriving expected values from it (e.g., const now =
new Date(); const { month, year } = computeCalendarFromStartDate(null);
expect(month).toBe(dayjs(now).month()); expect(year).toBe(dayjs(now).year());),
or better, refactor computeCalendarFromStartDate to accept an optional now
parameter (computeCalendarFromStartDate(startDate, now?: Date)) and in the test
call computeCalendarFromStartDate(null, now) and assert month/year from
dayjs(now) so both use the same instant.
- Around line 1895-2074: The "Should update events when date range is manually
changed" test only checks input values but not that the
GET_ORGANIZATION_EVENTS_USER_PORTAL_PG query was re-run with new
startDate/endDate; add a mock that matches the GraphQL variables (use
GET_ORGANIZATION_EVENTS_USER_PORTAL_PG and variables: id 'org123', first 100,
after null, startDate: newStartDate.toISOString(), endDate:
newEndDate.toISOString(), includeRecurring: true) and return distinct event
data, provide that mock to the MockedProvider (e.g., add to the link or use
StaticMockLink similar to thisWeekMock) and then assert the UI reflects the
returned mock (e.g., check event-data-json contains the new unique event name)
to both avoid unhandled operations and verify the query re-ran with updated
dates.
In @src/screens/UserPortal/Events/Events.tsx:
- Around line 82-99: computeCalendarFromStartDate uses new Date() when startDate
is null, making tests non-deterministic around month/year boundaries; change the
function signature to accept an optional refDate (e.g.,
computeCalendarFromStartDate(startDate: Date | null, refDate: Date = new
Date())) and use dayjs(refDate) when startDate is null so callers/tests can
inject a fixed "now"; update all callers and unit tests to pass a deterministic
refDate where needed.
- Around line 110-157: The tests only exercise the thisWeek preset; add at least
one additional unit/test case that programmatically selects another preset from
the presets array (e.g., 'today', 'thisMonth', 'next7Days', 'next30Days' or
'nextMonth') inside the Events component and asserts that the component calls
the query or updates query variables with the expected startDate/endDate
produced by that preset's getRange; locate the presets array in Events.tsx (the
objects with keys 'today', 'thisWeek', 'thisMonth', 'next7Days', 'next30Days',
'nextMonth') and in your test trigger the same UI action or invoke the preset
selection handler used by the component, then verify the query variables changed
to the preset's computed dates to raise coverage above the threshold.
- Around line 102-160: The preset labels are using t('preset...') from
useTranslation('translation', { keyPrefix: 'userEvents' }) but the locale keys
live in the common namespace; update the preset label calls to use tCommon with
the proper key prefix (e.g., replace t('presetThisWeek') etc. with
tCommon('userEvents.presetThisWeek')) or alternatively change the translation
hook to useTranslation('common', { keyPrefix: 'userEvents' }) so datePresets
(and symbols datePresets, useTranslation(...), t, tCommon, t('presetThisWeek'))
resolve to the correct namespace.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (7)
public/locales/en/common.jsonpublic/locales/es/common.jsonpublic/locales/fr/common.jsonpublic/locales/hi/common.jsonpublic/locales/zh/common.jsonsrc/screens/UserPortal/Events/Events.spec.tsxsrc/screens/UserPortal/Events/Events.tsx
🧰 Additional context used
📓 Path-based instructions (3)
**/*
⚙️ CodeRabbit configuration file
**/*: Conduct a comprehensive review and reevaluate all resolved and dismissed items.VALIDATION FRAMEWORK
1. Test Coverage & Quality
1.1 Test File Requirements
For each modified source file with logic or UI:
- ✅ Test file exists:
*.spec.tsx,*.spec.ts,*.test.tsx, or*.test.ts- ✅ Test file colocated with component (same directory)
- ✅ Test file updated to reflect source changes
- ✅ Target ≥95% code coverage for new/modified code
- ✅ List specific line numbers lacking test coverage
1.2 Test Quality Standards
✅ Framework Compliance (Vitest + React Testing Library):
- Use
vi.mock()for mocking (notjest.mock())- Use
describe(),it(),test()for structure- Use
@testing-library/reactqueries (getByRole, getByText, etc.)- Use
@testing-library/user-eventfor interactions✅ Coverage Completeness - All scenarios tested:
- Success paths with valid data
- Error scenarios (network failures, GraphQL errors, validation errors)
- Edge cases (empty data, null/undefined, boundary values)
- Loading and pending states
- User interactions and state changes
✅ Mock Quality:
- GraphQL:
MockedProviderorStaticMockLink- Realistic, comprehensive mock data
- Proper cleanup (reset mocks, clear timers)
✅ Test Structure:
- Isolated tests (no execution order dependency)
- No disabled tests (
*.skip) without documented reason + linked issue- Proper async utilities (
waitFor,act)- Shard-compatible (12-shard strategy, no shared state, <30s timeout)
2. Code Quality & Implementation
2.1 TypeScript Standards
- ✅ No
anytype without JSDoc justification- ✅ Proper typing for:
- Component props (interface declarations)
- Function parameters and return types
- GraphQL variables and responses
- State and context
- ✅ No
@ts-ignorewithout explanation- ✅ Zero TypeScript compilation errors
2.2 React & GraphQL Implementation
- ✅ React Best Practices:
- Fu...
Files:
public/locales/es/common.jsonpublic/locales/fr/common.jsonpublic/locales/zh/common.jsonpublic/locales/hi/common.jsonpublic/locales/en/common.jsonsrc/screens/UserPortal/Events/Events.spec.tsxsrc/screens/UserPortal/Events/Events.tsx
**/*.{test,spec}.{ts,tsx}
📄 CodeRabbit inference engine (Custom checks)
Test coverage must be ≥95% for modified files. Run: pnpm run test:coverage and verify coverage/coverage-summary.json shows no files below threshold
Files:
src/screens/UserPortal/Events/Events.spec.tsx
**/*.{ts,tsx}
📄 CodeRabbit inference engine (Custom checks)
Zero TypeScript errors: Run pnpm run typecheck and must pass without errors or warnings
Files:
src/screens/UserPortal/Events/Events.spec.tsxsrc/screens/UserPortal/Events/Events.tsx
🧠 Learnings (7)
📚 Learning: 2025-12-21T08:59:37.942Z
Learnt from: rawadhossain
Repo: PalisadoesFoundation/talawa-admin PR: 5287
File: src/shared-components/Recurrence/CustomRecurrenceModal.spec.tsx:78-84
Timestamp: 2025-12-21T08:59:37.942Z
Learning: In talawa-admin test files, ensure each spec file uses an explicit vi.clearAllMocks() in an afterEach block to guarantee test isolation. This should be present even if a global cleanup exists in vitest.setup.ts, as the linter enforces per-file hygiene. Apply this guideline to all spec files (e.g., src/**/*.spec.tsx) to satisfy ESLint/Vitest requirements and prevent bleed-over between tests.
Applied to files:
src/screens/UserPortal/Events/Events.spec.tsx
📚 Learning: 2025-12-27T11:22:41.191Z
Learnt from: rawadhossain
Repo: PalisadoesFoundation/talawa-admin PR: 5782
File: src/screens/Leaderboard/Leaderboard.spec.tsx:342-370
Timestamp: 2025-12-27T11:22:41.191Z
Learning: In test files that render screens with shared components (e.g., src/screens/Leaderboard/Leaderboard.spec.tsx), verify integration behavior by asserting the screen renders correctly in different scenarios (e.g., search results) without asserting the internal ARIA attributes, text, or icons of the shared component. Rely on the shared component's own tests to cover accessibility and presentation details. This keeps tests focused on higher-level behavior and interactions.
Applied to files:
src/screens/UserPortal/Events/Events.spec.tsx
📚 Learning: 2026-01-08T18:48:10.364Z
Learnt from: abhishekblue
Repo: PalisadoesFoundation/talawa-admin PR: 6260
File: src/screens/AdminPortal/OrganizationPeople/OrganizationPeople.spec.tsx:337-339
Timestamp: 2026-01-08T18:48:10.364Z
Learning: In tests that exercise Apollo Client queries (e.g., talawa-admin tests under src/screens/.../OrganizationPeople.spec.tsx), avoid using vi.useFakeTimers() because Apollo's internal promise resolution can be disrupted by mocked timers, causing timeouts. Use real timers with explicit waits (for example, await act(async () => { await new Promise(r => setTimeout(r, DURATION)); })) when testing components that fetch data via Apollo. If you must use timers, prefer real timers for the relevant test and flush promises deterministically. Replace or remove useFakeTimers in such tests and rely on actual time passage or proper promise flushing to ensure reliable Apollo-driven data fetching tests.
Applied to files:
src/screens/UserPortal/Events/Events.spec.tsx
📚 Learning: 2025-12-26T20:34:53.912Z
Learnt from: MuhammadUmar7195
Repo: PalisadoesFoundation/talawa-admin PR: 5847
File: src/screens/UserPortal/Volunteer/Invitations/Invitations.tsx:243-243
Timestamp: 2025-12-26T20:34:53.912Z
Learning: In PalisadoesFoundation/talawa-admin, whenever you modify a file (e.g., for migrations, tests, or feature changes), replace inline color attributes like color="grey" with Bootstrap utility classes (e.g., className="text-secondary") to satisfy the CSS-Policy-Check CI. This is a general compliance guideline, not scope creep, and should be applied to all affected TSX files during reviews. Steps: 1) Find inline color attributes in JSX/TSX. 2) Replace with appropriate Bootstrap text/color utility classes. 3) Ensure the visual outcome remains the same. 4) Run CI checks to confirm the policy passes.
Applied to files:
src/screens/UserPortal/Events/Events.spec.tsxsrc/screens/UserPortal/Events/Events.tsx
📚 Learning: 2026-01-06T16:39:41.033Z
Learnt from: Jashan32
Repo: PalisadoesFoundation/talawa-admin PR: 6199
File: src/shared-components/ProfileForm/ProfileForm.tsx:0-0
Timestamp: 2026-01-06T16:39:41.033Z
Learning: When refactoring or consolidating components (e.g., talawa-admin), remove helper functions that were copied from old files but are not used in the new implementation. Before exporting utilities, verify there are real usages across the codebase (search usages, remove dead code, and keep only necessary exports) to improve maintainability and reduce bundle size.
Applied to files:
src/screens/UserPortal/Events/Events.spec.tsxsrc/screens/UserPortal/Events/Events.tsx
📚 Learning: 2026-01-07T09:08:09.150Z
Learnt from: adityai0
Repo: PalisadoesFoundation/talawa-admin PR: 6202
File: src/components/EventManagement/EventAgendaItems/EventAgendaItems.tsx:4-13
Timestamp: 2026-01-07T09:08:09.150Z
Learning: In the talawa-admin repository, document comments with TSDoc in all TSX files. Do not use JSDoc. Write non-standard tags like component and requires as plain text (no leading @). Use standard TSDoc tags such as param, remarks, returns, and example with the leading @. This guideline applies to all TSX components (e.g., src/components/.../*.tsx).
Applied to files:
src/screens/UserPortal/Events/Events.spec.tsxsrc/screens/UserPortal/Events/Events.tsx
📚 Learning: 2025-12-27T11:22:19.556Z
Learnt from: rawadhossain
Repo: PalisadoesFoundation/talawa-admin PR: 5782
File: src/screens/Leaderboard/Leaderboard.spec.tsx:299-329
Timestamp: 2025-12-27T11:22:19.556Z
Learning: In talawa-admin test files (e.g., src/screens/Leaderboard/Leaderboard.spec.tsx), prefer separate explicit test cases for keyboard navigation interactions (Enter key, Space key) instead of consolidating them with test.each()/parameterization. This improves readability, documents each keyboard interaction path clearly, and makes failures easier to diagnose when specific key handling regresses. Apply this pattern to similarly structured spec files by keeping individual tests for each key interaction rather than combining them into a single parameterized test.
Applied to files:
src/screens/UserPortal/Events/Events.spec.tsx
🧬 Code graph analysis (2)
src/screens/UserPortal/Events/Events.spec.tsx (1)
src/screens/UserPortal/Events/Events.tsx (1)
Events(101-411)
src/screens/UserPortal/Events/Events.tsx (4)
src/utils/useLocalstorage.ts (1)
useLocalStorage(82-92)src/types/shared-components/DateRangePicker/interface.ts (1)
IDateRangePreset(52-56)src/shared-components/DateRangePicker/DateRangePicker.tsx (1)
DateRangePicker(74-231)src/shared-components/BaseModal/BaseModal.tsx (1)
BaseModal(28-100)
🔇 Additional comments (7)
src/screens/UserPortal/Events/Events.spec.tsx (1)
745-748: Good test isolation (vi.clearAllMocks()inafterEach).public/locales/zh/common.json (1)
258-266: Locale presets added with consistent key structure (userEvents.preset*).public/locales/hi/common.json (1)
258-266: Locale presets added with consistent key structure (userEvents.preset*).public/locales/es/common.json (1)
257-265: Locale presets added with consistent key structure (userEvents.preset*).src/screens/UserPortal/Events/Events.tsx (1)
94-98: UTC plugin is already extended via EventForm import — no runtime risk.The code at lines 94–98 uses
dayjs(startDate)without UTC. Lines 279–293 do usedayjs.utc(), but the UTC plugin is already extended at module import time throughEventForm(imported at line 70), which itself extends the plugin at line 34. The dependency chain is already satisfied; no explicit extension in Events.tsx is needed.Likely an incorrect or invalid review comment.
public/locales/fr/common.json (1)
256-265: No issues found in French locale file.The JSON structure is valid. The
"required"key appears once at the top level (not duplicated), and line 256 (eventNotFound) correctly ends with a comma. The nesteduserEventsobject and all syntax is proper.Likely an incorrect or invalid review comment.
public/locales/en/common.json (1)
256-265: No issues found — i18n implementation is correct and consistent across all locales.Verification confirms:
- ✅
"required"key appears exactly once (line 257, no duplicates)- ✅ JSON is valid and properly formatted
- ✅
eventNotFoundis correctly comma-terminated (line 256)- ✅
userEventspresets added to all locale files (en, es, fr, hi, zh)The i18n changes meet policy requirements and maintain consistency across all supported languages.
| it('Should filter events when DateRangePicker preset is selected', async () => { | ||
| const thisWeekStart = dayjs().startOf('week').startOf('day').toISOString(); | ||
| const thisWeekEnd = dayjs().endOf('week').endOf('day').toISOString(); | ||
|
|
||
| // Create a mock that expects the "This Week" date range | ||
| const thisWeekMock = { | ||
| request: { | ||
| query: GET_ORGANIZATION_EVENTS_USER_PORTAL_PG, | ||
| variables: { | ||
| id: 'org123', | ||
| first: 100, | ||
| after: null, | ||
| startDate: thisWeekStart, | ||
| endDate: thisWeekEnd, | ||
| includeRecurring: true, | ||
| }, | ||
| }, | ||
| result: { | ||
| data: { | ||
| organization: { | ||
| events: { | ||
| edges: [ | ||
| { | ||
| node: { | ||
| id: 'thisWeekEvent1', | ||
| name: 'This Week Event', | ||
| description: 'Event within this week', | ||
| startAt: dayjs() | ||
| .startOf('week') | ||
| .add(2, 'days') | ||
| .toISOString(), | ||
| endAt: dayjs() | ||
| .startOf('week') | ||
| .add(2, 'days') | ||
| .add(2, 'hours') | ||
| .toISOString(), | ||
| location: 'Test Location', | ||
| allDay: false, | ||
| isPublic: true, | ||
| isRegisterable: true, | ||
| isRecurringEventTemplate: false, | ||
| baseEvent: null, | ||
| sequenceNumber: null, | ||
| totalCount: null, | ||
| hasExceptions: false, | ||
| progressLabel: null, | ||
| recurrenceDescription: null, | ||
| recurrenceRule: null, | ||
| creator: { | ||
| id: 'user1', | ||
| name: 'Test User', | ||
| }, | ||
| attachments: [], | ||
| organization: { | ||
| id: 'org123', | ||
| name: 'Test Org', | ||
| }, | ||
| }, | ||
| cursor: 'cursor1', | ||
| }, | ||
| ], | ||
| pageInfo: { | ||
| hasNextPage: false, | ||
| endCursor: 'cursor1', | ||
| }, | ||
| }, | ||
| }, | ||
| }, | ||
| }, | ||
| }; | ||
|
|
||
| const testLink = new StaticMockLink( | ||
| [...MOCKS.slice(0, 2), thisWeekMock], | ||
| true, | ||
| ); | ||
| const cache = new InMemoryCache(); | ||
|
|
||
| render( | ||
| <MockedProvider link={testLink} cache={cache}> | ||
| <BrowserRouter> | ||
| <Provider store={store}> | ||
| <ThemeProvider theme={theme}> | ||
| <I18nextProvider i18n={i18nForTest}> | ||
| <Events /> | ||
| </I18nextProvider> | ||
| </ThemeProvider> | ||
| </Provider> | ||
| </BrowserRouter> | ||
| </MockedProvider>, | ||
| ); | ||
|
|
||
| await wait(); | ||
|
|
||
| await waitFor(() => { | ||
| expect( | ||
| screen.getByTestId('events-date-range-preset-thisWeek'), | ||
| ).toBeInTheDocument(); | ||
| }); | ||
|
|
||
| const thisWeekButton = screen.getByTestId( | ||
| 'events-date-range-preset-thisWeek', | ||
| ); | ||
|
|
||
| await userEvent.click(thisWeekButton); | ||
|
|
||
| await wait(300); | ||
|
|
||
| // Verify UI state changed (button is active) | ||
| expect(thisWeekButton).toHaveAttribute('aria-pressed', 'true'); | ||
|
|
||
| await waitFor( | ||
| () => { | ||
| const eventDataJson = screen.getByTestId('event-data-json'); | ||
| const parsedEvents = JSON.parse(eventDataJson.textContent || '[]'); | ||
|
|
||
| expect(parsedEvents).toBeInstanceOf(Array); | ||
| expect( | ||
| parsedEvents.some( | ||
| (event: { name: string }) => event.name === 'This Week Event', | ||
| ), | ||
| ).toBe(true); | ||
| }, | ||
| { timeout: 3000 }, | ||
| ); | ||
|
|
||
| const startDateInput = screen.getByTestId( | ||
| 'events-date-range-start-input', | ||
| ) as HTMLInputElement; | ||
| const endDateInput = screen.getByTestId( | ||
| 'events-date-range-end-input', | ||
| ) as HTMLInputElement; | ||
|
|
||
| expect(startDateInput.value).toBe( | ||
| dayjs(thisWeekStart).format('MM/DD/YYYY'), | ||
| ); | ||
| expect(endDateInput.value).toBe(dayjs(thisWeekEnd).format('MM/DD/YYYY')); | ||
| }); | ||
|
|
||
| it('Should update events when date range is manually changed', async () => { | ||
| const cache = new InMemoryCache(); | ||
| render( | ||
| <MockedProvider link={link} cache={cache}> | ||
| <BrowserRouter> | ||
| <Provider store={store}> | ||
| <ThemeProvider theme={theme}> | ||
| <I18nextProvider i18n={i18nForTest}> | ||
| <Events /> | ||
| </I18nextProvider> | ||
| </ThemeProvider> | ||
| </Provider> | ||
| </BrowserRouter> | ||
| </MockedProvider>, | ||
| ); | ||
|
|
||
| await wait(); | ||
|
|
||
| const startDateInput = screen.getByTestId( | ||
| 'events-date-range-start-input', | ||
| ) as HTMLInputElement; | ||
| const endDateInput = screen.getByTestId( | ||
| 'events-date-range-end-input', | ||
| ) as HTMLInputElement; | ||
|
|
||
| const newStartDate = dayjs().add(1, 'week'); | ||
| const newEndDate = dayjs().add(2, 'weeks'); | ||
|
|
||
| fireEvent.change(startDateInput, { | ||
| target: { value: newStartDate.format('MM/DD/YYYY') }, | ||
| }); | ||
|
|
||
| fireEvent.change(endDateInput, { | ||
| target: { value: newEndDate.format('MM/DD/YYYY') }, | ||
| }); | ||
|
|
||
| await wait(300); | ||
|
|
||
| expect(startDateInput.value).toBe(newStartDate.format('MM/DD/YYYY')); | ||
| expect(endDateInput.value).toBe(newEndDate.format('MM/DD/YYYY')); | ||
| }); | ||
|
|
There was a problem hiding this comment.
“Manual date range change” test doesn’t prove the main contract (Apollo variables change) and may trigger an unmocked query.
Right now it only asserts the DateRangePicker inputs changed; it should also assert the events query re-ran with the expected startDate/endDate (or at least provide a matching mock to avoid unhandled operations).
Example: add a mock that matches the new variables (and returns distinct event data)
it('Should update events when date range is manually changed', async () => {
+ const newStartDate = dayjs().add(1, 'week');
+ const newEndDate = dayjs().add(2, 'weeks');
+
+ const manualRangeMock = {
+ request: { query: GET_ORGANIZATION_EVENTS_USER_PORTAL_PG },
+ variableMatcher: (vars: { startDate?: string; endDate?: string }) =>
+ vars.startDate === newStartDate.startOf('day').toISOString() &&
+ vars.endDate === newEndDate.endOf('day').toISOString(),
+ result: {
+ data: {
+ organization: {
+ events: {
+ edges: [
+ {
+ node: {
+ id: 'manualRangeEvent',
+ name: 'Manual Range Event',
+ description: '',
+ startAt: newStartDate.toISOString(),
+ endAt: newEndDate.toISOString(),
+ location: '',
+ allDay: true,
+ isPublic: true,
+ isRegisterable: true,
+ isRecurringEventTemplate: false,
+ baseEvent: null,
+ sequenceNumber: null,
+ totalCount: null,
+ hasExceptions: false,
+ progressLabel: null,
+ recurrenceDescription: null,
+ recurrenceRule: null,
+ creator: { id: 'user1', name: 'Test User' },
+ attachments: [],
+ organization: { id: 'org123', name: 'Test Org' },
+ },
+ cursor: 'cursor-manual',
+ },
+ ],
+ pageInfo: { hasNextPage: false, endCursor: 'cursor-manual' },
+ },
+ },
+ },
+ },
+ };
+
+ const testLink = new StaticMockLink([...MOCKS.slice(0, 2), manualRangeMock], true);
const cache = new InMemoryCache();
render(
- <MockedProvider link={link} cache={cache}>
+ <MockedProvider link={testLink} cache={cache}>
...
</MockedProvider>,
);
await wait();
const startDateInput = screen.getByTestId(
'events-date-range-start-input',
) as HTMLInputElement;
const endDateInput = screen.getByTestId(
'events-date-range-end-input',
) as HTMLInputElement;
- const newStartDate = dayjs().add(1, 'week');
- const newEndDate = dayjs().add(2, 'weeks');
-
fireEvent.change(startDateInput, {
target: { value: newStartDate.format('MM/DD/YYYY') },
});
fireEvent.change(endDateInput, {
target: { value: newEndDate.format('MM/DD/YYYY') },
});
await wait(300);
- expect(startDateInput.value).toBe(newStartDate.format('MM/DD/YYYY'));
- expect(endDateInput.value).toBe(newEndDate.format('MM/DD/YYYY'));
+ await waitFor(() => {
+ const eventDataJson = screen.getByTestId('event-data-json');
+ const parsedEvents = JSON.parse(eventDataJson.textContent || '[]');
+ expect(parsedEvents.some((e: { name: string }) => e.name === 'Manual Range Event')).toBe(true);
+ });
});🤖 Prompt for AI Agents
In @src/screens/UserPortal/Events/Events.spec.tsx around lines 1895 - 2074, The
"Should update events when date range is manually changed" test only checks
input values but not that the GET_ORGANIZATION_EVENTS_USER_PORTAL_PG query was
re-run with new startDate/endDate; add a mock that matches the GraphQL variables
(use GET_ORGANIZATION_EVENTS_USER_PORTAL_PG and variables: id 'org123', first
100, after null, startDate: newStartDate.toISOString(), endDate:
newEndDate.toISOString(), includeRecurring: true) and return distinct event
data, provide that mock to the MockedProvider (e.g., add to the link or use
StaticMockLink similar to thisWeekMock) and then assert the UI reflects the
returned mock (e.g., check event-data-json contains the new unique event name)
to both avoid unhandled operations and verify the query re-ran with updated
dates.
| // Verify UI state changed (button is active) | ||
| expect(thisWeekButton).toHaveAttribute('aria-pressed', 'true'); | ||
|
|
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major
Avoid asserting shared-component internal ARIA state (aria-pressed) at screen level.
Prefer asserting the screen-level effect (query variables changed / new events rendered) and let DateRangePicker’s own tests cover ARIA details.
Based on learnings, avoid testing internal ARIA details of shared components.
🤖 Prompt for AI Agents
In @src/screens/UserPortal/Events/Events.spec.tsx around lines 2002 - 2004, The
test currently asserts the shared DateRangePicker internal ARIA state via
expect(thisWeekButton).toHaveAttribute('aria-pressed','true'); remove that
assertion and instead verify the screen-level effect of selecting "This Week":
assert that the events query was invoked with the expected date-range parameters
(or that the mocked fetch/GraphQL call received the correct variables) and/or
assert that the expected events for that range are rendered (e.g., check for
specific event titles or counts). Keep DateRangePicker ARIA behavior to its own
unit tests; here focus on effects (query variables or rendered event output) and
reference the thisWeekButton interaction that triggers them.
| it('should compute calendar from null startDate using current date', () => { | ||
| const now = dayjs(); | ||
| const { month, year } = computeCalendarFromStartDate(null); | ||
| expect(month).toBe(now.month()); | ||
| expect(year).toBe(now.year()); | ||
| }); |
There was a problem hiding this comment.
Potential flake: computeCalendarFromStartDate(null) test can fail at month/year boundaries.
Make expected values come from a captured Date (same primitive used by the function), or refactor the helper to accept an injected “now”.
🤖 Prompt for AI Agents
In @src/screens/UserPortal/Events/Events.spec.tsx around lines 2075 - 2080, The
test can flake at month/year boundaries because
computeCalendarFromStartDate(null) uses the current time; fix by capturing a
single "now" primitive and deriving expected values from it (e.g., const now =
new Date(); const { month, year } = computeCalendarFromStartDate(null);
expect(month).toBe(dayjs(now).month()); expect(year).toBe(dayjs(now).year());),
or better, refactor computeCalendarFromStartDate to accept an optional now
parameter (computeCalendarFromStartDate(startDate, now?: Date)) and in the test
call computeCalendarFromStartDate(null, now) and assert month/year from
dayjs(now) so both use the same instant.
| export function computeCalendarFromStartDate(startDate: Date | null): { | ||
| month: number; | ||
| year: number; | ||
| } { | ||
| if (!startDate) { | ||
| const now = new Date(); | ||
| return { | ||
| month: now.getMonth(), | ||
| year: now.getFullYear(), | ||
| }; | ||
| } | ||
|
|
||
| const d = dayjs(startDate); | ||
| return { | ||
| month: d.month(), | ||
| year: d.year(), | ||
| }; | ||
| } |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
computeCalendarFromStartDate(null) is non-deterministic; consider allowing an injected “now” for testability.
Using new Date() internally makes boundary-time tests (month/year rollover) flaky. Consider computeCalendarFromStartDate(startDate, refDate = new Date()).
🤖 Prompt for AI Agents
In @src/screens/UserPortal/Events/Events.tsx around lines 82 - 99,
computeCalendarFromStartDate uses new Date() when startDate is null, making
tests non-deterministic around month/year boundaries; change the function
signature to accept an optional refDate (e.g.,
computeCalendarFromStartDate(startDate: Date | null, refDate: Date = new
Date())) and use dayjs(refDate) when startDate is null so callers/tests can
inject a fixed "now"; update all callers and unit tests to pass a deterministic
refDate where needed.
| const { t } = useTranslation('translation', { keyPrefix: 'userEvents' }); | ||
| const { t: tCommon } = useTranslation('common'); | ||
|
|
||
| const { getItem } = useLocalStorage(); | ||
|
|
||
| // Define date presets using translations (inside component to access t) | ||
| const datePresets: IDateRangePreset[] = React.useMemo( | ||
| () => [ | ||
| { | ||
| key: 'today', | ||
| label: t('presetToday'), | ||
| getRange: () => ({ | ||
| startDate: dayjs().startOf('day').toDate(), | ||
| endDate: dayjs().endOf('day').toDate(), | ||
| }), | ||
| }, | ||
| { | ||
| key: 'thisWeek', | ||
| label: t('presetThisWeek'), | ||
| getRange: () => ({ | ||
| startDate: dayjs().startOf('week').toDate(), | ||
| endDate: dayjs().endOf('week').toDate(), | ||
| }), | ||
| }, | ||
| { | ||
| key: 'thisMonth', | ||
| label: t('presetThisMonth'), | ||
| getRange: () => ({ | ||
| startDate: dayjs().startOf('month').toDate(), | ||
| endDate: dayjs().endOf('month').toDate(), | ||
| }), | ||
| }, | ||
| { | ||
| key: 'next7Days', | ||
| label: t('presetNext7Days'), | ||
| getRange: () => ({ | ||
| startDate: dayjs().startOf('day').toDate(), | ||
| endDate: dayjs().add(7, 'days').endOf('day').toDate(), | ||
| }), | ||
| }, | ||
| { | ||
| key: 'next30Days', | ||
| label: t('presetNext30Days'), | ||
| getRange: () => ({ | ||
| startDate: dayjs().startOf('day').toDate(), | ||
| endDate: dayjs().add(30, 'days').endOf('day').toDate(), | ||
| }), | ||
| }, | ||
| { | ||
| key: 'nextMonth', | ||
| label: t('presetNextMonth'), | ||
| getRange: () => ({ | ||
| startDate: dayjs().add(1, 'month').startOf('month').toDate(), | ||
| endDate: dayjs().add(1, 'month').endOf('month').toDate(), | ||
| }), | ||
| }, | ||
| ], | ||
| [t], | ||
| ); |
There was a problem hiding this comment.
i18n namespace mismatch risk for preset labels (t('presetThisWeek'), etc.).
This component reads presets from useTranslation('translation', { keyPrefix: 'userEvents' }), but the provided locale changes add userEvents.preset* under public/locales/*/common.json. If the preset keys aren’t also present in the translation namespace, UI will render raw keys or fallbacks.
Option A: Read presets from the `common` namespace
export default function Events(): JSX.Element {
- const { t } = useTranslation('translation', { keyPrefix: 'userEvents' });
+ const { t } = useTranslation('translation', { keyPrefix: 'userEvents' });
const { t: tCommon } = useTranslation('common');
+ const { t: tUserEvents } = useTranslation('common', {
+ keyPrefix: 'userEvents',
+ });
// Define date presets using translations (inside component to access t)
const datePresets: IDateRangePreset[] = React.useMemo(
() => [
{
key: 'today',
- label: t('presetToday'),
+ label: tUserEvents('presetToday'),
getRange: () => ({
startDate: dayjs().startOf('day').toDate(),
endDate: dayjs().endOf('day').toDate(),
}),
},
{
key: 'thisWeek',
- label: t('presetThisWeek'),
+ label: tUserEvents('presetThisWeek'),
getRange: () => ({
startDate: dayjs().startOf('week').toDate(),
endDate: dayjs().endOf('week').toDate(),
}),
},
...
],
- [t],
+ [tUserEvents],
);Also applies to: 366-372
🤖 Prompt for AI Agents
In @src/screens/UserPortal/Events/Events.tsx around lines 102 - 160, The preset
labels are using t('preset...') from useTranslation('translation', { keyPrefix:
'userEvents' }) but the locale keys live in the common namespace; update the
preset label calls to use tCommon with the proper key prefix (e.g., replace
t('presetThisWeek') etc. with tCommon('userEvents.presetThisWeek')) or
alternatively change the translation hook to useTranslation('common', {
keyPrefix: 'userEvents' }) so datePresets (and symbols datePresets,
useTranslation(...), t, tCommon, t('presetThisWeek')) resolve to the correct
namespace.
| { | ||
| key: 'today', | ||
| label: t('presetToday'), | ||
| getRange: () => ({ | ||
| startDate: dayjs().startOf('day').toDate(), | ||
| endDate: dayjs().endOf('day').toDate(), | ||
| }), | ||
| }, | ||
| { | ||
| key: 'thisWeek', | ||
| label: t('presetThisWeek'), | ||
| getRange: () => ({ | ||
| startDate: dayjs().startOf('week').toDate(), | ||
| endDate: dayjs().endOf('week').toDate(), | ||
| }), | ||
| }, | ||
| { | ||
| key: 'thisMonth', | ||
| label: t('presetThisMonth'), | ||
| getRange: () => ({ | ||
| startDate: dayjs().startOf('month').toDate(), | ||
| endDate: dayjs().endOf('month').toDate(), | ||
| }), | ||
| }, | ||
| { | ||
| key: 'next7Days', | ||
| label: t('presetNext7Days'), | ||
| getRange: () => ({ | ||
| startDate: dayjs().startOf('day').toDate(), | ||
| endDate: dayjs().add(7, 'days').endOf('day').toDate(), | ||
| }), | ||
| }, | ||
| { | ||
| key: 'next30Days', | ||
| label: t('presetNext30Days'), | ||
| getRange: () => ({ | ||
| startDate: dayjs().startOf('day').toDate(), | ||
| endDate: dayjs().add(30, 'days').endOf('day').toDate(), | ||
| }), | ||
| }, | ||
| { | ||
| key: 'nextMonth', | ||
| label: t('presetNextMonth'), | ||
| getRange: () => ({ | ||
| startDate: dayjs().add(1, 'month').startOf('month').toDate(), | ||
| endDate: dayjs().add(1, 'month').endOf('month').toDate(), | ||
| }), | ||
| }, |
There was a problem hiding this comment.
Coverage gap: only thisWeek preset path appears exercised; other presets’ getRange branches likely uncovered.
If you’re enforcing ≥95% coverage on modified code, the other preset definitions (Today / This Month / Next 7 / Next 30 / Next Month) are likely currently uncovered. Add at least one more preset interaction test (or a small table test) that validates the query variables change.
Also applies to: 1895-2031
🤖 Prompt for AI Agents
In @src/screens/UserPortal/Events/Events.tsx around lines 110 - 157, The tests
only exercise the thisWeek preset; add at least one additional unit/test case
that programmatically selects another preset from the presets array (e.g.,
'today', 'thisMonth', 'next7Days', 'next30Days' or 'nextMonth') inside the
Events component and asserts that the component calls the query or updates query
variables with the expected startDate/endDate produced by that preset's
getRange; locate the presets array in Events.tsx (the objects with keys 'today',
'thisWeek', 'thisMonth', 'next7Days', 'next30Days', 'nextMonth') and in your
test trigger the same UI action or invoke the preset selection handler used by
the component, then verify the query variables changed to the preset's computed
dates to raise coverage above the threshold.
|
Please:
|
2 participants
What kind of change does this PR introduce?
Refactor
Issue Number:
Fixes #5179
Snapshots/Videos:
N/A – UI behavior remains functionally the same, with improved date-based filtering logic.
If relevant, did you update the documentation?
Not required for this change.
Summary
This PR refactors the User Portal Events screen to replace rigid month-based filtering with a flexible
DateRangePicker.Key changes:
DateRangePickerfor selecting arbitrary event date rangesstartAtandendAtderived from the selected rangecalendarMonthandcalendarYearfrom the active date range to maintain compatibility withEventCalendarThis improves UX and aligns event fetching behavior with user-selected date ranges.
Does this PR introduce a breaking change?
No. Existing functionality remains backward-compatible, and
EventCalendarprops are preserved.Checklist
CodeRabbit AI Review
Test Coverage
Other information
--no-verifywas used for the commit due to a known false-positive failure in thecheck-localstoragepre-commit hook.Have you read the contributing guide?
Yes
Summary by CodeRabbit
New Features
Improvements
Tests
Localization
✏️ Tip: You can customize this high-level summary in your review settings.