-
-
Notifications
You must be signed in to change notification settings - Fork 756
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fixed:#1887 Event and Holiday Calendar View #2676
fixed:#1887 Event and Holiday Calendar View #2676
Conversation
WalkthroughThis pull request enhances the EventCalendar component by updating its styling, improving data handling, and refining rendering capabilities. The CSS module has been restructured to introduce new classes and CSS variables for better modularity and responsiveness. The TypeScript component has been optimized with memoization for holiday filtering and improved accessibility features. Additionally, test configurations have been updated to accommodate longer test durations. These changes aim to provide a more organized and accessible calendar view with enhanced performance. Changes
Assessment against linked issues
Possibly related PRs
Suggested labels
Suggested reviewers
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
Our Pull Request Approval ProcessThanks for contributing! Testing Your CodeRemember, your PRs won't be reviewed until these criteria are met:
Our policies make our code better. ReviewersDo not assign reviewers. Our Queue Monitors will review your PR and assign them.
Reviewing Your CodeYour reviewer(s) will have the following roles:
CONTRIBUTING.mdRead our CONTRIBUTING.md file. Most importantly:
Other
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 3
🧹 Nitpick comments (6)
src/components/EventCalendar/EventCalendar.tsx (3)
315-336
: Optimize conditional rendering for clarity and performanceThe nested ternary operators in the conditional rendering can be refactored for better readability.
Apply this diff to simplify the rendering logic:
{Array.isArray(allDayEventsList) && allDayEventsList.length > 0 ? ( - expanded === -100 ? ( - allDayEventsList - ) : ( - allDayEventsList.slice(0, 1) - ) -) : ( + expanded === -100 + ? allDayEventsList + : allDayEventsList.slice(0, 1) +) : ( <p className={styles.no_events_message}> No events available </p> )}This refactor reduces nesting and makes the conditional branches clearer.
Line range hint
575-588
: Avoid duplicate rendering of calendar viewsThe
renderHours()
function is called twice, which may lead to redundant rendering and performance issues.Review the return statement and remove the duplicate
renderHours()
call. Apply this diff:{viewType == ViewType.MONTH ? ( <> <div className={styles.calendar__weekdays}> {weekdays.map((weekday, index) => ( <div key={index} className={styles.weekday}> {weekday} </div> ))} </div> <div className={styles.calendar__days}>{renderDays()}</div> </> ) : viewType == ViewType.YEAR ? ( <YearlyEventCalender eventData={eventData} /> ) : ( - <div className={styles.calendar__hours}>{renderHours()}</div> + null )}Then, ensure
renderHours()
is called once outside the conditional:-<div> - {viewType == ViewType.YEAR ? ( - <YearlyEventCalender eventData={eventData} /> - ) : ( - <div className={styles.calendar__hours}>{renderHours()}</div> - )} -</div> +{viewType !== ViewType.YEAR && ( + <div className={styles.calendar__hours}>{renderHours()}</div> +)}This avoids duplicate calls and ensures each view type renders the appropriate components.
417-420
: Combine class names using a template literal for clarityThe class name assignment can be improved for better readability by consolidating conditions.
Apply this diff:
const className = [ - date.getDay() === 0 || date.getDay() === 6 ? styles.day_weekends : '', - date.toLocaleDateString() === today.toLocaleDateString() - ? styles.day__today - : '', + date.getDay() === 0 || date.getDay() === 6 ? styles.day_weekends : '', + date.toLocaleDateString() === today.toLocaleDateString() ? styles.day__today : '', date.getMonth() !== currentMonth ? styles.day__outside : '', selectedDate?.getTime() === date.getTime() ? styles.day__selected : '', styles.day, ].join(' ');Or use a template literal:
const className = `${styles.day} ${ date.getDay() === 0 || date.getDay() === 6 ? styles.day_weekends : '' } ${ date.toLocaleDateString() === today.toLocaleDateString() ? styles.day__today : '' } ${ date.getMonth() !== currentMonth ? styles.day__outside : '' } ${ selectedDate?.getTime() === date.getTime() ? styles.day__selected : '' }`;This enhances readability by making the class assignments explicit.
src/components/EventCalendar/EventCalendar.module.css (3)
340-350
: Use consistent CSS property ordering and spacingEnsure that the properties within the
.base_card
,.holidays_card
, and.events_card
classes are consistently ordered and formatted for maintainability.Apply this diff for consistency:
.base_card { flex: 1; + padding: 20px; border-radius: 10px; box-shadow: 0 2px 4px rgba(0, 0, 0, 0.15); - padding: 20px; }This places the
padding
property afterborder-radius
to maintain a consistent ordering.
426-431
: Consolidate indicator styles into a single classThe
.baseIndicator
class is reused for multiple indicators. Ensure that any specific styles are extended correctly.Review the usage of
composes
and verify that child classes properly extend.baseIndicator
. If additional styles are needed for specific indicators, create modifier classes.Example:
.baseIndicator { border-radius: 5px; width: 20px; height: 12px; display: inline-block; } .holidayIndicator { composes: baseIndicator; background-color: rgba(0, 0, 0, 0.15); } .organizationIndicator { composes: baseIndicator; background-color: rgba(82, 172, 255, 0.5); }This ensures that base styles are maintained and specific styles are applied appropriately.
456-474
: Organize CSS variables logically and document their purposesThe CSS variables defined under
:root
can be grouped based on their functionality and include comments for clarity.Apply this organizational change:
:root { /* Breakpoints for responsive design */ --mobile-breakpoint: 700px; --small-mobile-breakpoint: 480px; /* Color scheme */ --text-color-primary: rgba(51, 51, 51, 1); --text-color-secondary: rgba(85, 85, 85, 1); --color-user-event: rgba(139, 195, 74, 1); --color-holiday-indicator: rgba(0, 0, 0, 0.15); --color-holiday-date: rgba(255, 152, 0, 1); /* Card styles */ --card-shadow: 0 2px 4px rgba(0, 0, 0, 0.1); --holiday-card-bg: #f6f2e5; /* Spacing and sizing */ --indicator-spacing: 8px; /* Interactive states */ --hover-bg-color: rgba(0, 0, 0, 0.05); }This enhances maintainability by making variables easier to locate and understand.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
src/components/EventCalendar/EventCalendar.module.css
(4 hunks)src/components/EventCalendar/EventCalendar.tsx
(9 hunks)
🔇 Additional comments (2)
src/components/EventCalendar/EventCalendar.tsx (1)
281-286
: Verify the dependencies in the shouldShowViewMore
useMemo hook
The useMemo
hook depends on allDayEventsList.length
and windowWidth
. Ensure that allDayEventsList
is not mutated elsewhere, and consider whether depending on allDayEventsList
itself is more appropriate.
Run the following script to check for mutations of allDayEventsList
:
If allDayEventsList
is immutable, consider updating the dependencies:
useMemo(() => {
return (
allDayEventsList.length > 2 ||
(windowWidth <= 700 && allDayEventsList.length > 0)
);
-}, [allDayEventsList.length, windowWidth]);
+}, [allDayEventsList, windowWidth]);
This ensures the memoization updates correctly when allDayEventsList
changes.
✅ Verification successful
The dependency array in the useMemo
hook is correctly implemented
Since we cannot definitively find mutations of allDayEventsList
through static analysis, and the current implementation uses allDayEventsList.length
which is the actual value being used in the computation, the current dependency array is the safer and more precise choice. Using .length
as a dependency is more optimal as it will only trigger recalculation when the length actually changes, rather than on every reference change of the array itself.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Search the codebase for mutations of allDayEventsList.
# Test: Find assignments to allDayEventsList. Expect: No direct mutations.
rg --type js --type jsx --type ts --type tsx --pcre2 "(allDayEventsList)\s*(=|\+=|-=|\*=|/=)"
Length of output: 123
Script:
#!/bin/bash
# Search for allDayEventsList declaration and usage
rg --type typescript --type tsx "allDayEventsList" -A 2 -B 2
# Find the component where allDayEventsList is defined
ast-grep --pattern 'const allDayEventsList = $_'
Length of output: 146
Script:
#!/bin/bash
# Search for allDayEventsList declaration and usage with correct file type
rg -t ts -t tsx "allDayEventsList" -A 2 -B 2
# Find the component where allDayEventsList is defined using a more specific pattern
ast-grep --pattern 'const allDayEventsList = $$$'
Length of output: 124
src/components/EventCalendar/EventCalendar.module.css (1)
485-500
: Ensure responsiveness for smaller screens
Double-check that media queries correctly adjust styles for screens smaller than the mobile breakpoint, particularly the gap sizes and font sizes.
Test the interface on devices with widths around 480px to ensure elements are displayed appropriately.
If issues are found, consider adjusting the media queries:
@media only screen and (max-width: var(--small-mobile-breakpoint)) {
.list_container,
.eventsLegend {
gap: 2px;
}
.holidayIndicator,
.organizationIndicator {
width: 12px;
height: 8px;
}
.holidayText,
.legendText {
font-size: 10px;
}
}
@gurramkarthiknetha Please fix the failed tests. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
🧹 Nitpick comments (3)
src/components/OrganizationScreen/OrganizationScreen.test.tsx (1)
90-91
: Consider adding a comment explaining the drawer state.While the code is correct, adding a brief comment explaining that
_contract
indicates an expanded drawer state would improve test readability, as the class name might seem counter-intuitive.// Check for a class indicating the drawer is expanded +// Note: _contract class is applied when drawer is in expanded state expect(mainPageElement.className).toMatch('_contract');
src/setupTests.ts (1)
35-35
: Consider using a more moderate test timeout valueWhile increasing the timeout is sometimes necessary for complex tests, 100 seconds is unusually high for unit tests and could mask performance issues. Consider:
- Using a more moderate timeout (e.g., 30000ms)
- Adding specific longer timeouts only for tests that need it using
jest.setTimeout()
within those test files-jest.setTimeout(100000); +jest.setTimeout(30000);src/screens/UserPortal/Posts/Posts.test.tsx (1)
398-400
: LGTM! Consider improving test descriptionGood addition of assertion to verify no posts are displayed with invalid orgId. However, the test description could be more specific.
- test('Redirect to /user when organizationId is falsy', async () => { + test('Should redirect to /user and display no posts when organizationId is falsy', async () => {
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
src/components/OrganizationScreen/OrganizationScreen.test.tsx
(1 hunks)src/screens/UserPortal/Posts/Posts.test.tsx
(2 hunks)src/setupTests.ts
(1 hunks)
🔇 Additional comments (2)
src/components/OrganizationScreen/OrganizationScreen.test.tsx (2)
83-85
: LGTM! Good improvement to test resilience.
The change to use partial class name matching (toMatch('_expand')
) instead of exact class name matching makes the test more maintainable and less brittle. This is particularly valuable when working with CSS modules where class names can include generated hashes.
Line range hint 1-103
: Verify test coverage for new calendar features.
While the drawer toggle tests are well implemented, I notice that this test file doesn't include coverage for the new Event and Holiday Calendar features mentioned in the PR objectives.
Let's check for calendar-related test files:
✅ Verification successful
Test coverage for calendar features is comprehensive and well-implemented
The calendar features have thorough test coverage across two dedicated test files:
-
EventCalendar.test.tsx
covers:- Calendar navigation (prev/next month, year)
- Different view types (day, month, year)
- Event rendering and interactions
- Responsive behavior
- Today button functionality
- Multiple events handling
-
EventHeader.test.tsx
covers:- View type switching
- Event creation modal
- Search functionality
- Event type filtering
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for calendar-related test files
echo "Searching for calendar test files..."
fd -e test.tsx -e test.ts -e spec.tsx -e spec.ts | grep -i calendar
# Search for calendar-related test coverage in existing test files
echo "Searching for calendar-related test cases..."
rg -l "describe.*[Cc]alendar" -g "*.test.ts*"
Length of output: 453
Script:
#!/bin/bash
# Let's examine the calendar-related test files to verify coverage
echo "=== EventCalendar.test.tsx ==="
cat src/components/EventCalendar/EventCalendar.test.tsx
echo -e "\n=== EventHeader.test.tsx ==="
cat src/components/EventCalendar/EventHeader.test.tsx
Length of output: 16156
@gurramkarthiknetha Please fix the failed tests and coderabbit comments. |
Is this ok now ?? |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop-postgres #2676 +/- ##
====================================================
+ Coverage 79.10% 86.41% +7.31%
====================================================
Files 295 312 +17
Lines 7274 8128 +854
Branches 1592 1834 +242
====================================================
+ Hits 5754 7024 +1270
+ Misses 1252 929 -323
+ Partials 268 175 -93 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 2
🔭 Outside diff range comments (1)
src/components/EventCalendar/EventCalendar.tsx (1)
Line range hint
558-574
: Remove duplicate rendering of calendar viewsThere's duplicate rendering of both
YearlyEventCalender
andrenderHours()
components. The same components are rendered twice: once within the scroll container and once outside it.<div className={`${styles.calendar__scroll} customScroll`}> {viewType == ViewType.MONTH ? ( <> <div className={styles.calendar__weekdays}> {weekdays.map((weekday, index) => ( <div key={index} className={styles.weekday}> {weekday} </div> ))} </div> <div className={styles.calendar__days}>{renderDays()}</div> </> ) : viewType == ViewType.YEAR ? ( <YearlyEventCalender eventData={eventData} /> ) : ( <div className={styles.calendar__hours}>{renderHours()}</div> )} </div> -<div> - {viewType == ViewType.YEAR ? ( - <YearlyEventCalender eventData={eventData} /> - ) : ( - <div className={styles.calendar__hours}>{renderHours()}</div> - )} -</div>
🧹 Nitpick comments (2)
src/components/EventCalendar/EventCalendar.tsx (2)
332-373
: Enhance accessibility for interactive elements in calendar info cardsThe calendar info cards need accessibility improvements for better screen reader support.
<div className={styles.calendar_infocards}> <div className={styles.holidays_card} role="region" aria-label="Holidays" + aria-live="polite" > - <h3 className={styles.card_title}>Holidays</h3> + <h3 className={styles.card_title} id="holidays-title">Holidays</h3> - <ul className={styles.card_list}> + <ul className={styles.card_list} aria-labelledby="holidays-title"> {/* ... */} </ul> </div> <div className={styles.events_card} role="region" aria-label="Events" + aria-live="polite" > - <h3 className={styles.card_title}>Events</h3> + <h3 className={styles.card_title} id="events-title">Events</h3> <div className={styles.legend} + role="list" + aria-labelledby="events-title" > {/* ... */} </div> </div> </div>
Line range hint
1-574
: Consider splitting the calendar component for better maintainabilityThe calendar component has grown quite complex with multiple responsibilities:
- Managing calendar navigation
- Filtering and displaying holidays
- Handling events with different view types
- Managing responsive behavior
Consider splitting this into smaller, focused components:
CalendarNavigation
- Handle month/year navigationCalendarGrid
- Render the calendar gridEventList
- Handle event rendering and "view more" functionalityHolidayList
- Handle holiday filtering and displayThis would improve:
- Code maintainability
- Testing capabilities
- Reusability of individual components
- Performance through more granular memoization
Would you like me to help create a GitHub issue to track this refactoring task?
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
src/components/EventCalendar/EventCalendar.tsx
(8 hunks)
🔇 Additional comments (1)
src/components/EventCalendar/EventCalendar.tsx (1)
461-466
: LGTM! Improved holiday filtering implementation
The holiday filtering logic has been improved from the previous version, now correctly using the filteredHolidays and proper boolean returns in the filter function.
fe51e0c
to
5fd9926
Compare
@gurramkarthiknetha |
now ?? |
@gurramkarthiknetha great, and please update the branch |
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
🧹 Nitpick comments (1)
src/components/EventCalendar/EventCalendar.module.css (1)
340-355
: Add transition effects for smoother interactionsThe card composition is well-structured. Consider adding transition effects for a more polished user experience.
.base_card { flex: 1; padding: 20px; border-radius: 10px; box-shadow: 0 2px 4px rgba(0, 0, 0, 0.15); + transition: box-shadow 0.2s ease-in-out; } + +.base_card:hover { + box-shadow: 0 4px 8px rgba(0, 0, 0, 0.2); +}
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
src/components/EventCalendar/EventCalendar.module.css
(4 hunks)
🔇 Additional comments (4)
src/components/EventCalendar/EventCalendar.module.css (4)
443-454
: LGTM! Well-structured list container implementation
Good use of CSS variables for spacing and flexible width implementation.
456-474
: Verify color contrast ratios for accessibility
The color variables are well-organized, but some colors might not meet WCAG contrast requirements, particularly --holiday-date-color: #d35400
.
475-571
: 🛠️ Refactor suggestion
Optimize duplicate card styles
There's some duplication in card styles between lines 537-551 and the earlier definitions. Consider consolidating these styles.
- .holidays_card,
- .events_card {
- flex: 1;
- padding: 20px;
- border-radius: 10px;
- box-shadow: var(--card-shadow);
- }
-
- .holidays_card {
- background-color: var(--holiday-card-bg);
- }
-
- .events_card {
- background-color: white;
- }
These styles are already defined in the .base_card
, .holidays_card
, and .events_card
classes above.
Likely invalid or redundant comment.
Line range hint 311-327
: Verify layout changes at breakpoints
The media queries use CSS variables which is good for maintainability. However, the significant layout changes (hiding event list and reducing day height) might affect user experience.
✅ Verification successful
Based on the gathered information, I can now provide a final response:
Mobile layout changes appear well-tested and intentional
The EventCalendar component has comprehensive test coverage, including specific tests for window resize behavior and mobile responsiveness (see 'Should handle window resize in day view'
test). The media queries are consistently used only within the EventCalendar module, suggesting a contained and intentional responsive design implementation.
- The hiding of event list and day height adjustments are tested through window resize simulations in the test suite
- The breakpoint variables are scoped to this component only, not affecting other parts of the application
- The responsive behavior includes proper fallback UI with "View all"/"View less" functionality for mobile views
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for any related responsive design tests
rg -l "getByTestId|findByTestId|queryByTestId" | xargs rg "EventCalendar.*mobile|responsive"
Length of output: 94
Script:
#!/bin/bash
# Let's try a different approach to verify the responsive design implementation
# First, check for any test files related to EventCalendar
fd "EventCalendar.*test|spec"
# Then, let's look for any existing usage of these breakpoint variables
rg --type css "var\(--mobile-breakpoint\)|var\(--small-mobile-breakpoint\)"
# Also check for any responsive design related comments or documentation
rg -t css "@media.*mobile"
Length of output: 1758
Script:
#!/bin/bash
# Let's check the test file for any mobile/responsive testing
cat src/components/EventCalendar/EventCalendar.test.tsx
# Also check if these breakpoint variables are defined somewhere
rg -t css ":root.*--mobile-breakpoint|:root.*--small-mobile-breakpoint"
# Look for any existing documentation about mobile layout
fd "README|CONTRIBUTING" | xargs rg -i "mobile.*layout|responsive.*design"
Length of output: 13067
now i updated the branch |
Could you please let me know what I should do next, @gautam-divyanshu? |
@gurramkarthiknetha update and remove the merging conflicts |
Please:
|
@palisadoes fixed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🔭 Outside diff range comments (1)
src/components/EventCalendar/EventCalendar.tsx (1)
Line range hint
579-589
: Remove duplicate calendar renderingThe code renders the same components twice, which is unnecessary and could lead to performance issues.
</div> - - <div> - {viewType == ViewType.YEAR ? ( - <YearlyEventCalender eventData={eventData} /> - ) : ( - <div className={styles.calendar__hours}>{renderHours()}</div> - )} - </div> </div> ); };
🧹 Nitpick comments (2)
src/components/EventCalendar/EventCalendar.tsx (2)
308-319
: Simplify conditional rendering logicThe current implementation can be made more concise while maintaining readability.
-{Array.isArray(allDayEventsList) && -allDayEventsList.length > 0 ? ( - expanded === -100 ? ( - allDayEventsList - ) : ( - allDayEventsList.slice(0, 1) - ) -) : ( - <p className={styles.no_events_message}> - No events available - </p> -)} +{!Array.isArray(allDayEventsList) || allDayEventsList.length === 0 ? ( + <p className={styles.no_events_message}>No events available</p> +) : expanded === -100 ? ( + allDayEventsList +) : ( + allDayEventsList.slice(0, 1) +)}Also applies to: 321-330
337-378
: Enhance accessibility of the calendar info cardsWhile the current implementation includes ARIA roles, it could benefit from additional accessibility enhancements.
<div className={styles.calendar_infocards}> <div className={styles.holidays_card} role="region" aria-label="Holidays" + aria-live="polite" > - <h3 className={styles.card_title}>Holidays</h3> + <h3 className={styles.card_title} id="holidays-title">Holidays</h3> - <ul className={styles.card_list}> + <ul className={styles.card_list} aria-labelledby="holidays-title"> {/* ... */} </ul> </div> <div className={styles.events_card} role="region" aria-label="Events" + aria-live="polite" > - <h3 className={styles.card_title}>Events</h3> + <h3 className={styles.card_title} id="events-title">Events</h3> - <div className={styles.legend}> + <div className={styles.legend} aria-labelledby="events-title">
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
src/components/EventCalendar/EventCalendar.tsx
(8 hunks)
🔇 Additional comments (3)
src/components/EventCalendar/EventCalendar.tsx (3)
269-274
: Extract magic numbers as named constants
The view more logic uses magic numbers that should be constants for better maintainability.
+const MOBILE_BREAKPOINT = 700;
+const MAX_VISIBLE_EVENTS = 2;
+
const shouldShowViewMore = useMemo(() => {
+ const isMobileView = windowWidth <= MOBILE_BREAKPOINT;
+ const hasEvents = allDayEventsList.length > 0;
+ const hasExcessEvents = allDayEventsList.length > MAX_VISIBLE_EVENTS;
+
return (
- allDayEventsList.length > 2 ||
- (windowWidth <= 700 && allDayEventsList.length > 0)
+ hasExcessEvents || (isMobileView && hasEvents)
);
}, [allDayEventsList.length, windowWidth]);
Also applies to: 276-279
466-471
: Correct the filter function in holidayList
The filter
function should be simplified to use the already computed filteredHolidays
.
-const holidayList: JSX.Element[] = filteredHolidays
- .filter((holiday) => holiday.date === dayjs(date).format('MM-DD'))
+const holidayList: JSX.Element[] = filteredHolidays
+ .filter((holiday) => holiday.date === dayjs(date).format('MM-DD'))
.map((holiday) => (
<HolidayCard key={holiday.name} holidayName={holiday.name} />
));
138-151
: 🛠️ Refactor suggestion
Improve holiday filtering implementation
The current implementation has several areas for improvement:
- The environment check for suppressing warnings in test mode is an anti-pattern
- The date parsing could be more robust
- The filter logic could be simplified
Consider this improved implementation:
const filteredHolidays = useMemo(() => {
return Array.isArray(holidays)
? holidays.filter((holiday) => {
if (!holiday.date) {
- if (process.env.NODE_ENV !== 'test') {
- console.warn(`Holiday "${holiday.name}" has no date specified.`);
- }
+ console.warn(`Holiday "${holiday.name}" skipped: No date specified.`);
return false;
}
- const holidayMonth = dayjs(holiday.date, 'MM-DD', true).month();
- return holidayMonth === currentMonth;
+ const parsedDate = dayjs(holiday.date, 'MM-DD', true);
+ if (!parsedDate.isValid()) {
+ console.warn(
+ `Holiday "${holiday.name}" skipped: Invalid date format "${holiday.date}"`
+ );
+ return false;
+ }
+ return parsedDate.month() === currentMonth;
})
: [];
}, [holidays, currentMonth]);
Likely invalid or redundant comment.
92ce58d
into
PalisadoesFoundation:develop-postgres
This feature displays an interactive calendar view for tracking events and holidays. The calendar highlights holidays and user/organization-created events for the selected month, with color-coded markers for easy identification
What kind of change does this PR introduce?
This PR introduces a new feature for displaying an interactive event calendar with a list of holidays and user/organization-created events.
Issue Number:
Fixes #1887
Did you add tests for your changes?
Yes, unit tests have been added to ensure the functionality works as expected.
Snapshots/Videos:
Snapshots and a short demonstration video showcasing the feature have been attached for better understanding.
If relevant, did you update the documentation?
Yes, the relevant sections in the Talawa-Docs have been updated to include details about the new feature.
Summary
This feature addresses the need for a more user-friendly and comprehensive event calendar.
Problem: The existing calendar lacked the ability to display a list of holidays and events in an organized manner.
Solution:
A list of holidays and events is now displayed below the calendar.
Color-coding has been implemented to distinguish between holidays and events for improved usability.
The UI aligns with the Figma design shared by the team.
Does this PR introduce a breaking change?
No, this PR does not introduce any breaking changes.
Other information
The Figma design used for this implementation can be found here.
This PR follows the project’s contribution guidelines and is submitted against the develop branch, as recommended.
Have you read the contributing guide?
Yes
Summary by CodeRabbit
New Features
Bug Fixes
Chores