Repository navigation
Feedbacks resolved 19 Dec - #48
Conversation
|
Warning Rate limit exceeded@dev-rathore has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 22 minutes and 43 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (8)
WalkthroughThis pull request introduces a series of layout and functional modifications across multiple components in the collaboration and explore influencers sections. The changes primarily focus on adjusting component widths from 768 to 640 pixels at the Changes
Sequence DiagramsequenceDiagram
participant User
participant ExploreInfluencers
participant CollaborationFilter
participant InfluencerHook
User->>ExploreInfluencers: Open Explore Page
ExploreInfluencers->>CollaborationFilter: Open Filter Modal
User->>CollaborationFilter: Set Filtering Criteria
CollaborationFilter->>ExploreInfluencers: Apply Filters
ExploreInfluencers->>InfluencerHook: Fetch Filtered Influencers
InfluencerHook-->>ExploreInfluencers: Return Filtered Results
ExploreInfluencers->>User: Display Filtered Influencers
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 (
|
There was a problem hiding this comment.
Actionable comments posted: 3
🔭 Outside diff range comments (3)
components/explore-influencers/index.tsx (2)
Line range hint
83-116: Complete the implementation of all filter criteria.The filtering logic has several commented-out conditions for followers, reach, and engagement ranges. This suggests incomplete implementation of the intended filtering functionality.
- Uncomment and implement the range filters
- Consider memoizing the filter function to optimize performance
const filterInfluencers = () => { const newFilteredInfluencers = influencers.filter((influencer) => { const isCollaborationTypeMatch = currentCollaborationType === "All" || influencer.profile?.category?.includes(currentCollaborationType); - // const isFollowersRangeMatch = - // Number(influencer.backend?.followers) >= currentFollowersRange[0] && - // Number(influencer.backend?.followers) <= currentFollowersRange[1]; - // const isReachRangeMatch = - // Number(influencer.backend?.reach) >= currentReachRange[0] && - // Number(influencer.backend?.reach) <= currentReachRange[1]; - // const isEngagementRangeMatch = - // Number(influencer.backend?.engagement) >= currentEngagementRange[0] && - // Number(influencer.backend?.engagement) <= currentEngagementRange[1]; + const isFollowersRangeMatch = + Number(influencer.backend?.followers) >= currentFollowersRange[0] && + Number(influencer.backend?.followers) <= currentFollowersRange[1]; + const isReachRangeMatch = + Number(influencer.backend?.reach) >= currentReachRange[0] && + Number(influencer.backend?.reach) <= currentReachRange[1]; + const isEngagementRangeMatch = + Number(influencer.backend?.engagement) >= currentEngagementRange[0] && + Number(influencer.backend?.engagement) <= currentEngagementRange[1]; const isSearchQueryMatch = influencer.name .toLowerCase() .includes(searchQuery.toLowerCase()); return ( isCollaborationTypeMatch && - // isFollowersRangeMatch && - // isReachRangeMatch && - // isEngagementRangeMatch && + isFollowersRangeMatch && + isReachRangeMatch && + isEngagementRangeMatch && isSearchQueryMatch ); }); setFilteredInfluencers(newFilteredInfluencers); };Also consider memoizing the filter function:
const filterInfluencers = useMemo(() => { return influencers.filter((influencer) => { // ... filtering logic ... }); }, [ influencers, currentCollaborationType, currentFollowersRange, currentReachRange, currentEngagementRange, searchQuery ]);
Line range hint
207-211: Optimize FlatList performance and implement infinite scroll.While the width adjustment to 640px aligns with the PR objectives, the FlatList implementation could benefit from performance optimizations.
Add the following optimizations to improve list performance and user experience:
<FlatList data={filteredInfluencers} renderItem={({ item, index }) => ( <InfluencerCard key={index} type="explore" ToggleModal={ToggleModal} influencer={item} openProfile={(influencer) => { setSelectedInfluencer(influencer); bottomSheetModalRef.current?.present(); }} setSelectedInfluencer={setSelectedInfluencer} /> )} keyExtractor={(item, index) => index.toString()} + windowSize={5} + maxToRenderPerBatch={10} + removeClippedSubviews={true} + initialNumToRender={10} + onEndReached={() => { + if (!isLoadingMore) { + fetchInfluencers(true); + } + }} + onEndReachedThreshold={0.5} + ListFooterComponent={() => isLoadingMore && ( + <ActivityIndicator size="small" color={Colors(theme).primary} /> + )} style={{ width: xl ? 640 : '100%', marginHorizontal: "auto", }} />components/collaboration/collaboration-details/InvitationsTabContent.tsx (1)
Line range hint
1-241: Consider these essential improvements for maintainability and type safety
- Add proper TypeScript interfaces instead of using 'any':
interface InvitationsTabContentProps { pageID: string; } interface Influencer { id: string; profileImage: string; // ... other properties }
- Consider extracting the invitation modal into a separate component to improve maintainability:
interface InvitationModalProps { visible: boolean; onClose: () => void; onSubmit: (message: string) => Promise<void>; isLoading: boolean; }
- Enhance error handling in handleCollaborationInvite:
} catch (error) { - console.error(error); + const errorMessage = error instanceof Error ? error.message : 'Unknown error occurred'; + console.error('Failed to send invitation:', errorMessage); Toaster.error("Failed to send invitation"); }
🧹 Nitpick comments (5)
components/collaboration/collaboration-details/ApplicationsTabContent.tsx (1)
Line range hint
1-150: Consider improving type safety and error handling.While not directly related to the current changes, the following improvements would enhance maintainability:
- Add proper error handling for Firebase operations
- Replace 'any' types with proper interfaces
- Define props interface
Example implementation:
interface Application { id: string; userId: string; // ... other application fields } interface Influencer extends Application { applicationID: string; // ... other influencer fields } interface ApplicationsTabContentProps { pageID: string; collaboration: any; // Define collaboration interface } const ApplicationsTabContent: React.FC<ApplicationsTabContentProps> = ({ pageID, collaboration }) => { const [influencers, setInfluencers] = useState<Influencer[]>([]); // ... rest of the implementation with proper error handling };components/collaboration/collaboration-details/OverviewTabContent.tsx (1)
Line range hint
42-106: Consider improvements to content structure and data handling.While not directly related to the current changes, there are opportunities for improvement:
- The description is duplicated in both "Ad Description" and "About Brand" sections
- Platform value is hardcoded to "Instagram"
- Payment verification shows a hardcoded "True"
Consider these improvements for a future update:
- <Paragraph style={styles.brandName}> - {" "} - {collaboration.description} - </Paragraph> + <Paragraph style={styles.brandName}> + {collaboration.adDescription} + </Paragraph> // Later in the file - <Paragraph style={styles.paragraph}>Instagram</Paragraph> + <Paragraph style={styles.paragraph}> + {collaboration.platform} + </Paragraph> // And - <Paragraph style={styles.brandName}> - Payment Verified: True - </Paragraph> + <Paragraph style={styles.brandName}> + Payment Verified: {collaboration.paymentVerified ? "Yes" : "No"} + </Paragraph>hooks/request/use-influencers.tsx (1)
Line range hint
25-40: Consider adding error boundaries for snapshot errors.The error handling only logs to console, which might not be sufficient for production.
Consider adding proper error boundaries or error state management:
const [influencers, setInfluencers] = useState<any[]>([]); + const [error, setError] = useState<Error | null>(null); const fetchInitialInfluencers = () => { setIsInitialLoading(true); + setError(null); // ... onSnapshot( influencersQuery, (snapshot: QuerySnapshot) => { // ... }, error => { console.error("Error fetching influencers:", error); + setError(error); setIsInitialLoading(false); } ); };components/explore-influencers/index.tsx (2)
Line range hint
63-82: Consider optimizing the data fetching implementation.The current implementation has several areas for improvement:
- Using
onSnapshotfor real-time updates might be unnecessary for an explore page and could impact performance/costs.- Missing error handling for Firestore query failures.
- No pagination implementation could lead to performance issues with large datasets.
Consider:
- Replacing
onSnapshotwithgetDocsfor one-time fetching- Implementing pagination using
startAfterandlimit- Adding proper error handling
- Implementing a loading state for pagination
Example implementation:
const [lastDoc, setLastDoc] = useState<DocumentSnapshot | null>(null); const [isLoadingMore, setIsLoadingMore] = useState(false); const fetchInfluencers = async (loadMore = false) => { try { setIsLoading(!loadMore); setIsLoadingMore(loadMore); const influencersRef = collection(FirestoreDB, "users"); let q = query( influencersRef, where("profile.completionPercentage", ">=", 60), limit(20) ); if (loadMore && lastDoc) { q = query(q, startAfter(lastDoc)); } const snapshot = await getDocs(q); const fetchedInfluencers = snapshot.docs.map((doc) => ({ ...doc.data(), id: doc.id, } as User)); setLastDoc(snapshot.docs[snapshot.docs.length - 1]); setInfluencers(prev => loadMore ? [...prev, ...fetchedInfluencers] : fetchedInfluencers); } catch (error) { console.error('Error fetching influencers:', error); // Handle error appropriately } finally { setIsLoading(false); setIsLoadingMore(false); } };
Line range hint
274-307: Enhance modal accessibility and user experience.The bottom sheet modals need accessibility improvements and better handling of platform-specific behaviors.
Consider the following improvements:
<BottomSheetModal ref={bottomSheetModalRef} index={2} snapPoints={snapPoints} backdropComponent={renderBackdrop} enablePanDownToClose={true} containerOffset={containerOffset} topInset={insets.top} bottomInset={insets.bottom} + accessibilityLabel="Influencer Profile Modal" + accessibilityHint="Shows detailed information about the selected influencer" + android_keyboardInputMode="adjustResize" > <BottomSheetScrollView + accessibilityRole="scrollable" + accessibilityLabel="Influencer Profile Content" > <ProfileBottomSheet influencer={selectedInfluencer as User} theme={theme} isBrandsApp={true} /> </BottomSheetScrollView> </BottomSheetModal>Also add hardware back button handling:
useEffect(() => { const backHandler = BackHandler.addEventListener('hardwareBackPress', () => { if (bottomSheetModalRef.current?.isActive()) { bottomSheetModalRef.current?.close(); return true; } return false; }); return () => backHandler.remove(); }, []);
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (8)
components/collaboration/collaboration-details/ApplicationsTabContent.tsx(1 hunks)components/collaboration/collaboration-details/InvitationsTabContent.tsx(1 hunks)components/collaboration/collaboration-details/OverviewTabContent.tsx(1 hunks)components/explore-influencers/index.tsx(1 hunks)components/ui/carousel/carousel.web.tsx(2 hunks)components/ui/carousel/render-media-item.tsx(1 hunks)hooks/request/use-influencers.tsx(2 hunks)styles/tab1.styles.tsx(1 hunks)
🔇 Additional comments (8)
components/collaboration/collaboration-details/ApplicationsTabContent.tsx (1)
110-110: LGTM! Width adjustment aligns with design standardization.
The width adjustment to 640px at xl breakpoint maintains consistency with similar changes in related components.
Let's verify the width consistency across other components:
✅ Verification successful
Width adjustment is consistent across all collaboration detail components
The verification confirms that all three components in the collaboration-details directory (ApplicationsTabContent.tsx, InvitationsTabContent.tsx, and OverviewTabContent.tsx) consistently use width: xl ? 640 : '100%' with identical styling patterns including marginHorizontal: "auto" and paddingBottom: 16.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check width values in related components to ensure consistency
# Expected: All components should use width: 640 at xl breakpoint
# Search for width declarations in related components
rg -A 2 -B 2 'width:.*xl.*?' components/collaboration/collaboration-details/
Length of output: 1562
components/collaboration/collaboration-details/OverviewTabContent.tsx (1)
34-34: Width adjustment aligns with design system changes.
The width adjustment to 640px at xl breakpoint maintains consistency with similar changes in ApplicationsTabContent and InvitationsTabContent components.
Let's verify this width adjustment across all collaboration detail components:
✅ Verification successful
Width adjustment is consistently implemented across collaboration detail components
The verification confirms that all three components in the collaboration details section (OverviewTabContent.tsx, InvitationsTabContent.tsx, and ApplicationsTabContent.tsx) consistently implement the 640px width at xl breakpoint with a responsive fallback to 100% width.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify width consistency across collaboration detail components
# Expected: All components should use 640px width at xl breakpoint
# Search for width definitions in collaboration detail components
rg -U "width:.*\?" components/collaboration/collaboration-details/
Length of output: 391
components/ui/carousel/carousel.web.tsx (3)
7-9: LGTM! Appropriate imports for navigation enhancement
The new imports properly support the navigation buttons while maintaining theme consistency.
69-83: LGTM! Clean and well-structured mapping implementation
The data mapping is properly implemented with appropriate key usage and prop passing.
Line range hint 21-22: Verify video playback behavior during slide transitions
Please ensure that videos are properly paused when switching between slides to prevent multiple videos from playing simultaneously.
✅ Verification successful
Video playback is properly handled during slide transitions
The codebase already implements proper video handling during slide transitions in the carousel component. Specifically in carousel.tsx, the handleIndexChange function ensures that:
- All videos are reset to the beginning (
seek(0)) - Video playback is stopped (
setIsPlaying(false)) - This is applied to all video refs when slides change
The implementation uses a videoRefs object to track all video instances and properly manages their state during transitions, preventing simultaneous playback of multiple videos.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for video pause/play handling in RenderMediaItem
ast-grep --pattern 'useEffect($$$) {
$$$
pause($$$)
$$$
}'
# Look for slide change handlers
rg -A 5 'onIndexChanged|onSlideChange'
Length of output: 107
Script:
#!/bin/bash
# Search for video-related code in the carousel component and its related files
rg -A 10 "video" --type tsx --type ts
# Search for useEffect hooks that might handle video state
ast-grep --pattern 'useEffect(() => {
$$$
})'
# Look for any slide change event handlers in carousel files
fd carousel --type f --exec rg -A 5 "onChange|onSlide|onSwipe"
Length of output: 180
Script:
#!/bin/bash
# Search for video-related code in the carousel component
rg -A 10 "video" components/ui/carousel/
# Search for useEffect hooks in carousel files
rg -A 10 "useEffect" components/ui/carousel/
# Look for any slide change event handlers in carousel files
rg -A 5 "onChange|onSlide|onSwipe" components/ui/carousel/
Length of output: 6099
styles/tab1.styles.tsx (1)
50-55: LGTM! Clean button style implementation.
The new buttonWrapper style follows good practices with theme-aware colors and consistent styling values.
components/collaboration/collaboration-details/InvitationsTabContent.tsx (2)
158-158: LGTM: Width standardization implemented correctly
The width adjustment to 640px at xl breakpoint aligns with the standardization effort across components while maintaining responsive behavior.
Line range hint 1-241: Verify integration with shared components
Please ensure that the width adjustment doesn't affect the layout of shared components:
- InfluencerCard
- BottomSheetActions
- EmptyState
✅ Verification successful
Based on the code analysis, I can now provide the final response:
Width adjustments are safely implemented and won't affect shared components
The width changes in InvitationsTabContent are safely contained and won't affect the shared components:
- InfluencerCard handles its own width through its parent container and uses relative width styling
- BottomSheetActions uses Modal and full-screen overlay, independent of parent width
- EmptyState is a flexible component that adapts to its container width through its View wrapper
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for other uses of these shared components to verify consistent width handling
# Check InfluencerCard usage
ast-grep --pattern 'InfluencerCard $$$'
# Check BottomSheetActions usage
ast-grep --pattern 'BottomSheetActions $$$'
# Check EmptyState usage
ast-grep --pattern 'EmptyState $$$'
Length of output: 125
Script:
#!/bin/bash
# Let's try a different approach using ripgrep to find component usage patterns
# Check InfluencerCard usage
echo "=== InfluencerCard Usage ==="
rg -l "InfluencerCard" --type tsx --type jsx
# Check BottomSheetActions usage
echo -e "\n=== BottomSheetActions Usage ==="
rg -l "BottomSheetActions" --type tsx --type jsx
# Check EmptyState usage
echo -e "\n=== EmptyState Usage ==="
rg -l "EmptyState" --type tsx --type jsx
# Check for width-related props or styles in these components
echo -e "\n=== Width Related Implementations ==="
rg "style.*width|width.*style" --type tsx --type jsx components/InfluencerCard.tsx components/BottomSheetActions.tsx components/ui/empty-state.tsx
Length of output: 699
Script:
#!/bin/bash
# Let's try without file type specifications since tsx/jsx are not recognized
# Check InfluencerCard usage and implementation
echo "=== InfluencerCard Usage ==="
rg -l "InfluencerCard"
# Get InfluencerCard implementation details
echo -e "\n=== InfluencerCard Implementation ==="
fd "InfluencerCard" --exec cat {}
# Check BottomSheetActions usage and implementation
echo -e "\n=== BottomSheetActions Usage ==="
rg -l "BottomSheetActions"
# Get BottomSheetActions implementation details
echo -e "\n=== BottomSheetActions Implementation ==="
fd "BottomSheetActions" --exec cat {}
# Check EmptyState usage and implementation
echo -e "\n=== EmptyState Usage ==="
rg -l "EmptyState"
# Get EmptyState implementation details
echo -e "\n=== EmptyState Implementation ==="
fd "empty-state" --exec cat {}
Length of output: 22166
Script:
#!/bin/bash
# Let's get the EmptyState component implementation specifically
echo "=== EmptyState Component Implementation ==="
fd "index.tsx" --full-path --base-directory components/ui/empty-state --exec cat {}
# Let's check width-related styles in the EmptyState styles
echo -e "\n=== EmptyState Styles ==="
fd "styles" --full-path --base-directory components/ui/empty-state --exec cat {}
Length of output: 2026
| pagingEnabled | ||
| showsButtons={data.length > 1} | ||
| nextButton={ | ||
| <View | ||
| style={styles.buttonWrapper} | ||
| > | ||
| <FontAwesomeIcon | ||
| icon={faChevronRight} | ||
| size={20} | ||
| color={Colors(theme).black} | ||
| /> | ||
| </View> | ||
| } | ||
| prevButton={ | ||
| <View | ||
| style={styles.buttonWrapper} | ||
| > | ||
| <FontAwesomeIcon | ||
| icon={faChevronLeft} | ||
| size={20} | ||
| color={Colors(theme).black} | ||
| /> | ||
| </View> | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Add accessibility attributes to navigation buttons
While the navigation implementation looks good, it should be enhanced with accessibility attributes for better usability.
Apply these improvements to both button Views:
<View
style={styles.buttonWrapper}
+ accessibilityRole="button"
+ accessibilityLabel="Next slide"
+ tabIndex={0}
> <View
style={styles.buttonWrapper}
+ accessibilityRole="button"
+ accessibilityLabel="Previous slide"
+ tabIndex={0}
>📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| pagingEnabled | |
| showsButtons={data.length > 1} | |
| nextButton={ | |
| <View | |
| style={styles.buttonWrapper} | |
| > | |
| <FontAwesomeIcon | |
| icon={faChevronRight} | |
| size={20} | |
| color={Colors(theme).black} | |
| /> | |
| </View> | |
| } | |
| prevButton={ | |
| <View | |
| style={styles.buttonWrapper} | |
| > | |
| <FontAwesomeIcon | |
| icon={faChevronLeft} | |
| size={20} | |
| color={Colors(theme).black} | |
| /> | |
| </View> | |
| } | |
| pagingEnabled | |
| showsButtons={data.length > 1} | |
| nextButton={ | |
| <View | |
| style={styles.buttonWrapper} | |
| accessibilityRole="button" | |
| accessibilityLabel="Next slide" | |
| tabIndex={0} | |
| > | |
| <FontAwesomeIcon | |
| icon={faChevronRight} | |
| size={20} | |
| color={Colors(theme).black} | |
| /> | |
| </View> | |
| } | |
| prevButton={ | |
| <View | |
| style={styles.buttonWrapper} | |
| accessibilityRole="button" | |
| accessibilityLabel="Previous slide" | |
| tabIndex={0} | |
| > | |
| <FontAwesomeIcon | |
| icon={faChevronLeft} | |
| size={20} | |
| color={Colors(theme).black} | |
| /> | |
| </View> | |
| } |
| shouldPlay | ||
| useNativeControls | ||
| usePoster | ||
| posterSource={imageUrl(require("@/assets/images/placeholder-image.jpg"))} |
There was a problem hiding this comment.
💡 Codebase verification
🛠️ Refactor suggestion
Auto-play and placeholder image implementation need refinement
The review findings are valid based on the codebase analysis:
- The
shouldPlayprop is only used in this component and lacks an explicit default value, which could lead to unexpected auto-play behavior - The placeholder image is properly managed as a constant in the codebase (used in multiple components), but the implementation here bypasses the constant
PLACEHOLDER_IMAGEfromconstants/Placeholder.ts
Consider these improvements:
- shouldPlay
+ shouldPlay={false}
- posterSource={imageUrl(require("@/assets/images/placeholder-image.jpg"))}
+ posterSource={imageUrl(PLACEHOLDER_IMAGE)}🔗 Analysis chain
Review auto-play behavior and poster implementation.
A few concerns with the current implementation:
- Auto-playing videos (
shouldPlay) could impact performance and user experience, especially with multiple videos in the carousel - Hardcoded placeholder image path makes maintenance harder
Let's verify the placeholder image usage:
Consider these improvements:
- shouldPlay
+ shouldPlay={false}
- posterSource={imageUrl(require("@/assets/images/placeholder-image.jpg"))}
+ posterSource={imageUrl(item.thumbnailUrl || require("@/assets/images/placeholder-image.jpg"))}🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if the placeholder image is used elsewhere
rg -l "placeholder-image.jpg"
Length of output: 151
Script:
#!/bin/bash
# Let's check how the placeholder image is used in other files
rg "placeholder-image.jpg" -B 2 -A 2
Length of output: 1230
Script:
#!/bin/bash
# Let's check how video autoplay is handled in other carousel or video components
rg "shouldPlay" -B 2 -A 2
# Also check if there's a thumbnailUrl property being used
ast-grep --pattern 'thumbnailUrl'
Length of output: 401
| const influencerRef = collection(FirestoreDB, "users"); | ||
| const influencersQuery = query( | ||
| influencerRef, | ||
| where("profile.completionPercentage", ">=", 60), |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Refactor duplicate filter condition.
The completion percentage filter condition is duplicated in both query functions. This could lead to maintenance issues if the threshold needs to change.
Consider extracting the filter condition:
+ const COMPLETION_THRESHOLD = 60;
+ const completionFilter = where("profile.completionPercentage", ">=", COMPLETION_THRESHOLD);
const fetchInitialInfluencers = () => {
const influencersQuery = query(
influencerRef,
- where("profile.completionPercentage", ">=", 60),
+ completionFilter,
orderBy("name"),
limit(PAGE_SIZE)
);
// ...
};
const fetchMoreInfluencers = async () => {
const influencersQuery = query(
influencerRef,
- where("profile.completionPercentage", ">=", 60),
+ completionFilter,
orderBy("name"),
startAfter(lastVisible),
limit(PAGE_SIZE)
);
// ...
};Also applies to: 58-58
Summary by CodeRabbit
New Features
Bug Fixes
Style
Chores