Switch from static app.json to dynamic app.config.ts and enhance push notifications#12
Switch from static app.json to dynamic app.config.ts and enhance push notifications#12
Conversation
…d with existing leaderboard entries from the global leaderboard
|
""" WalkthroughThe changes replace the static Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant SettingsScreen
participant usePushNotifications
participant notificationsPermissionsLookup
participant Linking
User->>SettingsScreen: Opens settings
SettingsScreen->>usePushNotifications: Get notification status
usePushNotifications->>notificationsPermissionsLookup: Check system notification permission
notificationsPermissionsLookup-->>usePushNotifications: Returns isEnabled
usePushNotifications-->>SettingsScreen: Returns status, toggle, systemNotificationsEnabled
alt systemNotificationsEnabled is false
SettingsScreen->>User: Show hint and "Open settings" button
User->>SettingsScreen: Presses "Open settings"
SettingsScreen->>Linking: openSettings()
else systemNotificationsEnabled is true
SettingsScreen->>User: Show toggle as enabled/disabled
end
Possibly related PRs
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
✅ Files skipped from review due to trivial changes (1)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
✨ Finishing Touches
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. 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: 0
🧹 Nitpick comments (1)
convex/leaderboards/queries.ts (1)
172-195: Consider adding duplicate prevention logic.The mutation logic is correct, but it doesn't check for existing entries in the target leaderboard. This could lead to duplicate entries if the mutation is called multiple times for the same user and leaderboard.
Consider adding a check to prevent duplicate entries:
for await (const entry of existingLeaderboardEntriesQuery) { + // Check if entry already exists in target leaderboard + const existingEntry = await ctx.db + .query('leaderboardEntries') + .withIndex('by_leaderboard_user_puzzle', (q) => + q.eq('leaderboardId', leaderboardId) + .eq('userId', userId) + .eq('puzzleId', entry.puzzleId) + ) + .unique(); + + if (existingEntry) continue; + await ctx.db.insert('leaderboardEntries', { leaderboardId: leaderboardId, userId, puzzleId: entry.puzzleId, score: entry.score, }); }Note: This assumes an index
by_leaderboard_user_puzzleexists. If not, you'd need to add it to your schema.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (5)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yamlsrc/assets/images/petka-app-icon-android-adaptive.pngis excluded by!**/*.pngsrc/assets/images/petka-app-icon-dev.pngis excluded by!**/*.pngsrc/assets/images/petka-app-icon-splash.pngis excluded by!**/*.pngsrc/assets/images/petka-app-icon.pngis excluded by!**/*.png
📒 Files selected for processing (15)
.github/workflows/main.yml(0 hunks)app.config.ts(1 hunks)app.json(0 hunks)convex/leaderboards/queries.ts(4 hunks)convex/notifications/queries.ts(0 hunks)eas.json(1 hunks)package.json(2 hunks)src/__tests__/settings.test.tsx(6 hunks)src/app/(authenticated)/settings.tsx(4 hunks)src/app/_layout.tsx(5 hunks)src/components/ui/Button/Button.tsx(6 hunks)src/components/ui/Text/Text.tsx(1 hunks)src/hooks/usePushNotifications/usePushNotifications.ts(2 hunks)src/utils/notifications.test.ts(2 hunks)src/utils/notifications.ts(1 hunks)
💤 Files with no reviewable changes (3)
- .github/workflows/main.yml
- convex/notifications/queries.ts
- app.json
🧰 Additional context used
🧠 Learnings (10)
📓 Common learnings
Learnt from: zigcccc
PR: zigcccc/petka-app#7
File: src/hooks/useUser/useUser.test.ts:183-186
Timestamp: 2025-07-07T06:21:28.647Z
Learning: The user (zigcccc) is comfortable with using `@ts-expect-error` TypeScript error suppression in test code, considering it acceptable for test data even when it compromises type safety.
Learnt from: zigcccc
PR: zigcccc/petka-app#9
File: src/app/_layout.tsx:94-0
Timestamp: 2025-07-09T12:59:59.807Z
Learning: In src/app/_layout.tsx, the useEffect hook that handles user identification and push notification registration intentionally omits `notifications` and `posthog` from the dependency array. The user (zigcccc) wants this effect to only run when the `user` object changes, not when other objects change, for performance and behavior control reasons.
src/components/ui/Text/Text.tsx (1)
Learnt from: zigcccc
PR: zigcccc/petka-app#11
File: src/components/ui/Button/Button.tsx:111-128
Timestamp: 2025-07-10T10:48:53.621Z
Learning: In the Button component (src/components/ui/Button/Button.tsx), the text color (styles.text.color) is always defined and never null or undefined, so fallback values like empty strings in ButtonIcon are safe to use as they will never be reached.
src/app/_layout.tsx (2)
Learnt from: zigcccc
PR: zigcccc/petka-app#9
File: src/app/_layout.tsx:94-0
Timestamp: 2025-07-09T12:59:59.807Z
Learning: In src/app/_layout.tsx, the useEffect hook that handles user identification and push notification registration intentionally omits `notifications` and `posthog` from the dependency array. The user (zigcccc) wants this effect to only run when the `user` object changes, not when other objects change, for performance and behavior control reasons.
Learnt from: zigcccc
PR: zigcccc/petka-app#7
File: src/app/(authenticated)/play/daily-puzzle-solved.tsx:66-79
Timestamp: 2025-07-07T06:08:49.592Z
Learning: In src/app/(authenticated)/play/daily-puzzle-solved.tsx, the user is fine with the iOS-only ActionSheetIOS sharing implementation for now, treating it as a work-in-progress item that may be addressed later for cross-platform compatibility.
src/components/ui/Button/Button.tsx (6)
Learnt from: zigcccc
PR: zigcccc/petka-app#11
File: src/components/ui/Button/Button.tsx:111-128
Timestamp: 2025-07-10T10:48:53.621Z
Learning: In the Button component (src/components/ui/Button/Button.tsx), the text color (styles.text.color) is always defined and never null or undefined, so fallback values like empty strings in ButtonIcon are safe to use as they will never be reached.
Learnt from: zigcccc
PR: zigcccc/petka-app#11
File: src/context/ActionSheet/ActionSheet.provider.tsx:96-98
Timestamp: 2025-07-10T10:59:21.150Z
Learning: The Button component in src/components/ui/Button/Button.tsx automatically sets accessibilityRole="button" on its internal Pressable component, so there's no need to manually add this accessibility prop when using the Button component.
Learnt from: zigcccc
PR: zigcccc/petka-app#11
File: src/context/ActionSheet/ActionSheet.provider.tsx:96-98
Timestamp: 2025-07-10T10:59:21.150Z
Learning: The Button component in src/components/ui/Button/Button.tsx automatically adds accessibilityRole="button" to all button instances, so there's no need to manually add this prop when using the Button component.
Learnt from: zigcccc
PR: zigcccc/petka-app#11
File: src/__tests__/index.test.tsx:36-43
Timestamp: 2025-07-10T10:44:20.098Z
Learning: The Button.Icon component in src/components/ui/Button/Button.tsx automatically adds testID and accessibilityLabel props to icon elements using the pattern `icon-${iconName}`, where iconName is extracted from the icon's name prop. This ensures all icon buttons have proper accessibility labels without requiring manual prop addition.
Learnt from: zigcccc
PR: zigcccc/petka-app#11
File: src/__tests__/index.test.tsx:36-43
Timestamp: 2025-07-10T10:44:20.098Z
Learning: The Button.Icon component in src/components/ui/Button/Button.tsx automatically adds testID and accessibilityLabel props to icon elements using the pattern `icon-${iconName}`, where iconName is extracted from the icon's name prop. This ensures all icon buttons have proper accessibility labels without requiring manual prop addition.
Learnt from: zigcccc
PR: zigcccc/petka-app#11
File: src/context/ActionSheet/ActionSheet.provider.tsx:77-90
Timestamp: 2025-07-10T10:59:04.202Z
Learning: In src/context/ActionSheet/ActionSheet.provider.tsx, the user (zigcccc) prefers to keep action buttons as buttons rather than menu items, maintaining the default button accessibility role instead of overriding it with "menuitem". This is semantically correct for action sheet buttons.
src/utils/notifications.ts (1)
Learnt from: zigcccc
PR: zigcccc/petka-app#9
File: src/app/_layout.tsx:94-0
Timestamp: 2025-07-09T12:59:59.807Z
Learning: In src/app/_layout.tsx, the useEffect hook that handles user identification and push notification registration intentionally omits `notifications` and `posthog` from the dependency array. The user (zigcccc) wants this effect to only run when the `user` object changes, not when other objects change, for performance and behavior control reasons.
src/app/(authenticated)/settings.tsx (4)
Learnt from: zigcccc
PR: zigcccc/petka-app#9
File: src/app/_layout.tsx:94-0
Timestamp: 2025-07-09T12:59:59.807Z
Learning: In src/app/_layout.tsx, the useEffect hook that handles user identification and push notification registration intentionally omits `notifications` and `posthog` from the dependency array. The user (zigcccc) wants this effect to only run when the `user` object changes, not when other objects change, for performance and behavior control reasons.
Learnt from: zigcccc
PR: zigcccc/petka-app#7
File: src/app/(authenticated)/play/daily-puzzle-solved.tsx:66-79
Timestamp: 2025-07-07T06:08:49.592Z
Learning: In src/app/(authenticated)/play/daily-puzzle-solved.tsx, the user is fine with the iOS-only ActionSheetIOS sharing implementation for now, treating it as a work-in-progress item that may be addressed later for cross-platform compatibility.
Learnt from: zigcccc
PR: zigcccc/petka-app#11
File: src/context/ActionSheet/ActionSheet.provider.tsx:77-90
Timestamp: 2025-07-10T10:59:04.202Z
Learning: In src/context/ActionSheet/ActionSheet.provider.tsx, the user (zigcccc) prefers to keep action buttons as buttons rather than menu items, maintaining the default button accessibility role instead of overriding it with "menuitem". This is semantically correct for action sheet buttons.
Learnt from: zigcccc
PR: zigcccc/petka-app#11
File: src/components/ui/Button/Button.tsx:111-128
Timestamp: 2025-07-10T10:48:53.621Z
Learning: In the Button component (src/components/ui/Button/Button.tsx), the text color (styles.text.color) is always defined and never null or undefined, so fallback values like empty strings in ButtonIcon are safe to use as they will never be reached.
convex/leaderboards/queries.ts (4)
Learnt from: zigcccc
PR: zigcccc/petka-app#7
File: src/hooks/useTrainingPuzzle/useTrainingPuzzle.ts:48-51
Timestamp: 2025-07-07T06:22:14.787Z
Learning: In src/hooks/useTrainingPuzzle/useTrainingPuzzle.ts and similar mutation calls, the user (zigcccc) prefers to rely on server-side validation rather than adding client-side validation checks for puzzle and user data before calling mutations - the server will reject invalid requests.
Learnt from: zigcccc
PR: zigcccc/petka-app#7
File: src/hooks/mutations/useCreatePuzzleGuessAttemptMutation.ts:1-5
Timestamp: 2025-07-07T06:08:06.599Z
Learning: In this codebase, the folder structure `convex/{feature}/queries` is a naming convention that contains all server actions (both queries and mutations), not just read operations. The "queries" folder name doesn't indicate the operation type.
Learnt from: zigcccc
PR: zigcccc/petka-app#7
File: src/hooks/useTrainingPuzzle/useTrainingPuzzle.ts:39-46
Timestamp: 2025-07-07T06:22:32.646Z
Learning: In the useTrainingPuzzle hook (src/hooks/useTrainingPuzzle/useTrainingPuzzle.ts), the user prefers server-side validation over client-side validation for user authentication/authorization checks. The server is expected to handle validation when user._id is null/undefined, so client-side validation is not needed.
Learnt from: zigcccc
PR: zigcccc/petka-app#7
File: src/hooks/useTrainingPuzzle/useTrainingPuzzle.ts:31-37
Timestamp: 2025-07-07T06:21:55.962Z
Learning: In src/hooks/useTrainingPuzzle/useTrainingPuzzle.ts, the user (zigcccc) prefers to rely on server-side validation rather than adding client-side validation checks before using non-null assertions. They are comfortable with letting the server reject requests if required data is missing.
src/hooks/usePushNotifications/usePushNotifications.ts (3)
Learnt from: zigcccc
PR: zigcccc/petka-app#9
File: src/app/_layout.tsx:94-0
Timestamp: 2025-07-09T12:59:59.807Z
Learning: In src/app/_layout.tsx, the useEffect hook that handles user identification and push notification registration intentionally omits `notifications` and `posthog` from the dependency array. The user (zigcccc) wants this effect to only run when the `user` object changes, not when other objects change, for performance and behavior control reasons.
Learnt from: zigcccc
PR: zigcccc/petka-app#7
File: src/hooks/useUser/useUser.ts:55-62
Timestamp: 2025-07-07T06:24:56.001Z
Learning: In src/hooks/useUser/useUser.ts, the handleUpdateUser function intentionally does not include try-catch error handling because errors are meant to bubble up to the calling form components. This is by design - the user (zigcccc) prefers to have form-level error handling rather than utility function-level error handling for update operations.
Learnt from: zigcccc
PR: zigcccc/petka-app#7
File: src/app/(authenticated)/play/daily-puzzle-solved.tsx:66-79
Timestamp: 2025-07-07T06:08:49.592Z
Learning: In src/app/(authenticated)/play/daily-puzzle-solved.tsx, the user is fine with the iOS-only ActionSheetIOS sharing implementation for now, treating it as a work-in-progress item that may be addressed later for cross-platform compatibility.
src/__tests__/settings.test.tsx (4)
Learnt from: zigcccc
PR: zigcccc/petka-app#9
File: src/app/_layout.tsx:94-0
Timestamp: 2025-07-09T12:59:59.807Z
Learning: In src/app/_layout.tsx, the useEffect hook that handles user identification and push notification registration intentionally omits `notifications` and `posthog` from the dependency array. The user (zigcccc) wants this effect to only run when the `user` object changes, not when other objects change, for performance and behavior control reasons.
Learnt from: zigcccc
PR: zigcccc/petka-app#11
File: src/context/Prompt/Prompt.test.tsx:99-99
Timestamp: 2025-07-10T10:44:14.838Z
Learning: In React Native, the Button component on Android automatically transforms the title text to uppercase for display purposes, while on iOS it preserves the original casing. When writing tests for Android platform behavior, the test should expect the uppercase version of the button title when using screen.getByRole('button', { name: 'BUTTON_TEXT' }).
Learnt from: zigcccc
PR: zigcccc/petka-app#11
File: src/__tests__/index.test.tsx:36-43
Timestamp: 2025-07-10T10:44:20.098Z
Learning: The Button.Icon component in src/components/ui/Button/Button.tsx automatically adds testID and accessibilityLabel props to icon elements using the pattern `icon-${iconName}`, where iconName is extracted from the icon's name prop. This ensures all icon buttons have proper accessibility labels without requiring manual prop addition.
Learnt from: zigcccc
PR: zigcccc/petka-app#11
File: src/__tests__/index.test.tsx:36-43
Timestamp: 2025-07-10T10:44:20.098Z
Learning: The Button.Icon component in src/components/ui/Button/Button.tsx automatically adds testID and accessibilityLabel props to icon elements using the pattern `icon-${iconName}`, where iconName is extracted from the icon's name prop. This ensures all icon buttons have proper accessibility labels without requiring manual prop addition.
src/utils/notifications.test.ts (2)
Learnt from: zigcccc
PR: zigcccc/petka-app#9
File: src/app/_layout.tsx:94-0
Timestamp: 2025-07-09T12:59:59.807Z
Learning: In src/app/_layout.tsx, the useEffect hook that handles user identification and push notification registration intentionally omits `notifications` and `posthog` from the dependency array. The user (zigcccc) wants this effect to only run when the `user` object changes, not when other objects change, for performance and behavior control reasons.
Learnt from: zigcccc
PR: zigcccc/petka-app#11
File: src/context/Prompt/Prompt.test.tsx:99-99
Timestamp: 2025-07-10T10:44:14.838Z
Learning: In React Native, the Button component on Android automatically transforms the title text to uppercase for display purposes, while on iOS it preserves the original casing. When writing tests for Android platform behavior, the test should expect the uppercase version of the button title when using screen.getByRole('button', { name: 'BUTTON_TEXT' }).
🧬 Code Graph Analysis (6)
src/app/_layout.tsx (1)
src/utils/notifications.ts (1)
registerForPushNotificationsAsync(6-41)
src/components/ui/Button/Button.tsx (1)
src/styles/themes.ts (1)
defaultTheme(1-118)
convex/leaderboards/queries.ts (2)
convex/shared/queries.ts (1)
internalMutation(14-14)convex/leaderboards/models.ts (1)
leaderboardType(11-11)
src/hooks/usePushNotifications/usePushNotifications.ts (2)
convex/_generated/dataModel.d.ts (1)
Id(48-49)src/utils/notifications.ts (1)
notificationsPermissionsLookup(43-55)
src/__tests__/settings.test.tsx (1)
src/app/(authenticated)/settings.tsx (1)
SettingsScreen(17-111)
src/utils/notifications.test.ts (1)
src/utils/notifications.ts (1)
notificationsPermissionsLookup(43-55)
🔇 Additional comments (38)
src/components/ui/Text/Text.tsx (1)
74-76: LGTM! Clean addition of gold40 color variant.The new
gold40color variant is well-implemented and consistent with the existing pattern. This addition aligns perfectly with the Button component's new "warning" intent, providing a cohesive color scheme across UI components.src/components/ui/Button/Button.tsx (4)
18-18: LGTM! Consistent spinner color mapping.The addition of the 'warning' intent to the spinner color map using
gold[40]is consistent with the gold color scheme used in outline and transparent variants.
173-173: LGTM! Proper intent variant addition.The addition of the 'warning' intent to the variants follows the established pattern and is consistent with other intent definitions.
273-279: LGTM! Comprehensive warning intent styling.The outline and transparent variant compound styles for the warning intent are well-implemented:
- Outline variant uses
gold[40]for border and text color- Transparent variant uses
gold[40]for text colorThis provides good visual distinction from the danger intent while maintaining consistency with the gold color scheme.
Also applies to: 365-371, 407-413
231-237: Confirm distinct warning fill colorThe
warningfill variant currently usestheme.colors.red[40]—the same token asdanger—which can make warning and danger buttons indistinguishable.
- Location:
src/components/ui/Button/Button.tsxlines 231–237- Current snippet:
{ variant: 'fill', intent: 'warning', styles: { backgroundColor: theme.colors.red[40], }, },Is this overlap intentional? If not, please update the warning style to use a separate token (e.g.,
theme.colors.yellow[40]).package.json (1)
68-68: LGTM! Dependencies properly aligned with new features.The addition of
expo-tracking-transparencyaligns with the tracking permission requests added insrc/app/_layout.tsx, and the package manager update is routine maintenance.Also applies to: 112-112
convex/leaderboards/queries.ts (2)
5-5: LGTM! Proper imports for the new internal mutation.The imports are correctly added to support the new
populateLeaderboardWithExistingRecordsinternal mutation.Also applies to: 8-8
224-227: LGTM! Proper async scheduling of leaderboard population.The async scheduling with
runAfter(0, ...)is appropriate - it ensures the main operations complete first while populating the leaderboard in the background.Also applies to: 262-265
eas.json (1)
12-14: LGTM! Environment variables properly configured for dynamic app configuration.The
APP_ENVenvironment variables are correctly set for each build profile, supporting the new dynamic configuration inapp.config.ts.Also applies to: 20-22, 27-29
src/utils/notifications.ts (1)
43-55: LGTM! Well-designed utility function for notification permission checking.The function properly handles the optional callback pattern and correctly determines when notification permissions are effectively disabled (denied and can't ask again). The logic aligns with the usage in the
usePushNotificationshook.src/app/_layout.tsx (4)
10-10: LGTM! Proper imports for the new permission request functionality.The imports are correctly added to support tracking transparency and push notification registration.
Also applies to: 21-21
79-88: LGTM! Appropriate permission request implementation.The permission requests are properly implemented with concurrent execution and appropriate error handling. The silent error catch is acceptable here since permission requests are non-critical to app functionality.
104-104: LGTM! Correct dependency array simplification.Removing
setImagesLoadedfrom the dependency array is correct since setState functions have stable references in React.
123-123: LGTM! Good addition of notification tracking analytics.Adding PostHog event capture for notification opens provides valuable user engagement metrics. The dependency array update is also correct.
Also applies to: 129-129
src/__tests__/settings.test.tsx (5)
4-4: LGTM: Proper import addition for new functionality.The
Linkingimport is correctly added to support the new "Open settings" functionality being tested.
52-52: LGTM: Appropriate spy setup for Linking.openSettings.The spy setup follows the established patterns in the test file and properly mocks the
Linking.openSettingsmethod.
65-65: LGTM: Comprehensive mock updates for systemNotificationsEnabled.All mock return values have been properly updated to include the new
systemNotificationsEnabledflag, ensuring consistency across test scenarios.Also applies to: 107-111, 122-126
135-149: LGTM: Thorough testing of systemNotificationsEnabled edge cases.The parameterized test properly covers all falsy values (
null,undefined,false) forsystemNotificationsEnabled, ensuring robust edge case handling.
178-196: LGTM: Complete test coverage for hint display functionality.The test cases properly verify both the display of the hint when system notifications are disabled and the absence of the hint when they're enabled. The test also verifies the button functionality to open system settings.
src/hooks/usePushNotifications/usePushNotifications.ts (5)
1-1: LGTM: Proper imports for the new functionality.The new imports are correctly added to support the system notification permission tracking functionality.
Also applies to: 3-4, 7-7
14-14: LGTM: Appropriate default value for systemNotificationsEnabled.Setting the default value to
trueprovides an optimistic default that won't unnecessarily disable the UI before the actual permission check completes.
60-64: LGTM: Proper use of useFocusEffect for permission checks.The
useFocusEffectcorrectly triggers permission checks when the screen gains focus, ensuring the UI reflects the current system state when users return to the app.
66-74: LGTM: Appropriate AppState listener for permission updates.The
AppStateevent listener properly handles permission checks when the app becomes active, ensuring the UI stays in sync with system-level permission changes. The cleanup function correctly removes the subscription.
76-79: LGTM: Proper memoization and return object update.The return object correctly includes the new
systemNotificationsEnabledflag, and the memoization dependencies are properly updated to include the new state variable.src/app/(authenticated)/settings.tsx (6)
1-1: LGTM: Proper imports for the new functionality.The new imports are correctly added to support the system notification permission UI enhancements.
Also applies to: 5-5, 15-15
21-21: LGTM: Proper destructuring of the new hook return value.The
systemNotificationsEnabledflag is correctly destructured from the updated hook.
28-30: LGTM: Clean and straightforward handler implementation.The
handleOpenAppSettingsfunction is well-implemented and follows the async pattern used elsewhere in the component.
40-43: LGTM: Proper Switch component enhancement.The Switch component correctly combines both app-level token status and system-level permission status for its value, disabled state, and accessibility value. This provides users with accurate feedback about the overall notification state.
50-68: LGTM: Excellent user guidance implementation.The conditional hint section provides clear, actionable guidance to users when system notifications are disabled. The UI includes:
- Clear iconography and messaging
- Helpful explanatory text
- A prominent button to open system settings
- Proper localization
This significantly improves the user experience by addressing a common point of confusion.
118-131: LGTM: Consistent styling following design patterns.The new styles for the hint components follow the established design patterns in the app, using the theme system appropriately for colors, spacing, and layout.
app.config.ts (4)
1-8: LGTM: Excellent environment-based configuration setup.The dynamic configuration based on
APP_ENVis well-implemented, allowing for distinct app variants with different names, identifiers, and icons. This is a best practice for managing multiple deployment environments.
10-38: LGTM: Comprehensive platform-specific configuration.The configuration properly handles iOS, Android, and web platforms with appropriate settings:
- iOS: Proper bundle identifier and encryption info
- Android: Adaptive icon configuration and edge-to-edge display
- Web: Metro bundler and static output configuration
All settings follow Expo best practices.
39-69: LGTM: Well-structured plugin configuration.The plugin configuration is comprehensive and includes all necessary plugins for the app's functionality:
- Routing, splash screen, and asset management
- Sentry integration for error tracking
- Notifications and tracking transparency
- Proper plugin configuration with appropriate options
70-86: LGTM: Proper EAS and update configuration.The experimental features, EAS project configuration, and update settings are correctly configured for the app's deployment needs.
src/utils/notifications.test.ts (4)
1-1: LGTM: Proper imports for the new test functionality.The
waitForimport is correctly added for asynchronous testing, and thenotificationsPermissionsLookupfunction is properly imported.Also applies to: 6-6
148-158: LGTM: Proper test setup and guard clause verification.The test suite setup is clean, and the guard clause test correctly verifies that the function doesn't call
getPermissionsAsyncwhen no callback is provided.
160-171: LGTM: Thorough testing of the 'denied and cannot ask again' scenario.The test properly verifies that when permissions are denied and
canAskAgainis false, the callback is called withfalse. The use ofwaitForcorrectly handles the asynchronous nature of the callback.
173-191: LGTM: Comprehensive parameterized testing for all other permission states.The parameterized test effectively covers all scenarios where the callback should be called with
true:
- GRANTED permissions
- UNDETERMINED permissions
- DENIED permissions where the user can still be asked again
This ensures complete coverage of the function's logic.
|
🚀 Expo preview is ready!
|
Summary by CodeRabbit
New Features
Improvements
Bug Fixes
Tests