feat(web): updated grant status logic #17127
Conversation
WalkthroughThe pull request introduces significant updates to the grant management components, primarily enhancing the handling of grant statuses across various files. A new utility function, Changes
Possibly related PRs
Suggested labels
Suggested reviewers
📜 Recent review detailsConfiguration used: .coderabbit.yaml 📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (2)
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
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (1)
apps/web/screens/Grants/utils.ts (1)
31-104: Consider refactoring 'parseStatus' to reduce code duplicationThe
parseStatusfunction contains multiple cases with similar return structures. Refactoring could reduce code duplication and enhance maintainability.For example, you could extract common properties into variables or use a mapping object to handle the different statuses.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
⛔ Files ignored due to path filters (1)
libs/cms/src/lib/generated/contentfulTypes.d.tsis excluded by!**/generated/**
📒 Files selected for processing (8)
apps/web/screens/Grants/Grant/GrantSidebar.tsx(3 hunks)apps/web/screens/Grants/SearchResults/SearchResultsContent.tsx(4 hunks)apps/web/screens/Grants/messages.ts(2 hunks)apps/web/screens/Grants/utils.ts(1 hunks)apps/web/screens/queries/Grants.ts(2 hunks)libs/cms/src/lib/cms.elasticsearch.service.ts(1 hunks)libs/cms/src/lib/models/grant.model.ts(3 hunks)libs/cms/src/lib/search/importers/grants.service.ts(1 hunks)
🧰 Additional context used
📓 Path-based instructions (8)
apps/web/screens/Grants/SearchResults/SearchResultsContent.tsx (1)
Pattern apps/**/*: "Confirm that the code adheres to the following:
- NextJS best practices, including file structure, API routes, and static generation methods.
- Efficient state management and server-side rendering techniques.
- Optimal use of TypeScript for component and utility type safety."
libs/cms/src/lib/search/importers/grants.service.ts (1)
Pattern libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
apps/web/screens/queries/Grants.ts (1)
Pattern apps/**/*: "Confirm that the code adheres to the following:
- NextJS best practices, including file structure, API routes, and static generation methods.
- Efficient state management and server-side rendering techniques.
- Optimal use of TypeScript for component and utility type safety."
apps/web/screens/Grants/Grant/GrantSidebar.tsx (1)
Pattern apps/**/*: "Confirm that the code adheres to the following:
- NextJS best practices, including file structure, API routes, and static generation methods.
- Efficient state management and server-side rendering techniques.
- Optimal use of TypeScript for component and utility type safety."
apps/web/screens/Grants/messages.ts (1)
Pattern apps/**/*: "Confirm that the code adheres to the following:
- NextJS best practices, including file structure, API routes, and static generation methods.
- Efficient state management and server-side rendering techniques.
- Optimal use of TypeScript for component and utility type safety."
apps/web/screens/Grants/utils.ts (1)
Pattern apps/**/*: "Confirm that the code adheres to the following:
- NextJS best practices, including file structure, API routes, and static generation methods.
- Efficient state management and server-side rendering techniques.
- Optimal use of TypeScript for component and utility type safety."
libs/cms/src/lib/cms.elasticsearch.service.ts (1)
Pattern libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
libs/cms/src/lib/models/grant.model.ts (1)
Pattern libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
🔇 Additional comments (8)
apps/web/screens/Grants/utils.ts (1)
17-24: Well-implemented date formatting function
The formatDate function correctly handles locale-specific date formatting using date-fns and adheres to best practices.
apps/web/screens/queries/Grants.ts (1)
20-20: GraphQL queries updated correctly
The modifications to GET_GRANTS_QUERY and GET_GRANT_QUERY appropriately reflect the data model changes, ensuring consistency.
Also applies to: 72-74
apps/web/screens/Grants/Grant/GrantSidebar.tsx (1)
37-41: Improved status handling using 'parseStatus'
Refactoring to use parseStatus enhances code clarity and ensures consistent status representation across the component.
Also applies to: 82-93
apps/web/screens/Grants/SearchResults/SearchResultsContent.tsx (1)
Line range hint 46-93: Updated status handling promotes consistency
The integration of parseStatus refines status management and aligns with the overall application architecture.
libs/cms/src/lib/search/importers/grants.service.ts (1)
113-114: LGTM: Status handling enhancement is well-structured
The new status cases are logically grouped and maintain the binary open/closed tagging system while providing more granular status information.
Also applies to: 122-124
apps/web/screens/Grants/messages.ts (2)
37-37: LGTM: Improved grammatical accuracy
The message has been updated from singular to plural form, which better reflects the context of multiple applications.
55-74: LGTM: Well-structured status messages
The new messages effectively support the enhanced status granularity while maintaining consistent formatting with {arg} placeholders.
libs/cms/src/lib/cms.elasticsearch.service.ts (1)
50-50: Verify impact of removing status filtering
The removal of status-based filtering from the Elasticsearch query suggests that status filtering has been moved to the application layer. Let's verify this change doesn't break existing functionality.
✅ Verification successful
Status filtering has been properly moved to the application layer
The verification confirms that status filtering has been successfully moved from the Elasticsearch service to the application layer:
- Status parsing logic is centralized in
apps/web/screens/Grants/utils.tswith theparseStatusfunction - Status filtering UI is implemented in
SearchResultsFilter.tsxusing theGrantStatusenum - Status display is handled consistently across components:
SearchResultsContent.tsxGrantSidebar.tsx
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify that status filtering logic exists in the application layer
# Check for status filtering implementation in application layer
rg -A 5 "parseStatus|filterByStatus" apps/web/screens/Grants/
# Check for any remaining direct status filtering
rg -A 5 "GrantStatus\." apps/web/screens/Grants/
Length of output: 6560
Datadog ReportAll test runs ✅ 98 Total Test Services: 0 Failed, 90 Passed Test ServicesThis report shows up to 10 services
🔻 Code Coverage Decreases vs Default Branch (6)
|
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (3)
apps/web/screens/Grants/utils.ts (3)
17-24: Enhance type safety for date formattingConsider improving type safety and maintainability:
const formatDate = ( date: Date, locale: Locale, - stringFormat = 'dd.MMMM yyyy', + stringFormat: 'dd.MMMM yyyy' | 'dd.MMMM.' | 'MMMM yyyy' = 'dd.MMMM yyyy', ) => format(date, stringFormat, { locale: locale === 'is' ? localeIS : localeEn, })
106-118: Improve type safety for status tag variantsConsider defining proper types for the variants instead of using type assertions:
+type TagVariant = 'mint' | 'rose'; + export const generateStatusTag = ( status: Status['applicationStatus'], formatMessage: FormatMessage, -) => +): { label: string; variant: TagVariant } | undefined => status !== 'unknown' ? { label: status === 'open' ? formatMessage(m.search.applicationOpen) : formatMessage(m.search.applicationClosed), - variant: status === 'open' ? ('mint' as const) : ('rose' as const), + variant: status === 'open' ? 'mint' : 'rose', } : undefined
1-118: Overall implementation follows NextJS and TypeScript best practicesThe code demonstrates:
- Strong typing with TypeScript
- Modular and reusable utility functions
- Clear separation of concerns
- Proper error handling
Consider adding unit tests to verify the behavior of these utility functions, especially the edge cases in status parsing.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
⛔ Files ignored due to path filters (1)
libs/cms/src/lib/generated/contentfulTypes.d.tsis excluded by!**/generated/**
📒 Files selected for processing (2)
apps/web/screens/Grants/messages.ts(2 hunks)apps/web/screens/Grants/utils.ts(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- apps/web/screens/Grants/messages.ts
🧰 Additional context used
📓 Path-based instructions (1)
apps/web/screens/Grants/utils.ts (1)
Pattern apps/**/*: "Confirm that the code adheres to the following:
- NextJS best practices, including file structure, API routes, and static generation methods.
- Efficient state management and server-side rendering techniques.
- Optimal use of TypeScript for component and utility type safety."
🔇 Additional comments (1)
apps/web/screens/Grants/utils.ts (1)
11-15: Well-structured Status interface!
The interface follows TypeScript best practices with clear type definitions and optional properties.
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (2)
apps/web/screens/Grants/utils.ts (1)
29-115: Consider enhancing date handling and status messages.While the status parsing logic is comprehensive, consider these improvements:
- Add timezone handling for date comparisons
- Consider using date-fns's
isAfter/isBeforefor more readable date comparisons- Add more descriptive status messages for edge cases
export const parseStatus = ( grant: Grant, formatMessage: FormatMessage, locale: Locale, ): Status => { + const now = new Date() switch (grant.status) { case GrantStatus.Closed: { return { applicationStatus: 'closed', deadlineStatus: grant.dateTo ? formatMessage( - containsTimePart(grant.dateTo) + isAfter(parseISO(grant.dateTo), startOfDay(now)) ? m.search.applicationWasOpenToAndWith : m.search.applicationWasOpenTo,libs/cms/src/lib/models/grant.model.ts (1)
175-184: Consider adding date validation and error handling.The parseDate function could benefit from additional validation and error handling.
const parseDate = (date?: string, time?: number): string | undefined => { if (!date) { return } const parsedDate = new Date(date) + if (isNaN(parsedDate.getTime())) { + return undefined + } if (!time) { return format(parsedDate, 'yyyy-MM-dd') } + if (time < 0 || time > 23) { + return undefined + } return addHours(new Date(date), time).toISOString() }
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (3)
apps/web/screens/Grants/messages.ts(2 hunks)apps/web/screens/Grants/utils.ts(1 hunks)libs/cms/src/lib/models/grant.model.ts(3 hunks)
🧰 Additional context used
📓 Path-based instructions (3)
apps/web/screens/Grants/utils.ts (1)
Pattern apps/**/*: "Confirm that the code adheres to the following:
- NextJS best practices, including file structure, API routes, and static generation methods.
- Efficient state management and server-side rendering techniques.
- Optimal use of TypeScript for component and utility type safety."
apps/web/screens/Grants/messages.ts (1)
Pattern apps/**/*: "Confirm that the code adheres to the following:
- NextJS best practices, including file structure, API routes, and static generation methods.
- Efficient state management and server-side rendering techniques.
- Optimal use of TypeScript for component and utility type safety."
libs/cms/src/lib/models/grant.model.ts (1)
Pattern libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
🔇 Additional comments (4)
apps/web/screens/Grants/utils.ts (2)
12-25: LGTM! Well-structured interface and date formatting.
The Status interface clearly defines the possible states, and the formatDate function properly handles locale-specific date formatting using date-fns.
119-131: LGTM! Clean and type-safe status tag generation.
The function effectively maps application statuses to UI tags while maintaining type safety.
libs/cms/src/lib/models/grant.model.ts (2)
Line range hint 14-74: LGTM! Well-structured enum and class definition.
The GrantStatus enum and Grant class are well-organized with proper GraphQL decorators and type definitions.
123-126:
Fix critical logical error in statusText assignment.
The current condition will always evaluate to a truthy value as it's comparing enum values directly instead of checking the current status.
statusText:
- GrantStatus.CLOSED_WITH_NOTE || GrantStatus.OPEN_WITH_NOTE
+ status === GrantStatus.CLOSED_WITH_NOTE || status === GrantStatus.OPEN_WITH_NOTE
? fields.grantStatusNote
: undefined,Likely invalid or redundant comment.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (3)
libs/cms/src/lib/models/grant.model.ts (3)
91-136: Consider adding error handling and simplifying nested operationsWhile the mapping logic is correct, consider these improvements:
- Add error handling for malformed input
- Simplify nested ternary operations using optional chaining
Consider this refactoring:
export const mapGrant = ({ fields, sys }: IGrant): Grant => { + if (!fields || !sys?.id) { + throw new Error('Invalid grant data: missing required fields'); + } return { id: sys.id, name: fields.grantName, - applicationUrl: fields.granApplicationUrl?.fields - ? mapReferenceLink(fields.granApplicationUrl) - : undefined, + applicationUrl: fields.granApplicationUrl?.fields && mapReferenceLink(fields.granApplicationUrl), // ... rest of the mapping } }
138-170: Enhance maintainability of status parsing logicThe status parsing logic could be improved in several ways:
- Extract magic strings into constants
- Extract repeated date parsing
- Add more descriptive comments explaining the business logic
Consider this refactoring:
+const GRANT_STATUS = { + AUTOMATIC: 'Automatic', + ALWAYS_OPEN: 'Always open', + CLOSED_WITH_NOTE: 'Closed with note', + OPEN_WITH_NOTE: 'Open with note', +} as const; +const parseGrantDates = (dateFrom?: string, dateTo?: string) => { + const parsedDateTo = new Date(dateTo ?? ''); + const parsedDateFrom = new Date(dateFrom ?? ''); + return { parsedDateTo, parsedDateFrom }; +}; const parseStatus = (fields: IGrantFields): GrantStatus => { switch (fields.grantStatus) { - case 'Automatic': { + case GRANT_STATUS.AUTOMATIC: { - const parsedDateTo = new Date(fields.grantDateTo ?? '') - const parsedDateFrom = new Date(fields.grantDateFrom ?? '') + const { parsedDateTo, parsedDateFrom } = parseGrantDates( + fields.grantDateFrom, + fields.grantDateTo + ); // ... rest of the function } } }
172-181: Improve date parsing robustnessThe date parsing function could be enhanced with:
- Input validation using isValidDate
- Explicit time parameter typing
- Configurable date format
Consider this refactoring:
-const parseDate = (date?: string, time?: number): string | undefined => { +const DEFAULT_DATE_FORMAT = 'yyyy-MM-dd'; + +const parseDate = ( + date?: string, + time?: number, + format: string = DEFAULT_DATE_FORMAT +): string | undefined => { if (!date) { return; } const parsedDate = new Date(date); + if (!isValidDate(parsedDate)) { + return; + } if (!time) { - return format(parsedDate, 'yyyy-MM-dd'); + return format(parsedDate, format); } return addHours(new Date(date), time).toISOString(); }
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (3)
apps/web/screens/Grants/messages.ts(2 hunks)apps/web/screens/Grants/utils.ts(1 hunks)libs/cms/src/lib/models/grant.model.ts(3 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
- apps/web/screens/Grants/utils.ts
- apps/web/screens/Grants/messages.ts
🧰 Additional context used
📓 Path-based instructions (1)
libs/cms/src/lib/models/grant.model.ts (1)
Pattern libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
🔇 Additional comments (3)
libs/cms/src/lib/models/grant.model.ts (3)
3-3: LGTM! Well-structured enum expansion
The new GrantStatus values provide a comprehensive set of states that clearly represent different grant scenarios. The additional date-related imports support the new date parsing functionality.
Also applies to: 10-12, 16-23
72-74: LGTM! Well-typed field addition
The statusText field is properly typed and decorated for GraphQL integration, following TypeScript best practices.
Line range hint 1-181: Confirms compliance with coding guidelines
The implementation adheres to the coding guidelines for libs/**/*:
- ✅ Reusable components with clear separation of concerns
- ✅ Strong TypeScript typing with proper decorators and interfaces
- ✅ Clean exports enabling effective tree-shaking
|
Affected services are: air-discount-scheme-api,api,application-system-api,judicial-system-api,judicial-system-backend,services-search-indexer,services-user-notification,web, Deployed services: application-system-api,api,web,air-discount-scheme-api,application-system-api-worker,consultation-portal,services-bff-portals-admin,services-bff-portals-my-pages,air-discount-scheme-web. |
thorkellmani
added
deprecated:automerge
thorkellmani
removed
the
deprecated:automerge
thorkellmani
added
the
deprecated:automerge
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Outside diff range and nitpick comments (3)
apps/web/pages/en/grants-plaza/grant/[id].ts (1)
5-8: Remove redundant comment line.There's an extra empty comment line that should be removed.
// eslint-disable-next-line @typescript-eslint/ban-ts-comment // @ts-ignore make web strict -// const Screen = withApollo(withLocale('en')(GrantSinglePage))apps/web/screens/Grants/utils.ts (2)
29-117: Consider extracting common status patternsThe status object construction follows similar patterns across different cases. Consider extracting common logic to reduce duplication.
const createStatusObject = ( applicationStatus: Status['applicationStatus'], deadlineStatus: string, note?: string ): Status => ({ applicationStatus, deadlineStatus, note: note ?? undefined, }); const getDeadlineStatus = ( grant: Grant, formatMessage: IntlShape['formatMessage'], locale: Locale, messageKey: keyof typeof m.search, dateFormat?: string ) => { return grant.dateTo ? formatMessage(messageKey, { arg: formatDate(new Date(grant.dateTo), locale, dateFormat), }) : formatMessage(m.search.applicationClosed); };
119-131: Extract status variants as constantsConsider extracting the tag variants and labels into named constants for better maintainability.
+const STATUS_VARIANTS = { + open: 'mint' as const, + closed: 'rose' as const, +} as const; export const generateStatusTag = ( status: Status['applicationStatus'], formatMessage: IntlShape['formatMessage'], ) => status !== 'unknown' ? { label: status === 'open' ? formatMessage(m.search.applicationOpen) : formatMessage(m.search.applicationClosed), - variant: status === 'open' ? ('mint' as const) : ('rose' as const), + variant: STATUS_VARIANTS[status === 'open' ? 'open' : 'closed'], } : undefined
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (6)
apps/web/pages/en/grants-plaza/grant/[id].ts(1 hunks)apps/web/pages/en/grants-plaza/grants/index.ts(1 hunks)apps/web/pages/en/grants-plaza/index.ts(1 hunks)apps/web/screens/Grants/Grant/GrantSidebar.tsx(4 hunks)apps/web/screens/Grants/Home/GrantsHome.tsx(1 hunks)apps/web/screens/Grants/utils.ts(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- apps/web/screens/Grants/Grant/GrantSidebar.tsx
🧰 Additional context used
📓 Path-based instructions (5)
apps/web/pages/en/grants-plaza/index.ts (1)
Pattern apps/**/*: "Confirm that the code adheres to the following:
- NextJS best practices, including file structure, API routes, and static generation methods.
- Efficient state management and server-side rendering techniques.
- Optimal use of TypeScript for component and utility type safety."
apps/web/pages/en/grants-plaza/grant/[id].ts (1)
Pattern apps/**/*: "Confirm that the code adheres to the following:
- NextJS best practices, including file structure, API routes, and static generation methods.
- Efficient state management and server-side rendering techniques.
- Optimal use of TypeScript for component and utility type safety."
apps/web/pages/en/grants-plaza/grants/index.ts (1)
Pattern apps/**/*: "Confirm that the code adheres to the following:
- NextJS best practices, including file structure, API routes, and static generation methods.
- Efficient state management and server-side rendering techniques.
- Optimal use of TypeScript for component and utility type safety."
apps/web/screens/Grants/Home/GrantsHome.tsx (1)
Pattern apps/**/*: "Confirm that the code adheres to the following:
- NextJS best practices, including file structure, API routes, and static generation methods.
- Efficient state management and server-side rendering techniques.
- Optimal use of TypeScript for component and utility type safety."
apps/web/screens/Grants/utils.ts (1)
Pattern apps/**/*: "Confirm that the code adheres to the following:
- NextJS best practices, including file structure, API routes, and static generation methods.
- Efficient state management and server-side rendering techniques.
- Optimal use of TypeScript for component and utility type safety."
🔇 Additional comments (6)
apps/web/pages/en/grants-plaza/index.ts (1)
1-4: Consider implementing static generation where possible.
While server-side rendering is valid, for better performance consider:
- Using
getStaticPropsif the data doesn't need to be real-time - Implementing incremental static regeneration (ISR) for dynamic data that doesn't change frequently
Let's check if other grant pages use SSR consistently:
Also applies to: 7-12
✅ Verification successful
Let me check if the grants data is dynamic by examining the GraphQL queries and data fetching patterns.
Let me check one final thing - the actual GraphQL query to understand the data requirements.
Server-side rendering is appropriate for this grants plaza implementation
Based on the codebase analysis:
- All grant pages consistently use server-side rendering via
getServerSidePropsWrapper - The pages appear to handle dynamic data through Apollo Client queries
- The grant details and search results are likely to require real-time data for:
- Up-to-date grant availability
- Latest grant details and requirements
- Real-time search functionality
While static generation could be considered for some content, the current SSR implementation is justified given the dynamic nature of grants data.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check SSR/SSG usage patterns across grant pages
rg -A 3 "getServerSideProps|getStaticProps" "apps/web/pages/en/grants-plaza/"
Length of output: 1567
Script:
#!/bin/bash
# Check GraphQL queries and data fetching in grants components
ast-grep --pattern 'useQuery($$$)' apps/web/screens/Grants/
rg -A 5 "query |mutation " apps/web/screens/Grants/
Length of output: 2304
Script:
#!/bin/bash
# Find the GraphQL query definitions
rg -A 10 "GET_GRANT_QUERY = gql|GET_GRANTS_QUERY = gql" apps/web/screens/Grants/
Length of output: 82
apps/web/pages/en/grants-plaza/grant/[id].ts (1)
1-12: 🛠️ Refactor suggestion
Consider extracting common HOC pattern.
The HOC composition pattern is duplicated across multiple files. Consider creating a shared utility:
// utils/withPageWrapper.ts
export const withPageWrapper = (Component: React.ComponentType) =>
withApollo(withLocale('en')(Component))
// Usage in this file:
const Screen = withPageWrapper(GrantSinglePage)Additionally, consider implementing error boundaries for the dynamic [id] route to handle invalid grant IDs gracefully.
Let's check for error handling patterns:
apps/web/pages/en/grants-plaza/grants/index.ts (2)
5-7: Remove redundant comment line.
Similar to the grant/[id].ts file, there's an extra empty comment line that should be removed.
1-12: Consider implementing client-side search optimization.
For search results pages, consider implementing:
- Client-side state management (e.g., React Query, SWR) for better user experience
- Debounced search with loading states
- URL-based search parameters for better SEO and sharing
The current implementation could be enhanced with proper loading states and error handling:
Let's check the search implementation:
apps/web/screens/Grants/utils.ts (1)
12-16: Well-designed type-safe interface!
The Status interface provides a clear contract for grant status representation with appropriate type constraints.
apps/web/screens/Grants/Home/GrantsHome.tsx (1)
45-47: LGTM! Clean variable extraction
The extraction of formatMessage from the intl object follows React best practices and improves code organization.
kodiakhq
bot
removed
the
deprecated:automerge
|
This PR currently has a merge conflict. Please resolve this and then re-add the |
thorkellmani
added
the
deprecated:automerge
What
Checklist:
Summary by CodeRabbit
Release Notes
New Features
Improvements
GrantSidebarandSearchResultsContentcomponents to utilize the new status parsing logic.statusTextand date fields for grants.GrantStatusenum with new values for better status representation.Bug Fixes
These changes aim to provide a more structured approach to managing grant statuses and improve user experience.