Decentralized Verification Feedback: Badges Tooltips + Filters #4765
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
mateodaza
changed the title
mateodaza
changed the title
WalkthroughThe pull request introduces new tooltip entries in multiple language JSON files, enhancing user information regarding project legitimacy and eligibility for GIVbacks. It also updates TypeScript enums to include new filtering options and modifies several components to utilize these new properties and display tooltips. Additionally, it adjusts styles and logic in various components to improve user experience and clarity regarding project statuses. Changes
Possibly related PRs
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
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
Outside diff range and nitpick comments (11)
src/components/IconWithToolTip.tsx (1)
21-38: LGTM: Timeout functionality well-implemented. Consider making delay time configurable.The implementation of the delay functionality using
timeoutRefand theshowTooltipandhideTooltipfunctions is well done. The use ofuseReffor the timeout is correct, and the logic for showing and hiding the tooltip with a delay is properly implemented.Consider making the delay time (currently hardcoded to 500ms) configurable. This would provide more flexibility for different use cases. You could add a
delayTimeprop to the component:interface IIconWithTooltipProps extends ITooltipDirection { // ... existing props delay?: boolean; delayTime?: number; } export const IconWithTooltip: FC<IIconWithTooltipProps> = ({ // ... other props delay = false, delayTime = 500, }) => { // ... in showTooltip function timeoutRef.current = setTimeout(() => { setShow(true); }, delayTime); // ... }This change would allow users of the component to customize the delay time if needed.
src/components/views/project/ProjectBadges.tsx (2)
32-48: LGTM: Enhanced verified badge with tooltipThe verified badge has been successfully wrapped with
IconWithTooltip, providing additional information to users. The implementation is correct and consistent with the project's style.Consider extracting the tooltip content into a separate constant or variable to improve readability and maintainability. For example:
const vouchedTooltipContent = ( <TooltipContent> {formatMessage({ id: 'tooltip.vouched' })} </TooltipContent> ); // Then use it in the JSX <IconWithTooltip // ...other props > {vouchedTooltipContent} </IconWithTooltip>This approach would make it easier to manage tooltip content, especially if it becomes more complex in the future.
51-70: LGTM: Enhanced GIVbacks eligible badge with tooltipThe GIVbacks eligible badge has been successfully wrapped with
IconWithTooltip, providing additional information to users. The implementation is correct and consistent with the verified badge changes.Similar to the suggestion for the verified badge, consider extracting the tooltip content into a separate constant or variable:
const givbackEligibleTooltipContent = ( <TooltipContent> {formatMessage({ id: 'tooltip.givback_eligible' })} </TooltipContent> ); // Then use it in the JSX <IconWithTooltip // ...other props > {givbackEligibleTooltipContent} </IconWithTooltip>This would maintain consistency with the previous suggestion and improve overall code readability.
src/helpers/url.tsx (1)
30-35: LGTM! Consider extracting filter mapping to a separate object.The addition of the
ECampaignFilterField.IsGivbackEligiblecase is implemented correctly and consistent with the existing pattern. It enhances the filtering capabilities of thecampaignLinkGeneratorfunction.To improve maintainability, consider extracting the mapping between
ECampaignFilterFieldandEProjectsFilterto a separate object. This would make it easier to add new filters in the future and reduce the complexity of the switch statement. Here's an example of how you could refactor this:const filterFieldToProjectsFilter = { [ECampaignFilterField.Verified]: EProjectsFilter.VERIFIED, [ECampaignFilterField.IsGivbackEligible]: EProjectsFilter.IS_GIVBACK_ELIGIBLE, // ... other mappings ... }; // In the switch statement: case ECampaignFilterField.IsGivbackEligible: case ECampaignFilterField.Verified: // ... other cases ... const projectsFilter = filterFieldToProjectsFilter[filter]; if (projectsFilter) { params.append('filter', projectsFilter); } break;This refactoring would make the code more maintainable and easier to extend in the future.
src/components/Tooltip.tsx (2)
26-26: LGTM! Consider using a more descriptive constant name.The addition of the
MARGINconstant is a good practice for maintainability. However, to improve clarity, consider using a more descriptive name such asTOOLTIP_MARGINorTOOLTIP_POSITIONING_MARGIN.-const MARGIN = 4; +const TOOLTIP_POSITIONING_MARGIN = 4;
161-161: LGTM! Consider extracting the arrow size calculation.The addition of
MARGINto the tooltip positioning calculations for desktop devices (right and left directions) is correct and maintains consistency with other margin applications.To improve code readability, consider extracting the arrow size calculation into a separate constant:
+const ARROW_SIZE_WITH_MARGIN = ARROW_SIZE + MARGIN; // Then use it in the calculations: -left: parentRect.right + ARROW_SIZE + MARGIN, +left: parentRect.right + ARROW_SIZE_WITH_MARGIN, -left: parentRect.left - ARROW_SIZE - MARGIN, +left: parentRect.left - ARROW_SIZE_WITH_MARGIN,This change would make the positioning calculations more concise and easier to understand at a glance.
Also applies to: 169-169
src/components/menu/FilterMenu.tsx (1)
Line range hint
1-324: Summary: Filter option updated from "Vouched" to "GIVback Eligible"The change in this file is focused on updating a single filter option in the
projectsFeaturesarray. This modification aligns with the PR's objective of implementing "Decentralized Verification Feedback" and "GIVbacks".While the change itself is straightforward and doesn't introduce any immediate issues in this file, it's crucial to ensure that this update is consistently reflected across the entire application. This includes updating any components that may be using the old filter value, ensuring proper translations for the new label, and verifying that the filtering logic in other parts of the application is adjusted accordingly.
Consider the following to ensure a smooth integration of this change:
- Update the
EProjectsFilterenum in the relevant file to reflect this change.- Review and update any components or utilities that rely on the old
VERIFIEDfilter.- Update relevant documentation or comments that might reference the old filter option.
- If there are any analytics or logging related to filter usage, make sure they're updated to track the new filter option correctly.
These steps will help maintain consistency and prevent any potential bugs or confusion that could arise from this change.
src/apollo/types/types.ts (2)
92-92: LGTM! Consider grouping related enum values.The addition of
IS_GIVBACK_ELIGIBLEto theEProjectsFilterenum is consistent with the existing structure and naming conventions. It aligns well with the PR objectives to enhance filtering options for GIVback eligible projects.Consider grouping related enum values together for better readability. For instance, you could move
IS_GIVBACK_ELIGIBLEnext toVERIFIEDsince they both relate to project status/eligibility.
119-119: LGTM! Consider grouping related enum values.The addition of
IsGivbackEligibleto theECampaignFilterFieldenum is consistent with the existing structure and naming conventions. It aligns well with the PR objectives to enhance filtering options for GIVback eligible campaigns.Consider grouping related enum values together for better readability. For instance, you could move
IsGivbackEligiblenext toVerifiedsince they both relate to campaign status/eligibility.src/components/project-card/ProjectCard.tsx (1)
98-98: Approved: Enhanced footer visibility logicThe modification to include
isGivbackEligiblein thehasFootercondition is a good addition. It ensures that GIVbacks eligible projects display the footer, which aligns with the PR objectives for improved badges and tooltips.For improved readability, consider using an array with
some()method:const hasFooter = [activeStartedRound, verified, isGivbackEligible].some(Boolean);This approach makes it easier to add or remove conditions in the future.
lang/en.json (1)
1716-1719: Consider grouping related translations.While the new entries are correctly added and functioning, consider grouping related translations together for better organization and maintainability. For example, you could move these new tooltip entries near other tooltip-related translations in the file.
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (13)
- lang/ca.json (1 hunks)
- lang/en.json (1 hunks)
- lang/es.json (1 hunks)
- src/apollo/types/types.ts (2 hunks)
- src/components/IconWithToolTip.tsx (1 hunks)
- src/components/Tooltip.tsx (4 hunks)
- src/components/menu/FilterMenu.tsx (1 hunks)
- src/components/project-card/ProjectCard.tsx (1 hunks)
- src/components/views/project/ProjectBadges.tsx (3 hunks)
- src/components/views/project/ProjectGIVbackToast.tsx (1 hunks)
- src/components/views/project/projectActionCard/ProjectStats.tsx (1 hunks)
- src/components/views/userProfile/projectsTab/ProjectItem.tsx (1 hunks)
- src/helpers/url.tsx (1 hunks)
Additional comments not posted (19)
src/components/IconWithToolTip.tsx (5)
9-9: LGTM: Newdelayprop added correctly.The addition of the optional
delayprop to theIIconWithTooltipPropsinterface is well-implemented. It's correctly typed as an optional boolean, and the naming is clear and descriptive.
17-17: LGTM:delayprop correctly added with appropriate default value.The
delayprop is correctly added to the component's destructured props with a default value offalse. This ensures backward compatibility and maintains the expected behavior (no delay by default) for existing usage of the component.
48-50: LGTM: Proper cleanup of timeout in useEffect.The addition of timeout cleanup in the useEffect hook's cleanup function is a good practice. This ensures that any pending timeouts are properly cleared when the component unmounts or when the effect is re-run, preventing potential memory leaks.
56-57: LGTM: Event handlers correctly updated.The onMouseEnter and onMouseLeave event handlers are properly updated to use the new showTooltip and hideTooltip functions. This change correctly implements the delay functionality for showing the tooltip and ensures consistent behavior with the rest of the component changes.
Line range hint
1-80: Overall, excellent implementation of the delay functionality.The changes to the
IconWithTooltipcomponent are well-implemented and add valuable functionality. The newdelayprop and associated logic are correctly integrated into the component, with proper typing, default values, and cleanup. The code is clean and consistent with React best practices.The only suggestion for improvement is to consider making the delay time configurable, as mentioned in a previous comment. This would enhance the flexibility of the component for various use cases.
Great job on this implementation!
src/components/views/project/ProjectBadges.tsx (3)
15-15: LGTM: New import added for IconWithTooltipThe new import statement for
IconWithTooltipis correctly added and necessary for the tooltip functionality implemented in this file.
102-108: LGTM: New TooltipContent styled componentThe
TooltipContentstyled component is well-implemented and provides consistent styling for tooltip content across the project. The use of theme colors is appropriate, ensuring consistency with the overall design system.
Line range hint
1-109: Summary: Excellent enhancement of project badges with tooltipsThe changes in this file significantly improve the user experience by adding informative tooltips to the verified and GIVbacks eligible badges. The implementation is consistent, well-structured, and follows good practices. The new
TooltipContentstyled component ensures consistent styling across tooltips.A few minor suggestions were made to improve code readability and maintainability, but overall, this is a solid improvement to the
ProjectBadgescomponent.src/components/Tooltip.tsx (4)
128-128: LGTM! Consistent use of the new margin constant.The addition of
MARGINto the tooltip positioning calculation for mobile devices (non-bottom directions) is correct and consistent with the newly introduced constant.
134-134: LGTM! Consistent margin application for bottom direction.The addition of
MARGINto the tooltip positioning calculation for mobile devices (bottom direction) is correct and maintains consistency with other margin applications.
143-143: LGTM! Consistent margin application for desktop top and bottom directions.The addition of
MARGINto the tooltip positioning calculations for desktop devices (top and bottom directions) is correct and maintains consistency with other margin applications.Also applies to: 151-151
Line range hint
1-203: Overall, the changes improve tooltip positioning consistency.The introduction of the
MARGINconstant and its consistent application across various tooltip positioning scenarios is a positive change. It enhances code maintainability and ensures uniform spacing for tooltips in different directions and device types.Consider implementing the suggested minor improvements:
- Use a more descriptive name for the
MARGINconstant.- Extract the arrow size calculation into a separate constant for improved readability.
These changes will further enhance the code quality and maintainability of the Tooltip component.
src/components/views/userProfile/projectsTab/ProjectItem.tsx (1)
94-94: 🛠️ Refactor suggestionVerify the implications of changing verification criteria
The
isVerifiedprop of theVerificationBadgecomponent is now usingproject?.isGivbackEligibleinstead ofproject?.verified. This change shifts the verification criteria from a general verified status to GIVbacks eligibility.Please ensure that:
- This change is intentional and aligns with the new verification process.
- The UI and user experience have been updated to reflect this change in meaning.
- Other parts of the application that may depend on the project's verification status have been updated accordingly.
To verify the impact of this change, you can run the following script:
This will help identify other areas of the codebase that might need to be updated to maintain consistency with this change.
Consider renaming the
isVerifiedprop toisGivbackEligiblefor clarity and consistency with the data being passed. This would make the component's API more explicit about what it's actually representing.-<VerificationBadge - isVerified={project?.isGivbackEligible} - verificationStatus={project.projectVerificationForm?.status} -/> +<VerificationBadge + isGivbackEligible={project?.isGivbackEligible} + verificationStatus={project.projectVerificationForm?.status} +/>If you make this change, be sure to update the
VerificationBadgecomponent definition and all other uses of this component throughout the codebase.Verification successful
Verification Successful: No issues found with the verification criteria change
The
isVerifiedprop in theVerificationBadgecomponent is now correctly usingproject?.isGivbackEligible. Sinceproject?.verifiedis not used elsewhere in the codebase, this change does not introduce any inconsistencies or issues.Consider renaming the
isVerifiedprop toisGivbackEligiblefor improved clarity and consistency.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for other occurrences of 'verified' property and 'isGivbackEligible' property echo "Searching for 'verified' property usage:" rg --type typescript "project\?\.verified" echo "\nSearching for 'isGivbackEligible' property usage:" rg --type typescript "project\?\.isGivbackEligible" echo "\nSearching for 'VerificationBadge' component usage:" rg --type typescript "VerificationBadge"Length of output: 581
Script:
#!/bin/bash # Description: Corrected script to check for occurrences of 'verified' property, 'isGivbackEligible' property, and 'VerificationBadge' component in TypeScript files. echo "Searching for 'verified' property usage:" rg --type ts "project\?\.verified" echo "\nSearching for 'isGivbackEligible' property usage:" rg --type ts "project\?\.isGivbackEligible" echo "\nSearching for 'VerificationBadge' component usage:" rg --type ts "VerificationBadge"Length of output: 1177
src/components/views/project/ProjectGIVbackToast.tsx (1)
412-412: LGTM: Color change enhances visual appeal.The color change from
neutralColors.gray[900]tobrandColors.pinky[500]for theInnerLinkstyled component is approved. This update likely makes the links more visually appealing and noticeable within the component.src/apollo/types/types.ts (1)
92-92: Verify the usage of new enum values across the application.The additions of
IS_GIVBACK_ELIGIBLEtoEProjectsFilterandIsGivbackEligibletoECampaignFilterFieldenhance the filtering capabilities for GIVback eligible projects and campaigns. These changes are consistent with the existing code structure and align with the PR objectives.To ensure these changes are fully integrated, please verify:
- The usage of these new enum values in relevant components and services.
- Any necessary updates to API calls or GraphQL queries that might use these filters.
- The presence of corresponding UI elements to utilize these new filter options.
Run the following script to check for the usage of these new enum values:
This will help ensure that the new enum values are properly utilized throughout the application.
Also applies to: 119-119
Verification successful
Enum Usage Verified Successfully.
The new enum values
EProjectsFilter.IS_GIVBACK_ELIGIBLEandECampaignFilterField.IsGivbackEligibleare utilized in the following files:
src/helpers/url.tsxsrc/components/menu/FilterMenu.tsxThese integrations confirm that the enhancements to the filtering capabilities for GIVback eligible projects and campaigns are properly implemented and actively used throughout the application.
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for the usage of new enum values across the application # Search for usage of IS_GIVBACK_ELIGIBLE echo "Searching for usage of EProjectsFilter.IS_GIVBACK_ELIGIBLE:" rg --type typescript "EProjectsFilter\.IS_GIVBACK_ELIGIBLE" -g '!src/apollo/types/types.ts' # Search for usage of IsGivbackEligible echo "Searching for usage of ECampaignFilterField.IsGivbackEligible:" rg --type typescript "ECampaignFilterField\.IsGivbackEligible" -g '!src/apollo/types/types.ts'Length of output: 524
Script:
#!/bin/bash # Description: Check for the usage of new enum values across the application by searching .ts and .tsx files # Search for usage of IS_GIVBACK_ELIGIBLE echo "Searching for usage of EProjectsFilter.IS_GIVBACK_ELIGIBLE:" rg "EProjectsFilter\.IS_GIVBACK_ELIGIBLE" -g '*.ts' -g '*.tsx' --glob '!src/apollo/types/types.ts' # Search for usage of IsGivbackEligible echo "Searching for usage of ECampaignFilterField.IsGivbackEligible:" rg "ECampaignFilterField\.IsGivbackEligible" -g '*.ts' -g '*.tsx' --glob '!src/apollo/types/types.ts'Length of output: 681
src/components/project-card/ProjectCard.tsx (1)
98-98: Verify visual impact of expanded footer visibilityThe change to
hasFooterwill cause more projects (those that are GIVbacks eligible) to display the footer section. This could affect the overall layout and appearance of project cards, as well as their hover behavior.Please ensure that:
- The layout remains visually appealing for all types of projects (with and without footer).
- The hover behavior works correctly for newly footer-enabled cards.
- The change doesn't introduce any unintended consequences in the card's responsiveness.
Consider adding or updating visual regression tests to capture these changes.
lang/en.json (1)
1717-1718: New tooltip entries added for project verification status.Two new tooltip entries have been added to provide information about project verification status:
- "tooltip.vouched": Explains that the project has been verified as legitimate by Giveth Verifiers.
- "tooltip.givback_eligible": Indicates that the project has been verified as a Public Good by Giveth.
These additions enhance the user experience by providing clear explanations for different project statuses.
lang/es.json (1)
1717-1718: New tooltip entries added successfully.Two new tooltip entries have been added to the Spanish language file:
- "tooltip.vouched": "Este proyecto ha sido avalado como legítimo por los verificadores de Giveth"
- "tooltip.givback_eligible": "Este proyecto ha sido verificado como un Bien Público por Giveth"
The translations appear to be correct and follow the existing structure and naming conventions of the file. These new entries will provide additional context for users regarding project legitimacy and eligibility for GIVbacks.
lang/ca.json (1)
1717-1718: New tooltip entries added correctly.The two new tooltip entries have been added correctly to the JSON file:
- "tooltip.vouched": "Aquest projecte ha estat avalat com a legítim pels verificadors de Giveth"
- "tooltip.givback_eligible": "Aquest projecte ha estat verificat com un Bé Públic per Giveth"
These entries are properly formatted and placed at the end of the JSON object, maintaining the correct structure.
| @@ -68,7 +68,7 @@ export const ProjectStats = () => { | |||
| </IconWithTooltip> | |||
| </Flex> | |||
| <VerificationBadge | |||
| isVerified={projectData?.verified} | |||
| isVerified={projectData?.isGivbackEligible} | |||
There was a problem hiding this comment.
💡 Codebase verification
Inconsistent usage of verification properties detected across the codebase
The change from projectData?.verified to projectData?.isGivbackEligible in ProjectStats.tsx impacts multiple components:
-
projectData?.verifiedis used in:src/components/views/project/ProjectGIVbackToast.tsxsrc/components/views/project/ProjectTabs.tsxsrc/components/views/donate/DonatePageProjectDescription.tsx
-
projectData?.isGivbackEligibleis used in:src/components/views/project/ProjectGIVbackToast.tsxsrc/components/views/project/projectActionCard/ProjectStats.tsxsrc/components/views/donate/DonatePageProjectDescription.tsx
-
VerificationBadgecomponent is used in:src/components/views/project/projectActionCard/ProjectStats.tsxsrc/components/views/userProfile/projectsTab/ProjectItem.tsx
This scattered usage suggests potential inconsistencies in how project verification status is handled and displayed across the application. It's recommended to:
- Review and unify the verification criteria to ensure consistency.
- Update all affected components to use the new
isGivbackEligibleproperty if it aligns with the intended functionality. - Consider renaming the
VerificationBadgecomponent if its purpose is now specifically tied to GIVbacks eligibility. - Conduct thorough testing to ensure that the changes do not introduce bugs or inconsistencies in the user interface.
Analysis chain
Verify the implications of changing verification criteria
The change from projectData?.verified to projectData?.isGivbackEligible alters the criteria for determining a project's verification status. While this might align with new requirements, it raises several concerns:
- The new criteria (
isGivbackEligible) might not be a direct equivalent to the previousverifiedstatus. A project could potentially be verified but not eligible for GIVbacks, or vice versa. - The component name
VerificationBadgemight now be misleading if it's specifically showing GIVbacks eligibility rather than a general verification status. - Other parts of the application might still be using
projectData?.verified, which could lead to inconsistencies in how project verification is represented across the platform.
To ensure consistency and correct implementation, please run the following script:
This script will help identify other occurrences of these properties and the VerificationBadge component, allowing you to ensure consistent usage across the codebase.
Additionally, consider the following actions:
- Update the
VerificationBadgecomponent name or its internal logic to accurately reflect its new purpose if it's now specifically for GIVbacks eligibility. - Ensure that this change is documented in the project's documentation or changelog.
- Verify that this change aligns with the intended user experience and doesn't introduce confusion for users familiar with the previous verification system.
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for other occurrences of 'verified' and 'isGivbackEligible' in the codebase
echo "Searching for 'verified' property usage:"
rg 'projectData\?\.verified' --type typescript
echo "\nSearching for 'isGivbackEligible' property usage:"
rg 'projectData\?\.isGivbackEligible' --type typescript
echo "\nSearching for 'VerificationBadge' component usage:"
rg '<VerificationBadge' --type typescript
Length of output: 592
Script:
#!/bin/bash
# Description: Check for other occurrences of 'verified' and 'isGivbackEligible' in the codebase
echo "Searching for 'verified' property usage:"
rg 'projectData\?\.verified' --type typescriptreact
echo "\nSearching for 'isGivbackEligible' property usage:"
rg 'projectData\?\.isGivbackEligible' --type typescriptreact
echo "\nSearching for 'VerificationBadge' component usage:"
rg '<VerificationBadge' --type typescriptreact
Length of output: 622
Script:
#!/bin/bash
# Description: Check for other occurrences of 'verified' and 'isGivbackEligible' in the codebase within .ts and .tsx files
echo "Searching for 'verified' property usage in .ts and .tsx files:"
rg 'projectData\?\.verified' --glob '*.ts' --glob '*.tsx'
echo "\nSearching for 'isGivbackEligible' property usage in .ts and .tsx files:"
rg 'projectData\?\.isGivbackEligible' --glob '*.ts' --glob '*.tsx'
echo "\nSearching for 'VerificationBadge' component usage in .ts and .tsx files:"
rg '<VerificationBadge' --glob '*.ts' --glob '*.tsx'
Length of output: 1415
| label: { id: 'label.isGivbackEligible' }, | ||
| value: EProjectsFilter.IS_GIVBACK_ELIGIBLE, |
There was a problem hiding this comment.
💡 Codebase verification
Issues Found:
EProjectsFilter.VERIFIEDis still used insrc/helpers/url.tsx.
Please update or remove this usage to ensure consistency with the new filter value.
Analysis chain
LGTM! Verify translations and update related components.
The change from "vouched" to "isGivbackEligible" aligns well with the PR objectives. This update shifts the focus from project verification to GIVback eligibility, which seems to be the intended behavior.
To ensure consistency across the codebase:
- Verify that the new label
'label.isGivbackEligible'is properly translated in all language files. - Check other components that might be using the old
EProjectsFilter.VERIFIEDvalue and update them accordingly.
Run the following script to help with these verifications:
This script will help identify any inconsistencies or areas that might need updating due to this change.
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for the new label in translation files
echo "Checking for 'label.isGivbackEligible' in translation files:"
rg --type json "label\.isGivbackEligible"
echo "\nChecking for usages of EProjectsFilter.VERIFIED:"
rg --type typescript "EProjectsFilter\.VERIFIED"
echo "\nChecking for usages of EProjectsFilter.IS_GIVBACK_ELIGIBLE:"
rg --type typescript "EProjectsFilter\.IS_GIVBACK_ELIGIBLE"
Length of output: 800
Script:
#!/bin/bash
# Check for the new label in translation files
echo "Checking for 'label.isGivbackEligible' in translation files:"
rg --type json "label\.isGivbackEligible"
echo "\nChecking for usages of EProjectsFilter.VERIFIED in TypeScript files:"
rg --type ts "EProjectsFilter\.VERIFIED"
echo "\nChecking for usages of EProjectsFilter.IS_GIVBACK_ELIGIBLE in TypeScript files:"
rg --type ts "EProjectsFilter\.IS_GIVBACK_ELIGIBLE"
Length of output: 1014
Summary by CodeRabbit
Release Notes
New Features
Bug Fixes
Style