feat(native-app): Move app to nx #17098
Conversation
WalkthroughThe pull request includes extensive modifications across various files in a React Native application. Key changes involve updates to the Changes
Suggested labels
Suggested reviewers
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: 9
🧹 Outside diff range and nitpick comments (11)
apps/native/app/tsconfig.spec.json (1)
1-21: Configuration looks good with a minor optimization opportunityThe TypeScript configuration for tests is well-structured and follows Nx conventions. However, consider consolidating the test file patterns to reduce redundancy.
Optional optimization:
"include": [ "jest.config.ts", - "src/**/*.test.ts", - "src/**/*.spec.ts", - "src/**/*.test.tsx", - "src/**/*.spec.tsx", - "src/**/*.test.js", - "src/**/*.spec.js", - "src/**/*.test.jsx", - "src/**/*.spec.jsx", + "src/**/*.{test,spec}.{ts,tsx,js,jsx}", "src/**/*.d.ts" ]apps/native/app-e2e/project.json (1)
7-18: Consider adding essential targetsThe configuration is missing some essential targets that are typically needed for a complete e2e testing setup:
build: To compile any test helpers or utilitiestest: To run unit tests for test helpersapps/native/app/jest.config.ts (1)
1-22: Enhance test configuration with coverage and environment settingsThe Jest configuration looks good but could be improved with:
- Coverage thresholds to maintain test quality
- Specific coverage collection paths
- Explicit test environment setting
Add these configurations:
module.exports = { displayName: 'IslandApp', preset: 'react-native', + testEnvironment: 'node', resolver: '@nx/jest/plugins/resolver', moduleFileExtensions: ['ts', 'js', 'html', 'tsx', 'jsx'], setupFilesAfterEnv: ['<rootDir>/src/test-setup.ts'], moduleNameMapper: { '\\.svg$': '@nx/react-native/plugins/jest/svg-mock', }, transform: { '^.+.(js|ts|tsx)$': [ 'babel-jest', { configFile: __dirname + '/.babelrc.js', }, ], '^.+.(bmp|gif|jpg|jpeg|mp4|png|psd|svg|webp)$': require.resolve( 'react-native/jest/assetFileTransformer.js', ), }, coverageDirectory: '../../../coverage/apps/native/app', + collectCoverageFrom: [ + 'src/**/*.{js,jsx,ts,tsx}', + '!src/**/*.d.ts', + '!src/**/*.stories.{js,jsx,ts,tsx}', + '!src/**/*.spec.{js,jsx,ts,tsx}', + ], + coverageThreshold: { + global: { + branches: 80, + functions: 80, + lines: 80, + statements: 80 + } + } }apps/native/app/metro.config.js (2)
24-26: Consider enabling debug mode during developmentDebug mode is currently disabled. During the transition to Nx, having debug information available could help troubleshoot module resolution issues.
// Change this to true to see debugging info. // Useful if you have issues resolving modules - debug: false, + debug: true,
27-28: Add SVG to extensions arrayThe configuration includes SVG handling but the extensions array is empty. Consider adding 'svg' to maintain consistency.
// all the file extensions used for imports other than 'ts', 'tsx', 'js', 'jsx', 'json' - extensions: [], + extensions: ['svg'],apps/native/app/webpack.config.js (1)
27-37: Add TypeScript support for vector-iconsThe babel configuration only handles JavaScript files for vector-icons. Since this is a TypeScript project, consider adding TypeScript support.
config.module.rules.push({ - test: /\.(js|jsx)$/, + test: /\.(js|jsx|ts|tsx)$/, include: /react-native-vector-icons/, loader: 'babel-loader', options: { presets: [ '@babel/preset-env', ['@babel/preset-react', { runtime: 'automatic' }], + '@babel/preset-typescript', ], }, }).gitignore (1)
107-179: Add missing React Native specific patternsWhile the current patterns are good, there are some missing React Native specific patterns that should be included.
Add these additional patterns:
# React Native # OSX # .DS_Store +# React Native specific +*.bundle +*.bundle.map +.env.development +.env.production +.env.staging + +# iOS specific +ios/assets +ios/main.jsbundle +ios/main.jsbundle.meta + +# Android specific +android/app/src/main/assets/index.android.bundle +android/app/src/main/assets/index.android.bundle.meta +android/app/release/ + # Xcodeapps/native/app/project.json (1)
77-83: Consider adding test coverage thresholdsWhile the Jest configuration is present, consider adding coverage thresholds to maintain code quality standards.
"test": { "executor": "@nx/jest:jest", "outputs": ["{workspaceRoot}/coverage/{projectRoot}"], "options": { - "jestConfig": "apps/native/app/jest.config.ts" + "jestConfig": "apps/native/app/jest.config.ts", + "coverageThreshold": { + "global": { + "branches": 80, + "functions": 80, + "lines": 80, + "statements": 80 + } + } } }nx.json (1)
Line range hint
1-23: Consider increasing parallel execution limitThe task runner is configured with
"parallel": 1, which might limit build performance. Consider increasing this value based on available system resources."options": { "cacheableOperations": [ "build", "lint", "test", "e2e", "codegen/backend-client", "codegen/backend-schema", "codegen/frontend-client", "generateDevIndexHTML" ], "cacheDirectory": ".cache/nx", - "parallel": 1 + "parallel": 3 }apps/native/app/Gemfile (1)
9-9: Consider reordering gems alphabeticallyWhile not critical, the gems could be ordered alphabetically for better maintainability. The
activesupportgem could be moved beforecocoapods.source 'https://rubygems.org' # You may use http://rbenv.org/ or https://rvm.io/ to install and use this version ruby ">= 2.6.10" # Cocoapods 1.15 introduced a bug which break the build. We will remove the upper # bound in the template on Cocoapods with next React Native release. +gem 'activesupport', '>= 6.1.7.5', '< 7.1.0' gem 'cocoapods', '>= 1.13', '< 1.15' -gem 'activesupport', '>= 6.1.7.5', '< 7.1.0'🧰 Tools
🪛 rubocop (1.68.0)
[convention] 9-9: Gems should be sorted in an alphabetical order within their section of the Gemfile. Gem
activesupportshould appear beforecocoapods.(Bundler/OrderedGems)
apps/native/app/src/utils/applications-utils.ts (1)
Line range hint
1-35: Architecture aligns well with nx workspace structureThe utility module's structure and location follow nx best practices:
- Clear separation of concerns
- Well-defined utility functions
- Proper use of shared types from the monorepo
Consider documenting the URL generation patterns in the nx workspace documentation to help other developers understand the application routing structure.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
⛔ Files ignored due to path filters (1)
yarn.lockis excluded by!**/yarn.lock,!**/*.lock
📒 Files selected for processing (28)
.gitignore(1 hunks)apps/native/app-e2e/.eslintrc.json(1 hunks)apps/native/app-e2e/playwright.config.ts(1 hunks)apps/native/app-e2e/project.json(1 hunks)apps/native/app-e2e/src/example.spec.ts(1 hunks)apps/native/app-e2e/tsconfig.json(1 hunks)apps/native/app/.babelrc.js(1 hunks)apps/native/app/.bundle/config(1 hunks)apps/native/app/.eslintrc.json(2 hunks)apps/native/app/.gitignore(0 hunks)apps/native/app/Gemfile(1 hunks)apps/native/app/android/app/google-services.json(1 hunks)apps/native/app/babel.config.js(0 hunks)apps/native/app/ios/IslandApp.xcodeproj/project.pbxproj(3 hunks)apps/native/app/jest.config.js(0 hunks)apps/native/app/jest.config.ts(1 hunks)apps/native/app/metro.config.js(1 hunks)apps/native/app/package.json(2 hunks)apps/native/app/project.json(1 hunks)apps/native/app/src/test-setup.ts(1 hunks)apps/native/app/src/types/react-native.d.ts(0 hunks)apps/native/app/src/utils/applications-utils.ts(1 hunks)apps/native/app/tsconfig.app.json(1 hunks)apps/native/app/tsconfig.json(1 hunks)apps/native/app/tsconfig.spec.json(1 hunks)apps/native/app/webpack.config.js(1 hunks)nx.json(1 hunks)package.json(6 hunks)
💤 Files with no reviewable changes (4)
- apps/native/app/jest.config.js
- apps/native/app/.gitignore
- apps/native/app/babel.config.js
- apps/native/app/src/types/react-native.d.ts
✅ Files skipped from review due to trivial changes (7)
- apps/native/app/.bundle/config
- apps/native/app/src/test-setup.ts
- apps/native/app/.eslintrc.json
- apps/native/app-e2e/tsconfig.json
- apps/native/app/.babelrc.js
- apps/native/app-e2e/.eslintrc.json
- apps/native/app/tsconfig.app.json
🧰 Additional context used
📓 Path-based instructions (14)
apps/native/app-e2e/src/example.spec.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/native/app/src/utils/applications-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/native/app-e2e/project.json (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/native/app/metro.config.js (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/native/app/android/app/google-services.json (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/native/app/ios/IslandApp.xcodeproj/project.pbxproj (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/native/app/package.json (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/native/app/tsconfig.spec.json (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/native/app/jest.config.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/native/app-e2e/playwright.config.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/native/app/webpack.config.js (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/native/app/tsconfig.json (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/native/app/project.json (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/native/app/Gemfile (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."
🪛 Gitleaks (8.21.2)
apps/native/app/android/app/google-services.json
23-23: Uncovered a GCP API key, which could lead to unauthorized access to Google Cloud services and data breaches.
(gcp-api-key)
59-59: Uncovered a GCP API key, which could lead to unauthorized access to Google Cloud services and data breaches.
(gcp-api-key)
95-95: Uncovered a GCP API key, which could lead to unauthorized access to Google Cloud services and data breaches.
(gcp-api-key)
🪛 rubocop (1.68.0)
apps/native/app/Gemfile
[convention] 9-9: Gems should be sorted in an alphabetical order within their section of the Gemfile. Gem activesupport should appear before cocoapods.
(Bundler/OrderedGems)
🔇 Additional comments (14)
apps/native/app/webpack.config.js (1)
16-19: Verify react-native-web compatibility with existing native components
The alias configuration redirects 'react-native' to 'react-native-web'. While this is necessary for web support, ensure all native components used in the app have web equivalents.
✅ Verification successful
React Native Web compatibility is verified for current component usage
Based on the analysis of imports from 'react-native' across the codebase, the components being used are all compatible with react-native-web:
- Core components like View, Text, Image, ScrollView, SafeAreaView, TouchableOpacity, etc. are fully supported
- Animation APIs (Animated, Easing) are supported
- Platform utilities (Platform, Dimensions, Appearance) work correctly
- Common APIs like Alert, Linking, AppState are supported
The only potentially problematic usage is ActionSheetIOS in a few files, but these are properly isolated in platform-specific code using Platform.select() or Platform.OS checks.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for react-native specific components that might not have web equivalents
rg -l "import.*?{.*?}.*?from 'react-native'" | xargs rg "import.*?{.*?(Modal|ActionSheetIOS|Alert|AnimatedImage|AppRegistry|AppState|DeviceEventEmitter|Dimensions|DrawerLayoutAndroid|ImagePickerIOS|InputAccessoryView|KeyboardAvoidingView|ListView|MaskedViewIOS|NavigatorIOS|PixelRatio|ProgressBarAndroid|ProgressViewIOS|PushNotificationIOS|SegmentedControlIOS|Settings|Share|StatusBarIOS|SwipeableFlatList|SwipeableListView|TabBarIOS|TimePickerAndroid|Toast|ToolbarAndroid|TVEventHandler|UIManager|VibrationIOS|ViewPagerAndroid|WebView|DatePickerIOS).*?}.*?from 'react-native'"
Length of output: 1332
Script:
#!/bin/bash
# Search for react-native imports with fixed regex
rg "import.*from 'react-native'" -l | while read -r file; do
echo "=== $file ==="
rg "import .* from 'react-native'" "$file"
done
Length of output: 40222
Script:
#!/bin/bash
# Search for specific native components that might not have web equivalents
rg -g '!*.test.*' -g '!*.spec.*' -g '!*.d.ts' \
-e "Modal[^a-zA-Z]" \
-e "ActionSheetIOS" \
-e "ImagePickerIOS" \
-e "NavigatorIOS" \
-e "ProgressBarAndroid" \
-e "SegmentedControlIOS" \
-e "StatusBarIOS" \
-e "TabBarIOS" \
-e "TimePickerAndroid" \
-e "ToolbarAndroid" \
-e "ViewPagerAndroid" \
-e "DatePickerIOS"
Length of output: 67235
apps/native/app/android/app/google-services.json (2)
11-13: Verify package name consistency across environments
The package names follow a good naming convention (is.island.app, is.island.app.dev, is.island.app.staging), maintaining clear separation between environments.
Also applies to: 47-49, 83-85
2-6: Verify Firebase project configuration
The Firebase configuration appears to be using a development project ID (pc-api-8701487029959181480-770). Ensure this is intentional and not mixing development and production configurations.
Also applies to: 81-86
✅ Verification successful
Firebase configuration is correctly set up for multiple environments
After analyzing the google-services.json file, I can confirm this is intentionally configured for development purposes. The file contains proper configurations for multiple environments:
- Production:
is.island.app - Development:
is.island.app.dev - Staging:
is.island.app.staging
All environments are properly configured under the same Firebase project with appropriate package names and client configurations.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if the Firebase project ID follows naming conventions
# and if there are any potential misconfigurations
# Check for any other Firebase configurations that might conflict
rg -l "pc-api-8701487029959181480-770" --type json
# Look for any other potential Firebase configurations
fd -e json -x grep -l "project_info" {}
Length of output: 192
Script:
#!/bin/bash
# Let's check the content of the google-services.json to understand the full configuration
cat apps/native/app/android/app/google-services.json
# Check for any environment-specific configuration files or build scripts
fd -e json -e js -e ts -e gradle | rg -i "firebase|google.*services"
# Look for any environment configuration patterns
rg -i "firebase.*config" -g "!{*.json,*.lock}"
Length of output: 13755
apps/native/app/project.json (2)
8-14: LGTM: React Native start configuration
The start configuration is properly set up with the default Metro bundler port (8081).
84-117: Verify web build configuration completeness
The webpack configuration for web builds includes proper development and production settings. However, ensure that React Native Web-specific optimizations are included in the webpack config.
✅ Verification successful
React Native Web configuration is properly implemented
The webpack configuration includes all essential React Native Web optimizations:
- Correct alias mapping for 'react-native' to 'react-native-web'
- Proper extension resolution order with .web.* extensions prioritized
- Babel configuration for react-native-vector-icons support
- Integration with Nx and React webpack plugins
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check webpack configuration for React Native Web support
# Check if webpack config includes React Native Web aliases
rg -l "react-native-web" "apps/native/app/webpack.config.js"
# Look for other React Native Web related configurations
rg "react-native" "apps/native/app/webpack.config.js"
Length of output: 231
Script:
#!/bin/bash
# Get more context about webpack configuration to ensure all necessary React Native Web optimizations are in place
cat apps/native/app/webpack.config.js
Length of output: 1037
nx.json (1)
101-102: LGTM: E2E cache configuration
The e2e cache configuration is properly set up with appropriate inputs and cache enabled.
apps/native/app/package.json (2)
54-55: Good addition of testing libraries!
The addition of React Native testing libraries will help maintain code quality during and after the nx migration. These libraries are essential for component testing in React Native.
68-68: Verify metro configuration compatibility
The metro-config update to version 0.81.0 is required for nx integration. However, let's ensure it's compatible with the React Native version being used.
✅ Verification successful
Metro configuration is compatible with React Native version
The metro-config version 0.81.0 is compatible with React Native 0.74.5. The metro configuration is properly set up using @react-native/metro-config and integrated with Nx through @nx/react-native. The configuration includes proper transformer and resolver settings for handling various file extensions including SVG files.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if metro-config version is compatible with react-native version
rg -A 1 '"react-native":\s*"[^"]*"' apps/native/app/package.json
Length of output: 134
Script:
#!/bin/bash
# Check metro-config peer dependencies in package.json
rg -A 5 '"metro-config":\s*"[^"]*"' apps/native/app/package.json
# Check metro-config version in node_modules
cat package.json | jq -r '.dependencies["metro-config"] + " " + .devDependencies["metro-config"]' 2>/dev/null
# Search for metro.config.js files
fd -g 'metro.config.js' -x cat {}
Length of output: 1411
package.json (2)
Line range hint 349-360: Comprehensive nx setup for React Native
Good addition of nx packages required for React Native integration. The inclusion of all necessary nx packages ensures proper monorepo management.
264-264: Verify React Native version compatibility
The React Native setup includes core and platform-specific dependencies. Let's ensure version compatibility between:
- react-native: 0.74.1
- @react-native-community/cli-platform-android: ~13.6.6
- @react-native/babel-preset: ^0.74.83
- @react-native/metro-config: ^0.74.83
Also applies to: 367-369
✅ Verification successful
React Native dependencies are properly aligned
All React Native related dependencies are compatible with version 0.74.1:
- react-native: 0.74.1
- @react-native-community/cli-platform-android: ~13.6.6
- @react-native/babel-preset: ^0.74.83
- @react-native/metro-config: ^0.74.83
The version numbers follow the expected pattern where the major version (74) matches across the core package and its related dependencies.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for any version mismatches in React Native related packages
rg -A 1 '"react-native":\s*"[^"]*"|"@react-native[^"]*":\s*"[^"]*"' package.json
Length of output: 344
apps/native/app/ios/IslandApp.xcodeproj/project.pbxproj (1)
553-553: Consistent linker flags update across configurations
The OTHER_LDFLAGS setting has been updated consistently across Debug, Release, and Testing configurations. This change ensures proper linking behavior in the nx-managed build process.
Also applies to: 625-625, 745-745
apps/native/app/Gemfile (1)
Line range hint 3-4: Consider upgrading the minimum Ruby version requirement
The current minimum Ruby version (2.6.10) is quite old and reached end-of-life. Consider upgrading to a more recent version (e.g., >= 3.0.0) to ensure you receive security updates and can leverage modern Ruby features.
🧰 Tools
🪛 rubocop (1.68.0)
[convention] 9-9: Gems should be sorted in an alphabetical order within their section of the Gemfile. Gem activesupport should appear before cocoapods.
(Bundler/OrderedGems)
apps/native/app/src/utils/applications-utils.ts (2)
1-1: Verify the updated import path across the codebase
The simplified import path aligns with the nx migration objective. Let's ensure this change is consistent across the codebase.
✅ Verification successful
Let me verify the exports from the new path to ensure the ApplicationConfigurations type is properly exposed.
Import path update is valid and consistent
The simplified import path @island.is/application/types is correctly structured as:
- No instances of the old import path remain in the codebase
- The new path is valid with proper exports through
index.ts ApplicationConfigurationsis properly exported from./lib/ApplicationTypes
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for any remaining old import paths and verify the new import path exists
# Check for any remaining old import paths
echo "Checking for old import paths..."
rg "@island.is/application/types/lib/ApplicationTypes"
# Verify the new import path exists in the nx workspace
echo "Verifying new import path..."
fd -t f "index.(ts|js)" -p "libs/application/types/"
Length of output: 496
Script:
#!/bin/bash
# Check if ApplicationConfigurations is exported from the new path
echo "Checking exports in index.ts..."
cat libs/application/types/src/index.ts
# Check for any other files that might contain ApplicationConfigurations
echo -e "\nChecking for ApplicationConfigurations definition..."
rg "ApplicationConfigurations" -A 2 libs/application/types/
Length of output: 1296
Line range hint 7-35: Verify type compatibility and URL generation with nx structure
The utility functions depend on ApplicationConfigurations and config values. While the implementation remains unchanged, we should ensure:
- The ApplicationConfigurations type structure remains compatible
- The URL generation still works with the new nx workspace structure
✅ Verification successful
URL generation and type compatibility verified with nx structure
Based on the code analysis:
- The ApplicationConfigurations import is correctly maintained from '@island.is/application/types'
- The URL generation functions correctly use the config values and maintain the same pattern across the nx workspace
- The slug-based routing structure remains consistent with the application templates shown in the broader codebase
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify type definitions and config usage
# Check ApplicationConfigurations type definition
echo "Checking ApplicationConfigurations type..."
ast-grep --pattern 'interface ApplicationConfigurations {
$$$
}'
# Check config usage pattern
echo "Checking config usage pattern..."
rg -A 2 "apiUrl.replace\(/api\$/, "
Length of output: 275
Script:
#!/bin/bash
# Let's try different approaches to verify the dependencies
# 1. Check for ApplicationConfigurations usage and definition
echo "Checking ApplicationConfigurations..."
rg "ApplicationConfigurations" -B 2 -A 2
# 2. Check for type imports and definitions
echo "Checking Application type definition..."
rg "type Application" -B 2 -A 2
# 3. Check config pattern in a broader context
echo "Checking config usage..."
rg "getConfig\(\).apiUrl" -B 2 -A 2
# 4. Look for SearchArticleFragmentFragment type
echo "Checking SearchArticleFragmentFragment..."
rg "SearchArticleFragmentFragment" -B 2 -A 2
# 5. Check for any potential URL configuration files
echo "Checking URL configuration files..."
fd -t f "url" -t f "config"
Length of output: 67212
Script:
#!/bin/bash
# Let's check for the specific imports and type definitions
# 1. Check for ApplicationConfigurations type definition
echo "Checking ApplicationConfigurations type definition..."
rg "type ApplicationConfigurations" -B 2 -A 5
# 2. Check for Application type imports in the file
echo "Checking imports in applications-utils.ts..."
rg -g "applications-utils.ts" "import.*Application.*from"
# 3. Check for config usage in a different way
echo "Checking config usage..."
rg "getConfig\(\)" -g "applications-utils.ts" -B 2 -A 2
# 4. Check for SearchArticleFragmentFragment definition
echo "Checking SearchArticleFragmentFragment definition..."
rg "type SearchArticleFragmentFragment" -B 2 -A 5
Length of output: 1524
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (1)
.gitignore (1)
184-186: Remove duplicate node_modules entry.There's a duplicate entry for
node_modules/(also appears on line 154). Consider removing this redundant entry to maintain a cleaner.gitignorefile.-## Nested node_modules - -node_modules/
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (1)
.gitignore(1 hunks)
🔇 Additional comments (1)
.gitignore (1)
107-176: LGTM! Comprehensive React Native ignore patterns added.
The additions properly cover all essential ignore patterns for React Native development, including:
- Build artifacts and derived data
- IDE specific files
- Sensitive credentials and certificates
- Platform-specific dependencies
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (2)
apps/native/app/ios/IslandApp/Info.plist (1)
Line range hint
95-96: Security: Consider moving CodePushDeploymentKey to environment variablesThe CodePushDeploymentKey is currently hardcoded in the Info.plist file. Consider moving this to a secure configuration management system or environment variables to follow security best practices.
apps/native/app/android/app/build.gradle (1)
Version mismatch detected across platform configurations
The verification reveals inconsistencies in version numbers across different platform configurations:
- iOS: version 1.4.8
- Android: version 1.4.8
- Package.json: version 1.2.5
The iOS and Android versions are aligned at 1.4.8, but the package.json version (1.2.5) is significantly behind. This misalignment should be addressed to maintain consistent versioning across the project.
🔗 Analysis chain
Line range hint
89-91: Verify version code and name alignmentThe versionCode is dynamically set with a fallback of 143, while versionName is updated to "1.4.8". Please ensure this version code increment aligns with your versioning strategy.
Also applies to: 106-106
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check version consistency across platforms echo "Checking version numbers across platforms..." # Check iOS version echo "iOS version:" grep -A 1 "CFBundleShortVersionString" apps/native/app/ios/IslandApp/Info.plist # Check Android version echo "Android version:" grep "versionName" apps/native/app/android/app/build.gradle # Check package.json version if it exists echo "Package.json version (if exists):" find apps/native/app -name "package.json" -exec grep "\"version\"" {} \;Length of output: 580
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (3)
apps/native/app/android/app/build.gradle(1 hunks)apps/native/app/ios/IslandApp/Info.plist(1 hunks)nx.json(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- nx.json
🧰 Additional context used
📓 Path-based instructions (2)
apps/native/app/ios/IslandApp/Info.plist (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/native/app/android/app/build.gradle (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 (2)
apps/native/app/ios/IslandApp/Info.plist (1)
20-20: Version update looks good
The version increment to 1.4.8 is consistent with the Android configuration.
apps/native/app/android/app/build.gradle (1)
106-106: Version update is consistent
The version name update to 1.4.8 aligns with the iOS configuration, maintaining version parity across platforms.
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Outside diff range and nitpick comments (4)
apps/native/app/project.json (4)
Line range hint
1-7: Update project tag to reflect TypeScript usageThe tag
scope:jsdoesn't accurately reflect that this is a React Native TypeScript project. Consider using a more specific tag likescope:react-nativeorscope:typescript.- "tags": ["scope:js"], + "tags": ["scope:react-native", "scope:typescript"],
21-28: Use workspace-relative paths for bundle outputsThe bundle output paths are hardcoded. Consider using Nx workspace tokens for more maintainable paths.
- "bundleOutput": "dist/apps/native/app/ios/main.jsbundle" + "bundleOutput": "{workspaceRoot}/dist/{projectRoot}/ios/main.jsbundle"Also applies to: 61-68
9-15: Add common development options to start targetThe start target could benefit from additional options commonly needed during development.
"start": { "executor": "@nx/react-native:start", "dependsOn": [], "options": { - "port": 8081 + "port": 8081, + "resetCache": false, + "interactive": true } },
78-84: Enhance test configuration with coverage settingsThe test target could benefit from coverage thresholds and explicit test environment configuration.
"test": { "executor": "@nx/jest:jest", "outputs": ["{workspaceRoot}/coverage/{projectRoot}"], "options": { - "jestConfig": "apps/native/app/jest.config.ts" + "jestConfig": "apps/native/app/jest.config.ts", + "passWithNoTests": false, + "coverage": true, + "coverageThreshold": { + "global": { + "branches": 80, + "functions": 80, + "lines": 80, + "statements": 80 + } + } } },
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (1)
apps/native/app/project.json(1 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
apps/native/app/project.json (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/native/app/project.json (1)
36-44: Consider adding configuration options for build targets
The build targets for both Android and iOS lack specific configuration options that might be needed for different environments (staging, production, etc.).
Let's check if there are any environment-specific configurations in the project:
Also applies to: 45-50
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (3)
package.json (1)
474-474: Consider pinning react-native-web versionThe caret (^) version for react-native-web might lead to unexpected updates. Consider pinning it to a specific version for better stability:
- "react-native-web": "^0.19.11", + "react-native-web": "0.19.11",apps/native/app/project.json (2)
8-74: Consider adding descriptions to targetsTo improve maintainability, consider adding descriptions to each target explaining its purpose and usage. This helps other developers understand when to use each target.
Example addition for the start target:
"start": { "executor": "@nx/react-native:start", + "description": "Starts the React Native development server for hot reloading during development", "dependsOn": [], "options": { "port": 8081 } }
Project name inconsistency detected across configuration files
The project uses different names across various configuration files:
native-appin project.json and nx commandsIslandAppin app.json, jest.config.ts, and native platform files@island.is/native-appin package.jsonThis inconsistency should be unified to prevent potential build issues and confusion:
project.json: Update "name" to match the display name "IslandApp"package.json: Update nx command references from "native-app" to "IslandApp"- Keep native platform files as is since they use the correct display name
🔗 Analysis chain
Line range hint
1-7: Verify project name consistency across the codebaseThe project is named "native-app", but there might be references to "IslandApp" in other configuration files.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for any references to both "native-app" and "IslandApp" in configuration files echo "Searching for project name references..." rg -g "*.{json,js,ts,xml,plist,gradle}" -i "native-app|IslandApp" apps/native/app/Length of output: 1629
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
⛔ Files ignored due to path filters (1)
yarn.lockis excluded by!**/yarn.lock,!**/*.lock
📒 Files selected for processing (2)
apps/native/app/project.json(1 hunks)package.json(5 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
apps/native/app/project.json (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 (3)
package.json (1)
264-264: LGTM! React Native dependencies are properly configured
The React Native dependencies are well-structured with:
- Core package at the latest stable version
- Required CLI tools and presets
- Testing utilities
- SVG support packages
Also applies to: 367-369, 472-474, 383-383, 385-385, 464-464
apps/native/app/project.json (2)
31-70: Android build configuration looks good
The Android targets are well-structured with appropriate:
- Build outputs for both bundle and APK
- Entry file configuration
- Bundle output path
78-84: Verify Jest configuration setup
The test target references jest.config.ts. Ensure it's properly configured for React Native testing.
✅ Verification successful
Jest configuration is properly set up for React Native testing
The test configuration is correctly configured with:
- React Native preset and appropriate transforms
- Testing Library Jest Native extensions
- Proper Babel configuration with React Native preset
- Module resolution and path aliases
- Asset handling for various file types
While there are currently no test files present, the infrastructure is properly set up to support React Native testing.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check Jest configuration
echo "Checking Jest config..."
cat apps/native/app/jest.config.ts
# Verify test setup files
echo "Checking for test setup files..."
fd "setup-tests" apps/native/app/
Length of output: 840
Script:
#!/bin/bash
# Check for test setup file referenced in Jest config
echo "Checking test setup file..."
cat apps/native/app/src/test-setup.ts 2>/dev/null || echo "Test setup file not found"
# Check for .babelrc.js referenced in Jest config
echo -e "\nChecking Babel config..."
cat apps/native/app/.babelrc.js 2>/dev/null || echo "Babel config not found"
# Look for test files
echo -e "\nChecking for test files..."
fd "\.(spec|test)\.(ts|tsx)$" apps/native/app/
Length of output: 973
Datadog ReportAll test runs ✅ 99 Total Test Services: 0 Failed, 91 Passed Test ServicesThis report shows up to 10 services
🔻 Code Coverage Decreases vs Default Branch (1)
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #17098 +/- ##
=======================================
Coverage 35.76% 35.76%
=======================================
Files 6931 6931
Lines 147949 147949
Branches 42167 42167
=======================================
Hits 52918 52918
Misses 95031 95031 Flags with carried forward coverage won't be shown. Click here to find out more. Continue to review full report in Codecov by Sentry.
|
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Outside diff range and nitpick comments (2)
apps/native/app/project.json (1)
Line range hint
1-6: Update project metadata for React NativeThe tag
"scope:js"should be updated to better reflect that this is a React Native project. Consider using"scope:mobile"or"scope:react-native"for better categorization.- "tags": ["scope:js"], + "tags": ["scope:react-native"],apps/native/app/android/settings.gradle (1)
Expo configuration needs to be updated for React Native setup
The current setup shows that while Expo packages are listed as dependencies in the native app's package.json, the project is using a bare React Native setup without Expo's build system. The
autolinking.gradlescript anduseExpoModules()configuration insettings.gradleare not compatible with this setup as:
- The project uses React Native CLI and native modules directly
- Expo packages are used as standalone modules without Expo's build infrastructure
- The gradle files show standard React Native configuration without Expo integration
Recommended actions:
- Remove the Expo autolinking configuration from
settings.gradle- Use React Native's standard autolinking through
native_modules.gradlewhich is already correctly configured- Keep the Expo package dependencies but manage them through React Native's standard build process
🔗 Analysis chain
Line range hint
15-16: Review Expo autolinking configurationThe Expo autolinking script path might need adjustment for the Nx workspace structure. Additionally, verify that the
useExpoModules()configuration is compatible with the new setup.
Let me gather more information about the Expo setup in the workspace.
Let me check the content of the package.json files and gradle files to understand the Expo setup better.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify Expo setup in the new structure # Check if expo package.json exists node --print "require.resolve('expo/package.json')" 2>/dev/null if [ $? -eq 0 ]; then echo "✓ Expo package found" # Check if autolinking.gradle exists EXPO_PATH=$(node --print "require.resolve('expo/package.json')") EXPO_DIR=$(dirname "$EXPO_PATH") if [ -f "$EXPO_DIR/../scripts/autolinking.gradle" ]; then echo "✓ autolinking.gradle found" else echo "✗ autolinking.gradle not found" fi else echo "✗ Expo package not found" fiLength of output: 136
Script:
#!/bin/bash # Check for expo-related dependencies in package.json files echo "=== Searching for expo dependencies ===" fd package.json --exec grep -l "expo" {} || true echo -e "\n=== Checking workspace structure ===" fd . -t d -d 2 || true echo -e "\n=== Looking for other gradle files with expo configuration ===" fd '.*\.gradle$' --exec grep -l "expo" {} || trueLength of output: 2201
Script:
#!/bin/bash echo "=== Content of native app's package.json ===" cat apps/native/app/package.json echo -e "\n=== Content of root package.json expo-related entries ===" cat package.json | grep -A 5 -B 5 "expo" echo -e "\n=== Content of build.gradle files ===" echo "--- apps/native/app/android/build.gradle ---" cat apps/native/app/android/build.gradle echo -e "\n--- apps/native/app/android/app/build.gradle ---" cat apps/native/app/android/app/build.gradleLength of output: 15708
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (2)
apps/native/app/android/settings.gradle(1 hunks)apps/native/app/project.json(1 hunks)
🧰 Additional context used
📓 Path-based instructions (2)
apps/native/app/android/settings.gradle (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/native/app/project.json (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 (3)
apps/native/app/project.json (3)
78-84: LGTM! Test configuration follows nx best practices
The test configuration is well-structured with proper output paths and Jest configuration.
51-74: LGTM! Utility targets are well-configured
The utility targets are properly set up with correct dependencies and outputs, following nx and React Native best practices.
Line range hint 93-95: Verify the purpose of the docker-native target
The docker-native target appears to be a placeholder. Please verify if this is intentional or if it should be properly configured for Docker builds.
✅ Verification successful
The docker-native target is intentionally configured as a placeholder
The empty executor is indeed intentional. This is evidenced by:
- The repository uses
@gperdomor/nx-dockerplugin for Docker builds - The target's explicit comment states it's meant only for project filtering with
nx show projects --with-target docker-native - Other services in the repository have proper Docker configurations (Dockerfiles and docker-compose.yml files)
- The repository has a global
affected:dockernpm script that likely handles the actual Docker builds
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if there are any Docker-related files or configurations
echo "Checking for Docker files..."
fd "Dockerfile|docker-compose" apps/native/app/
# Check if other projects use similar docker targets
echo "Checking other projects' docker configurations..."
rg "docker-native" -A 5 "project.json"
Length of output: 318
Script:
#!/bin/bash
# Search for project.json files recursively and check for docker-native targets
echo "Searching for project.json files with docker-native targets..."
fd "project.json" | xargs rg "docker-native" -A 5 -B 2
# Look for any Docker-related files in the repository
echo -e "\nSearching for Docker-related files..."
fd "Dockerfile|docker-compose.yml"
# Check for any nx docker plugins or configurations
echo -e "\nChecking for nx docker configurations..."
rg "docker" package.json
Length of output: 2046
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (55)
apps/native/app/src/screens/vehicles/components/vehicle-item.tsx (1)
5-5: Consider using Nx library imports instead of relative pathsSince this PR moves the app to Nx, consider importing UI components through the Nx library pattern instead of using deep relative paths. This would make the imports more maintainable and align better with Nx best practices.
Example:
-import { Label, VehicleCard } from '../../../ui' +import { Label, VehicleCard } from '@island-is/native-ui'apps/native/app/src/screens/home/onboarding-module.tsx (1)
Line range hint
15-89: Consider enhancing type safety.While the component logic is sound, consider adding explicit TypeScript types for:
- Component props using React.FC or React.memo generic
- Store values from useAuthStore and usePreferencesStore
- Theme values from useTheme
Example enhancement:
type OnboardingModuleProps = { // Add any future props here } type WelcomeCardProps = { description: string imgSrc: ImageSourcePropType backgroundColor: { dark: string light: string } grid?: boolean link?: { url: string title: string } } export const OnboardingModule = React.memo<OnboardingModuleProps>(() => { // ... rest of the implementation })apps/native/app/src/types/styled-components.d.ts (1)
Line range hint
1-77: Consider enhancing type safety with literal types.The color and shade interfaces use string types for all color values. Consider using literal types for better type safety and autocompletion.
Example improvement:
export interface Color { // Instead of just string, use literal types blue600: '#0000FF' blue400: '#4444FF' // ... other colors with their exact hex values }This would:
- Prevent accidental assignment of invalid color values
- Provide better IDE support with exact color values
- Make it easier to track color usage across the application
apps/native/app/src/screens/family/family-overview.tsx (2)
Line range hint
92-106: Consider enhancing error handling with user feedbackWhile the error handling ensures proper state cleanup, consider adding:
- Error logging for debugging
- User feedback when refresh fails
} catch (err) { + console.error('Failed to refresh family data:', err); + // Show error toast or feedback to user + Toast.show({ + type: 'error', + text: intl.formatMessage({ id: 'family.refreshError' }) + }); setRefetching(false); }
Line range hint
29-29: Improve type safety by replacing 'any' typesSeveral instances of 'any' type usage could be replaced with proper TypeScript interfaces:
interface FamilyMember { type: 'spouse' | 'child'; nationalId: string; name?: string; displayName?: string; } interface ListItem { id?: string; type: 'skeleton' | 'empty' | 'spouse' | 'child'; nationalId?: string; } // Update component props const FamilyMember = React.memo(({ item }: { item: FamilyMember }) => { // ... }) // Update renderItem and keyExtractor const renderItem = ({ item }: { item: ListItem }) => { // ... } const keyExtractor = useCallback( (item: ListItem) => item?.nationalId ?? item?.id, [], )Also applies to: 92-92, 107-107, 134-134, 164-164
apps/native/app/src/screens/document-detail/utils/get-buttons-for-actions.tsx (3)
5-5: Consider configuring path aliases in nx configWhile the relative import path works, deep relative paths (../../../) can become difficult to maintain. Consider configuring path aliases in your nx configuration to improve code maintainability and readability.
Example configuration in
tsconfig.base.json:{ "compilerOptions": { "paths": { "@ui/*": ["libs/ui/src/*"], "@ui": ["libs/ui/src"] } } }
Line range hint
22-31: Enhance type safety for icon handlingConsider improving type safety and maintainability of the icon mapping function.
type IconType = 'open' | 'download'; const ICON_MAP: Record<IconType, any> = { 'open': openIcon, 'download': downloadIcon, }; const getIcons = (icon: IconType) => ICON_MAP[icon] ?? null;
Line range hint
33-71: Consider refactoring for improved maintainabilityThe function could benefit from several improvements:
- Extract button rendering logic to a separate component
- Move inline styles to styled components
- Add proper error handling for invalid action data
- Improve type safety for action types
Example refactor:
type ActionType = 'file' | 'url'; type DocumentAction = DocumentV2Action & { type: ActionType; }; const ActionButton = ({ action, onPress }: { action: DocumentAction; onPress: () => void }) => ( <Action key={`${action.title}-${action.type}`}> <StyledButton isUtilityButton isOutlined title={action.title} icon={getIcons(action.icon ?? '')} onPress={onPress} /> </Action> ); const StyledButton = styled(Button)` padding-top: 9px; padding-bottom: 9px; `; export const getButtonsForActions = ( openBrowser: (link: string, componentId?: string) => void, onShare: () => void, componentId: string, actions?: DocumentV2Action[] | null, ) => { if (!actions?.length) return null; const validButtons = actions .filter((action): action is DocumentAction => (action.type === 'file' || action.type === 'url') && Boolean(action.data) && Boolean(action.title) ) .map((action) => ( <ActionButton key={`${action.title}-${action.type}`} action={action} onPress={() => action.type === 'url' ? openBrowser(action.data ?? '', componentId) : onShare() } /> )); return validButtons.length > 0 ? ( <Host setMaxWidth={validButtons.length === 1}>{validButtons}</Host> ) : null; };apps/native/app/src/screens/license-scanner/license-scan-detail.tsx (1)
Line range hint
31-54: Consider enhancing error handling documentation and abstractionWhile the error handling logic is functional, consider these improvements:
- Document the possible error types in
VerifyLicenseBarcodeError- Extract error messages to constants
- Consider moving navigation logic to a custom hook
+ // Error types: + // - Expired: License has expired + // - Error: Generic error occurred const type = licenseType as unknown as SupportedGenericLicenseTypes const isExpired = error === VerifyLicenseBarcodeError.Expired + const ERROR_MESSAGES = { + expired: 'licenseScanDetail.barcodeExpired', + unknown: 'licenseScanner.errorUnknown', + } as const - useNavigationButtonPress(({ buttonId }) => { - if (buttonId === LICENSE_SCANNER_DONE) { - Navigation.dismissModal(StackRegistry.LicenseScannerStack) - } - }) + const useModalDismiss = () => { + useNavigationButtonPress(({ buttonId }) => { + if (buttonId === LICENSE_SCANNER_DONE) { + Navigation.dismissModal(StackRegistry.LicenseScannerStack) + } + }) + } + useModalDismiss()apps/native/app/src/screens/license-scanner/license-scanner.tsx (2)
Line range hint
89-277: Consider breaking down the LicenseScannerScreen componentThe component is handling multiple responsibilities and could benefit from being split into smaller, more focused components and hooks.
Consider extracting these functionalities:
- Camera permission logic to a custom hook
- Barcode scanning logic to a separate component
- Navigation logic to a custom hook
Example refactor:
// hooks/useCameraSetup.ts export const useCameraSetup = () => { const [active, setActive] = useState(true) const { hasPermission, requestPermission } = useCameraPermission() const device = useCameraDevice('back') useEffect(() => { void requestPermission() if (!isIos) { authStore.setState({ noLockScreenUntilNextAppStateActive: true, }) } }, []) return { active, setActive, hasPermission, device } } // components/BarcodeScanner.tsx export const BarcodeScanner = ({ onCodeScanned, ...props }) => { const { active, device, hasPermission } = useCameraSetup() // ... zoom logic return hasPermission && device ? ( <GestureDetector gesture={gesture}> <ReanimatedCamera {...props} device={device} isActive={active} codeScanner={codeScanner} animatedProps={animatedZoom} /> </GestureDetector> ) : null }
Line range hint
144-186: Add error boundary and loading statesThe barcode verification logic should handle loading states and errors more gracefully.
+ const [isScanning, setIsScanning] = useState(false) const onCodeScanned: CodeScanner['onCodeScanned'] = (codes) => { const { type, value } = codes[0] if (!type || !value || scanningRef.current !== ScanningStatus.INITIAL) { return } + setIsScanning(true) void verifyLicenseBarcode({ variables: { input: { data: value, }, }, }) .then(({ data }) => { if (data) { // ... navigation logic } }) + .catch((error) => { + // Handle error + setInvalid(true) + }) + .finally(() => { + setIsScanning(false) + }) }apps/native/app/src/screens/update-app/update-app.tsx (3)
Line range hint
47-49: Enhance type safety for component propsConsider improving type safety by:
- Creating a dedicated interface for the component props
- Adding proper typing for the styled-components theme
+interface UpdateAppScreenProps { + closable?: boolean; + componentId: string; +} -export const UpdateAppScreen: NavigationFunctionComponent<{ - closable?: boolean -}> = ({ closable = true, componentId }) => { +export const UpdateAppScreen: NavigationFunctionComponent<UpdateAppScreenProps> = ({ + closable = true, + componentId, +}) => {
Line range hint
51-63: Add cleanup function to useEffectConsider adding a cleanup function to handle component unmounting and prevent potential memory leaks.
useEffect(() => { Navigation.mergeOptions(componentId, { hardwareBackButton: { dismissModalOnPress: closable, }, modal: { swipeToDismiss: closable, }, }) + return () => { + // Reset navigation options on unmount if needed + Navigation.mergeOptions(componentId, { + hardwareBackButton: { + dismissModalOnPress: true, + }, + modal: { + swipeToDismiss: true, + }, + }) + } }, [])
Line range hint
64-132: Add accessibility supportThe UI components are missing accessibility props which are crucial for screen reader support.
Add accessibility props to key elements:
<Image source={logo} resizeMode="contain" style={{ width: 45, height: 45 }} + accessibilityLabel={intl.formatMessage({ + id: 'updateApp.logo.accessibility', + defaultMessage: 'Ísland.is logo' + })} /> <Image source={illustrationSrc} style={{ width: 210, height: 240 }} resizeMode="contain" + accessibilityRole="image" + accessibilityLabel={intl.formatMessage({ + id: 'updateApp.illustration.accessibility', + defaultMessage: 'Update illustration' + })} /> <Button title={intl.formatMessage({ id: 'updateApp.button', defaultMessage: 'Uppfæra', })} onPress={() => { Linking.openURL(/*...*/) }} + accessibilityHint={intl.formatMessage({ + id: 'updateApp.button.accessibility', + defaultMessage: 'Opens the app store to update the application' + })} />apps/native/app/src/utils/get-theme-with-preferences.ts (2)
Line range hint
53-58: Track technical debt: Temporary light mode enforcementThe current implementation forces light mode, disabling the system's theme preferences. This should be tracked as technical debt to ensure proper dark mode support is implemented in the future.
Would you like me to create a GitHub issue to track the implementation of proper dark mode support? This would include:
- Restoring the commented-out dynamic theme selection
- Testing with system preferences
- Ensuring proper theme transitions
Line range hint
89-94: Fix type assertion in efficient theme color overrideThe current implementation has a potential type safety issue where
shades.dark.foregroundis incorrectly asserted as '#0061ff'.Consider this safer implementation:
if (themeKey === 'efficient') { shades.dark = shades.efficient themeObj.color = { ...themeObj.color, - blue400: shades.dark.foreground as '#0061ff', + blue400: shades.dark.foreground, } }apps/native/app/src/screens/finance/finance-status-detail.tsx (1)
Line range hint
1-24: Consider enhancing error handling and loading statesWhile the component handles loading and error states, consider implementing a dedicated error component for better user experience.
- const error = !!financeStatusDetails.error + const error = financeStatusDetails.error + if (error) { + return ( + <ErrorView + message={intl.formatMessage({ id: 'financeDetail.errorMessage' })} + onRetry={() => financeStatusDetails.refetch()} + /> + ) + }apps/native/app/src/screens/finance/components/finance-status-card.tsx (2)
Line range hint
249-259: Fix URL construction in openBrowser callThere's a potential bug in the URL construction where the email is incorrectly used as the homepage URL.
- openBrowser( - `https://${org.email.replace(/https?:\/\//, '')}`, - componentId, - ) + openBrowser( + `https://${org.homepage.replace(/https?:\/\//, '')}`, + componentId, + )
Line range hint
89-279: Consider splitting component for better maintainabilityThe FinanceStatusCard component has grown quite large and handles multiple responsibilities. Consider extracting the organization contact information section into a separate component.
// Suggested new component: OrganizationContactInfo.tsx interface OrganizationContactProps { org: Organization; componentId: string; } function OrganizationContactInfo({ org, componentId }: OrganizationContactProps) { const { openBrowser } = useBrowser(); // ... extract organization contact rendering logic }apps/native/app/src/screens/settings/settings.tsx (5)
Line range hint
52-586: Consider breaking down the SettingsScreen componentThe component is quite large (500+ lines) and handles multiple concerns. Consider breaking it down into smaller, focused components for each settings section (UserSettings, CommunicationSettings, SecuritySettings, AboutSettings) to improve maintainability and testability.
Example structure:
// UserSettingsSection.tsx export const UserSettingsSection: React.FC<{ userProfile: UseQueryResult<GetProfileQuery>; }> = ({ userProfile }) => { // User settings section implementation }; // Usage in SettingsScreen const SettingsScreen: NavigationFunctionComponent = ({ componentId }) => { const userProfile = useGetProfileQuery(); return ( <ScrollView> <UserSettingsSection userProfile={userProfile} /> <CommunicationSettingsSection userProfile={userProfile} /> <SecuritySettingsSection /> <AboutSettingsSection /> </ScrollView> ); };
Line range hint
392-411: Improve biometric authentication flowThe biometric authentication flow has a potential issue where
setUseBiometrics(true)is called before confirming the authentication success. Consider moving the state updates inside the authentication success block.onValueChange={(value) => { if (value === true && !hasAcceptedBiometrics) { authenticateAsync().then((authenticate) => { if (authenticate.success) { setUseBiometrics(true) preferencesStore.setState({ hasAcceptedBiometrics: true, }) + } else { + // Reset the switch if authentication fails + setUseBiometrics(false) } }) } else { setUseBiometrics(value) } }}
Line range hint
234-259: Optimize profile update handlersThe
updateDocumentNotificationsandupdateEmailNotificationsfunctions share similar logic. Consider creating a reusable function to handle profile updates to reduce code duplication.const updateProfile = async (field: keyof UpdateProfileMutationVariables['input'], value: any) => { try { await client.mutate<UpdateProfileMutation, UpdateProfileMutationVariables>({ mutation: UpdateProfileDocument, update(cache, { data }) { cache.modify({ fields: { getUserProfile: (existing) => ({ ...existing, ...data?.updateProfile }), }, }) }, variables: { input: { [field]: value }, }, }) } catch (err) { console.error(err) RNAlert.alert( intl.formatMessage({ id: 'settings.communication.newNotificationsErrorTitle', }), intl.formatMessage({ id: 'settings.communication.newNotificationsErrorDescription', }), ) } } // Usage const updateDocumentNotifications = (value: boolean) => updateProfile('documentNotifications', value) const updateEmailNotifications = (value: boolean) => updateProfile('canNudge', value)Also applies to: 260-285
Line range hint
286-309: Improve error handling consistencyThe
updateLocalefunction silently catches errors while other update functions show error alerts. Consider implementing consistent error handling across all profile update operations.const updateLocale = (value: string) => { client .mutate<UpdateProfileMutation, UpdateProfileMutationVariables>({ mutation: UpdateProfileDocument, update(cache, { data }) { cache.modify({ fields: { getUserProfile: (existing) => { return { ...existing, ...data?.updateProfile } }, }, }) }, variables: { input: { locale: value, }, }, }) - .catch(() => { - // noop - }) + .catch((err) => { + console.error(err) + RNAlert.alert( + intl.formatMessage({ + id: 'settings.communication.updateLocaleErrorTitle', + }), + intl.formatMessage({ + id: 'settings.communication.updateLocaleErrorDescription', + }), + ) + }) }
Line range hint
146-157: Optimize CodePush update checkThe CodePush update check is wrapped in a setTimeout which adds unnecessary delay. Consider removing the timeout or implementing a more efficient loading state management.
useEffect(() => { - setTimeout(() => { - // @todo move to ui store, persist somehow - setLoadingCP(true) - CodePush.getUpdateMetadata().then((p) => { - setLoadingCP(false) - setLocalPackage(p) - }) - }, 330) + setLoadingCP(true) + CodePush.getUpdateMetadata().then((p) => { + setLoadingCP(false) + setLocalPackage(p) + }) }, [])apps/native/app/src/screens/home/licenses-module.tsx (4)
1-14: Consider grouping type imports separatelyThe import statements are well-organized, but consider grouping type imports separately for better maintainability.
import React from 'react' import { FormattedMessage, useIntl } from 'react-intl' import { Image, SafeAreaView, TouchableOpacity } from 'react-native' import styled, { useTheme } from 'styled-components/native' -import { ApolloError } from '@apollo/client' +// Types +import { ApolloError } from '@apollo/client' + import { Typography, Heading, ChevronRight, ViewPager, EmptyCard, GeneralCardSkeleton, } from '../../ui'
Line range hint
41-57: Enhance type safety in validation functionThe validation function could benefit from stricter typing and better error handling.
-const validateLicensesInitialData = ({ +const validateLicensesInitialData = ({ data, loading, -}: { +}: Readonly<{ data: ListLicensesQuery | undefined loading: boolean -}) => { +}): boolean => { if (loading) { return true } - // We only want to show the widget for the first time if the user has driving license - if ( - data?.genericLicenses?.some( + + return Boolean( + data?.genericLicenses?.some( (license) => license.license.type === GenericLicenseType.DriversLicense, ) - ) { - return true - } - - return false + ) }
Line range hint
59-103: Optimize hook performance and error handlingThe data fetching hook could benefit from memoization and better error handling.
-const useGetLicensesData = ({ skipFetching }: { skipFetching: boolean }) => { +const useGetLicensesData = ({ + skipFetching +}: Readonly<{ + skipFetching: boolean +}>) => { + const includedTypes = React.useMemo(() => [ + GenericLicenseType.DriversLicense, + GenericLicenseType.AdrLicense, + GenericLicenseType.MachineLicense, + GenericLicenseType.FirearmLicense, + GenericLicenseType.DisabilityLicense, + GenericLicenseType.PCard, + GenericLicenseType.Ehic, + GenericLicenseType.HuntingLicense, + ], []) const { data, loading, error, refetch } = useListLicensesQuery({ variables: { input: { - includedTypes: [ - GenericLicenseType.DriversLicense, - GenericLicenseType.AdrLicense, - GenericLicenseType.MachineLicense, - GenericLicenseType.FirearmLicense, - GenericLicenseType.DisabilityLicense, - GenericLicenseType.PCard, - GenericLicenseType.Ehic, - GenericLicenseType.HuntingLicense, - ], + includedTypes, }, }, skip: skipFetching, + onError: (error) => { + console.error('Failed to fetch licenses:', error) + }, })
Line range hint
105-196: Enhance accessibility and performanceThe component implementation could benefit from accessibility improvements and better performance optimizations.
- Add accessibility props:
<TouchableOpacity disabled={count === 0} onPress={() => navigateTo(`/wallet`)} + accessibilityRole="button" + accessibilityLabel={intl.formatMessage({ id: 'homeOptions.licenses' })} + accessibilityHint={intl.formatMessage({ id: 'button.seeAll' })} >
- Optimize rendering performance:
+const renderItem = React.useCallback((item: any, index: number) => ( + <WalletItem + key={index} + item={item} + style={ + count > 1 + ? { + width: viewPagerItemWidth, + paddingLeft: theme.spacing[2], + paddingRight: 0, + } + : { + width: '100%', + paddingLeft: 0, + paddingRight: 0, + } + } + noPadding + /> +), [count, viewPagerItemWidth, theme.spacing]); -const items = allLicenses +const items = React.useMemo(() => allLicenses .filter( (license) => license.__typename === 'GenericUserLicense' || license.__typename === 'IdentityDocumentModel', ) ?.slice(0, 3) - .map((item, index) => ( - <WalletItem - key={index} - item={item} - style={...} - noPadding - /> - )) + .map(renderItem), +[allLicenses, renderItem])apps/native/app/src/ui/lib/empty-state/empty-list.tsx (1)
Line range hint
44-50: Consider strengthening the TypeScript types.The
HeadingPropsinterface could be improved for better type safety:interface HeadingProps { title: React.ReactNode description: React.ReactNode - image: React.ReactNode + image: React.ReactElement<typeof Image> small?: boolean }apps/native/app/src/components/offline/offline-banner.tsx (1)
Line range hint
24-45: Consider memoizing animation configurations.The animation configurations could be optimized to prevent unnecessary recreations:
+const popInConfig = { + duration: 350, + useNativeDriver: true, + easing: Easing.in(Easing.ease), +} + +const popOutConfig = { + duration: 250, + useNativeDriver: true, + easing: Easing.out(Easing.ease), +} const popIn = () => { Animated.timing(popAnim, { toValue: 0, - duration: 350, - useNativeDriver: true, - easing: Easing.in(Easing.ease), + ...popInConfig, }).start() } const popOut = () => { Animated.timing(popAnim, { toValue: -TranslateYValue, - duration: 250, - useNativeDriver: true, - easing: Easing.out(Easing.ease), + ...popOutConfig, }).start(() => { toggleBanner(false) void Navigation.dismissOverlay(CR.OfflineBanner) }) }apps/native/app/src/ui/lib/problem/problem-template.tsx (1)
Line range hint
29-36: Add missing 'error' case in getIcon functionThe
getIconfunction handles 'warning' and 'info' variants but doesn't handle the 'error' variant, which is a valid value in theVarianttype.Apply this diff to add the missing case:
const getIcon = (variant: Variant) => { switch (variant) { case 'warning': return require('../../assets/icons/warning.png') case 'info': return require('../../assets/icons/info.png') + + case 'error': + return require('../../assets/icons/error.png') } }apps/native/app/src/screens/home/hello-module.tsx (2)
Line range hint
63-67: Enhance error handling for image download failuresThe current implementation only logs errors to console without user feedback or retry mechanism.
Consider implementing a retry mechanism and user feedback:
} catch (e) { - console.error(e) - // Do nothing, try again next time + console.error('Failed to download image:', e) + // Implement retry logic with exponential backoff + const retryCount = 3 + for (let i = 0; i < retryCount; i++) { + try { + await new Promise(resolve => setTimeout(resolve, Math.pow(2, i) * 1000)) + await downloadResumable.downloadAsync() + return + } catch (retryError) { + console.error(`Retry ${i + 1}/${retryCount} failed:`, retryError) + } + } }
Line range hint
44-71: Optimize image caching implementationThe current implementation checks cache on every render and doesn't handle cache invalidation.
Consider implementing:
- Cache expiration
- Cache size limits
- Preloading for better UX
const handleImage = async () => { if (!image || !titleWithExtension) { return } const localPath = `${cacheDirectory}/${titleWithExtension}` const fileInfo = await FileSystem.getInfoAsync(localPath) + const CACHE_EXPIRY_HOURS = 24 + const isCacheExpired = fileInfo.exists && + (Date.now() - fileInfo.modificationTime > CACHE_EXPIRY_HOURS * 60 * 60 * 1000) - if (fileInfo.exists) { + if (fileInfo.exists && !isCacheExpired) { setImageSrc(fileInfo.uri) } else {apps/native/app/src/screens/home/inbox-module.tsx (1)
Line range hint
123-146: Consider implementing virtualization for better performanceThe current implementation renders all documents at once, which could impact performance with large lists.
Consider using FlatList for better performance:
- documents.map((item, index) => ( - <InboxCard - key={item.id} - subject={item.subject} - publicationDate={item.publicationDate} - id={`${item.id}-${index}`} - unread={!item.opened} - senderName={item.sender.name} - icon={ - item.sender.name && getOrganizationLogoUrl(item.sender.name, 75) - } - isUrgent={item.isUrgent} - onPress={() => - navigateTo(`/inbox/${item.id}`, { - title: item.sender.name, - isUrgent: item.isUrgent, - }) - } - /> - )) + <FlatList + data={documents} + renderItem={({ item, index }) => ( + <InboxCard + key={item.id} + subject={item.subject} + publicationDate={item.publicationDate} + id={`${item.id}-${index}`} + unread={!item.opened} + senderName={item.sender.name} + icon={ + item.sender.name && getOrganizationLogoUrl(item.sender.name, 75) + } + isUrgent={item.isUrgent} + onPress={() => + navigateTo(`/inbox/${item.id}`, { + title: item.sender.name, + isUrgent: item.isUrgent, + }) + } + /> + )} + keyExtractor={item => item.id} + initialNumToRender={10} + maxToRenderPerBatch={10} + windowSize={5} + />apps/native/app/src/lib/show-picker.ts (1)
Line range hint
126-146: Improve action handling consistencyThe action mapping logic is inconsistent between platforms and uses string literals.
Consider using an enum for actions and consistent mapping:
+export enum PickerAction { + SELECT = 'select', + NEGATIVE = 'negative', + NEUTRAL = 'neutral', + DISMISS = 'dismiss', +} - let actn: ShowPickerResponse['action'] = 'neutral' + let actn: PickerAction = PickerAction.NEUTRAL if (action === 'actionDismiss') { - actn = 'dismiss' + actn = PickerAction.DISMISS } else if (action === 'actionNegative') { - actn = 'negative' + actn = PickerAction.NEGATIVE } else if (action === 'actionSelect') { - actn = 'select' + actn = PickerAction.SELECT }apps/native/app/src/screens/onboarding/onboarding-biometrics.tsx (2)
11-11: Consider configuring path aliases for better maintainability.While the relative import path works, consider configuring TypeScript path aliases in the Nx workspace to maintain the convenience of absolute imports while keeping Nx compatibility.
Example tsconfig.json configuration:
{ "compilerOptions": { "paths": { "@ui/*": ["apps/native/app/src/ui/*"] } } }
Line range hint
66-74: Fix potential memory leak in AppState event listener.The AppState event listener is added but never removed, which could cause memory leaks. Always clean up event listeners in the useEffect hook.
useEffect(() => { - AppState.addEventListener('change', (state) => { + const subscription = AppState.addEventListener('change', (state) => { if (state === 'active') { // user may be coming back from settings where they were trying to // enroll into biometrics. isEnrolledAsync().then(setIsEnrolled) } }) + return () => { + subscription.remove() + } }, [])apps/native/app/src/screens/home/air-discount-module.tsx (2)
Line range hint
36-52: Simplify validation logic for better readability.The validation logic uses double negatives which makes it harder to understand. Consider simplifying the logic.
const validateAirDiscountInitialData = ({ data, loading, }: { data: GetAirDiscountQuery | undefined loading: boolean }) => { if (loading) { return true } - const noRights = - data?.airDiscountSchemeDiscounts?.filter( - (item) => item.user.fund?.credit === 0 && item.user.fund.used === 0, - ).length === data?.airDiscountSchemeDiscounts?.length - - // Only show widget initially if the user has air discount rights - if (!noRights) { - return true - } - - return false + // Show widget if any user has discount rights + return data?.airDiscountSchemeDiscounts?.some( + (item) => item.user.fund?.credit > 0 || item.user.fund?.used > 0 + ) ?? false }
Line range hint
71-82: Extract duplicate logic and define constants.The filtering logic is duplicated and there's a magic number in the slice operation. Consider these improvements:
+const MAX_VISIBLE_DISCOUNTS = 3; + +const hasDiscountRights = (item: { user: { fund?: { credit: number, used: number } } }) => + !(item.user.fund?.credit === 0 && item.user.fund?.used === 0); + const discounts = data?.airDiscountSchemeDiscounts?.filter( - ({ user }) => !(user.fund?.used === 0 && user.fund.credit === 0), + hasDiscountRights ) const count = discounts?.length ?? 0 const viewPagerItemWidth = screenWidth - theme.spacing[2] * 4 -const items = discounts?.slice(0, 3).map(({ discountCode, user }) => ( +const items = discounts?.slice(0, MAX_VISIBLE_DISCOUNTS).map(({ discountCode, user }) => (apps/native/app/src/screens/home/vehicles-module.tsx (2)
Line range hint
28-41: Optimize optional chaining in validation logic.The validation logic is sound but could be more concise with improved optional chaining.
const validateVehiclesInitialData = ({ data, loading, }: { data: ListVehiclesQuery | undefined loading: boolean }) => { if (loading) { return true } // Only show widget initially if there are vehicles that require mileage registration - if ( - data?.vehiclesList?.vehicleList?.some( - (vehicle) => vehicle.requiresMileageRegistration, - ) - ) { - return true - } - - return false + return data?.vehiclesList?.vehicleList?.some( + (vehicle) => vehicle.requiresMileageRegistration + ) ?? false }
Line range hint
63-79: Optimize sorting logic in useMemo.The sorting logic could be simplified, and the spread operation might be unnecessary.
const reorderedVehicles = useMemo( () => vehicles - ? [...vehicles]?.sort((a, b) => { - if ( - a.requiresMileageRegistration && - !b.requiresMileageRegistration - ) { - return -1 - } else if ( - !a.requiresMileageRegistration && - b.requiresMileageRegistration - ) { - return 1 - } - return 0 - }) - : vehicles, + ? vehicles.sort((a, b) => + Number(b.requiresMileageRegistration) - Number(a.requiresMileageRegistration) + ) + : vehicles, [vehicles], )apps/native/app/src/screens/settings/edit-bank-info.tsx (1)
Line range hint
1-24: Consider enhancing form validationThe bank information validation could be improved by:
- Adding input format validation for bank account numbers
- Implementing real-time validation feedback
Consider adding a validation helper:
const validateBankInfo = (bank: string, l: string, account: string): boolean => { const bankRegex = /^\d{4}$/; const lRegex = /^\d{2}$/; const accountRegex = /^\d{6}$/; return bankRegex.test(bank) && lRegex.test(l) && accountRegex.test(account); };apps/native/app/src/screens/settings/edit-email.tsx (1)
Line range hint
89-123: Consider enhancing error handling and email validationThe error handling could be improved by:
- Adding specific error messages for different failure scenarios
- Implementing proper email format validation before mutation
Consider adding email validation and specific error handling:
const isValidEmail = (email: string): boolean => { return /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email); }; // In the onPress handler: if (!isEmpty && !isValidEmail(text)) { Alert.alert( intl.formatMessage({ id: 'edit.email.error' }), intl.formatMessage({ id: 'edit.email.invalidFormat' }) ); return; }apps/native/app/src/screens/more/more.tsx (1)
Line range hint
73-146: Consider centralizing navigation logicThe screen contains multiple hardcoded navigation paths. Consider centralizing these in a routes configuration file for better maintainability.
Consider creating a routes configuration:
// src/navigation/routes.ts export const ROUTES = { PERSONAL_INFO: '/personalinfo', FAMILY: '/family', VEHICLES: '/vehicles', // ... other routes } as const; // Then use in component: onPress={() => navigateTo(ROUTES.PERSONAL_INFO)}apps/native/app/src/screens/applications/applications.tsx (1)
Line range hint
63-89: Consider memoizing sortApplicationsStatus functionThe sorting function could benefit from memoization when handling large lists of applications.
-export const sortApplicationsStatus = ( +export const sortApplicationsStatus = useMemo(() => ( applications: Application[], ): SortedApplication => { const incomplete: Application[] = [] const inProgress: Application[] = [] const completed: Application[] = [] applications.forEach((application) => { if ( application.status === ApplicationResponseDtoStatusEnum.Draft || application.status === ApplicationResponseDtoStatusEnum.Notstarted ) { incomplete.push(application) } else if ( application.status === ApplicationResponseDtoStatusEnum.Inprogress ) { inProgress.push(application) } else { completed.push(application) } }) return { incomplete, inProgress, completed, } -} +}), [applications])apps/native/app/src/screens/vehicles/vehicles.tsx (1)
Line range hint
93-117: Ensure cleanup of loadingTimeout on component unmountThe loadingTimeout ref should be cleared when the component unmounts to prevent memory leaks.
export const VehiclesScreen: NavigationFunctionComponent = ({ componentId, }) => { + useEffect(() => { + return () => { + if (loadingTimeout.current) { + clearTimeout(loadingTimeout.current) + } + } + }, [])apps/native/app/src/screens/applications/components/applications-list.tsx (1)
13-21: Consider using path aliases for deep importsThe relative import path
../../../uiis quite deep and could become difficult to maintain. Consider configuring path aliases in your TypeScript configuration to make imports more maintainable.Example tsconfig.json configuration:
{ "compilerOptions": { "baseUrl": ".", "paths": { "@ui/*": ["src/ui/*"] } } }apps/native/app/src/screens/assets/assets-overview.tsx (1)
Line range hint
92-108: Consider adding error feedback in onRefreshWhile the error handling is present, it silently fails without informing the user. Consider adding a toast or alert to notify users when the refresh fails.
} catch (err) { setRefetching(false) + // Add user feedback + showErrorToast(intl.formatMessage({ id: 'common.errors.refreshFailed' })); }apps/native/app/src/screens/app-lock/app-lock.tsx (2)
Line range hint
89-107: Enhance biometric authentication error handlingThe biometric authentication doesn't provide user feedback on failures. Consider adding error messages for different failure scenarios.
const authenticateWithBiometrics = async () => { if (!useBiometrics || isPromptRef.current) { return } isPromptRef.current = true const response = await authenticateAsync() if (response.success) { void selectionAsync() unlockApp() + } else { + // Handle specific error cases + switch (response.error) { + case 'user_cancel': + // Silent failure + break; + case 'lockout': + Alert.alert( + intl.formatMessage({ id: 'biometric.error.lockoutTitle' }), + intl.formatMessage({ id: 'biometric.error.lockoutMessage' }) + ); + break; + default: + Alert.alert( + intl.formatMessage({ id: 'biometric.error.genericTitle' }), + intl.formatMessage({ id: 'biometric.error.genericMessage' }) + ); + } } }
Line range hint
147-186: Consider adding rate limiting for PIN attemptsWhile there is a maximum attempt limit, there's no rate limiting between attempts. Consider adding a delay that increases with each failed attempt.
if (res && res.password === code) { unlockApp() } else { setAttempts((previousAttempts) => previousAttempts + 1) setInvalidCode(true) + // Add exponential backoff + const delay = Math.min(2000 * Math.pow(2, attempts), 30000); setTimeout(() => { setCode('') - }, 660) + }, delay) }apps/native/app/src/screens/notifications/notifications.tsx (1)
Line range hint
12-12: Consider using TypeScript path aliases in Nx workspaceWhile the relative imports work, consider leveraging TypeScript path aliases (e.g.,
@ui/*) configured throughtsconfig.base.jsonin your Nx workspace. This approach would:
- Make imports more maintainable across the monorepo
- Reduce the need for relative path calculations
- Make module resolution more explicit and easier to refactor
Example configuration in tsconfig.base.json:
{ "compilerOptions": { "paths": { "@ui/*": ["libs/ui/src/*"] } } }Also applies to: 16-16, 19-26
apps/native/app/src/screens/login/testing-login.tsx (2)
Line range hint
142-169: Consider extracting Chrome version check to a constantThe Chrome version check uses a magic number (55). Consider extracting this to a named constant with documentation explaining the compatibility requirements.
+const MIN_CHROME_VERSION = 55; // Minimum version required for WebView compatibility + if (Platform.OS === 'android') { const chromeVersion = await getChromeVersion() - if (chromeVersion < 55) { + if (chromeVersion < MIN_CHROME_VERSION) {
Line range hint
186-195: Improve error handling robustnessThe current error detection relies on string matching which is fragile. Consider using error types or error codes for more reliable error handling.
-if ((err as Error).message.indexOf('Connection error') >= 0) { +// Define error types +type LoginError = { + code: 'CONNECTION_ERROR' | 'AUTH_ERROR' | 'UNKNOWN_ERROR'; + message: string; +}; + +if ((err as LoginError).code === 'CONNECTION_ERROR') {apps/native/app/src/screens/document-detail/document-detail.tsx (2)
Line range hint
171-208: Enhance error handling in PdfViewer componentWhile the memoization is well implemented, consider enhancing the error handling by providing more specific error information to the parent component.
-onError={(err) => { - onError?.(err as Error) +onError={(err) => { + onError?.({ + code: 'PDF_LOAD_ERROR', + message: err.message, + details: err + } as PdfError)
Line range hint
266-271: Consider a more robust platform identification approachThe current approach of adding '_app' suffix is a temporary solution. Consider implementing a proper platform identification mechanism that the backend can use for distinguishing between app and web confirmations.
+const PLATFORM = 'mobile_app'; + const confirmAction = async (confirmed: boolean) => { - // Adding a suffix '_app' since the backend is currently not distinguishing between the app and the web await logConfirmedAction({ - variables: { input: { id: `${docId}_app`, confirmed: confirmed } }, + variables: { + input: { + id: docId, + confirmed: confirmed, + platform: PLATFORM + } + }, }) }
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (79)
apps/native/app/.babelrc.js(1 hunks)apps/native/app/src/components/bottom-tabs-indicator/bottom-tabs-indicator.tsx(1 hunks)apps/native/app/src/components/offline/offline-banner.tsx(1 hunks)apps/native/app/src/components/pin-keypad/pin-keypad.tsx(1 hunks)apps/native/app/src/components/visualized-pin-code/visualized-pin-code.tsx(1 hunks)apps/native/app/src/hooks/use-connectivity-indicator.ts(1 hunks)apps/native/app/src/lib/show-picker.ts(1 hunks)apps/native/app/src/screens/air-discount/air-discount.tsx(1 hunks)apps/native/app/src/screens/air-discount/airfares-usage-table.tsx(1 hunks)apps/native/app/src/screens/app-lock/app-lock.tsx(1 hunks)apps/native/app/src/screens/applications/applications.tsx(1 hunks)apps/native/app/src/screens/applications/components/applications-list.tsx(1 hunks)apps/native/app/src/screens/applications/components/applications-preview.tsx(2 hunks)apps/native/app/src/screens/assets/assets-detail.tsx(1 hunks)apps/native/app/src/screens/assets/assets-overview.tsx(1 hunks)apps/native/app/src/screens/cognito-auth/cognito-auth.tsx(1 hunks)apps/native/app/src/screens/document-detail/document-detail.tsx(1 hunks)apps/native/app/src/screens/document-detail/utils/get-buttons-for-actions.tsx(1 hunks)apps/native/app/src/screens/family/family-details.tsx(1 hunks)apps/native/app/src/screens/family/family-overview.tsx(1 hunks)apps/native/app/src/screens/finance/components/finance-status-card.tsx(1 hunks)apps/native/app/src/screens/finance/finance-status-detail.tsx(1 hunks)apps/native/app/src/screens/finance/finance.tsx(1 hunks)apps/native/app/src/screens/health/health-overview.tsx(1 hunks)apps/native/app/src/screens/home/air-discount-module.tsx(1 hunks)apps/native/app/src/screens/home/applications-module.tsx(1 hunks)apps/native/app/src/screens/home/hello-module.tsx(1 hunks)apps/native/app/src/screens/home/home-options.tsx(1 hunks)apps/native/app/src/screens/home/home.tsx(1 hunks)apps/native/app/src/screens/home/inbox-module.tsx(1 hunks)apps/native/app/src/screens/home/licenses-module.tsx(1 hunks)apps/native/app/src/screens/home/onboarding-module.tsx(1 hunks)apps/native/app/src/screens/home/vehicles-module.tsx(1 hunks)apps/native/app/src/screens/inbox/inbox-filter.tsx(1 hunks)apps/native/app/src/screens/inbox/inbox.tsx(1 hunks)apps/native/app/src/screens/license-scanner/license-scan-detail.tsx(1 hunks)apps/native/app/src/screens/license-scanner/license-scanner.tsx(1 hunks)apps/native/app/src/screens/login/login.tsx(1 hunks)apps/native/app/src/screens/login/testing-login.tsx(1 hunks)apps/native/app/src/screens/more/more.tsx(1 hunks)apps/native/app/src/screens/more/personal-info.tsx(1 hunks)apps/native/app/src/screens/notifications/notifications.tsx(1 hunks)apps/native/app/src/screens/onboarding/onboarding-biometrics.tsx(1 hunks)apps/native/app/src/screens/onboarding/onboarding-notifications.tsx(1 hunks)apps/native/app/src/screens/onboarding/onboarding-pin-code.tsx(1 hunks)apps/native/app/src/screens/passkey/passkey.tsx(1 hunks)apps/native/app/src/screens/settings/edit-bank-info.tsx(1 hunks)apps/native/app/src/screens/settings/edit-confirm.tsx(1 hunks)apps/native/app/src/screens/settings/edit-email.tsx(1 hunks)apps/native/app/src/screens/settings/edit-phone.tsx(1 hunks)apps/native/app/src/screens/settings/settings.tsx(1 hunks)apps/native/app/src/screens/update-app/update-app.tsx(1 hunks)apps/native/app/src/screens/vaccinations/components/vaccination-card.tsx(1 hunks)apps/native/app/src/screens/vaccinations/vaccinations.tsx(1 hunks)apps/native/app/src/screens/vehicles/components/mileage-cell.tsx(1 hunks)apps/native/app/src/screens/vehicles/components/vehicle-item.tsx(1 hunks)apps/native/app/src/screens/vehicles/vehicle-mileage.screen.tsx(1 hunks)apps/native/app/src/screens/vehicles/vehicles-detail.tsx(1 hunks)apps/native/app/src/screens/vehicles/vehicles.tsx(1 hunks)apps/native/app/src/screens/wallet-pass/components/field-render.tsx(1 hunks)apps/native/app/src/screens/wallet-pass/wallet-pass.tsx(1 hunks)apps/native/app/src/screens/wallet-passport/wallet-passport.tsx(1 hunks)apps/native/app/src/screens/wallet/components/wallet-item.tsx(1 hunks)apps/native/app/src/screens/wallet/wallet.tsx(1 hunks)apps/native/app/src/types/styled-components.d.ts(1 hunks)apps/native/app/src/ui/index.ts(2 hunks)apps/native/app/src/ui/lib/card/license-card.tsx(1 hunks)apps/native/app/src/ui/lib/date-picker/date-picker.tsx(1 hunks)apps/native/app/src/ui/lib/detail/header.tsx(1 hunks)apps/native/app/src/ui/lib/empty-state/empty-list.tsx(1 hunks)apps/native/app/src/ui/lib/empty-state/empty-state.stories.tsx(1 hunks)apps/native/app/src/ui/lib/input/input.tsx(1 hunks)apps/native/app/src/ui/lib/label/label.tsx(1 hunks)apps/native/app/src/ui/lib/link/link-text.tsx(1 hunks)apps/native/app/src/ui/lib/list/list-item.tsx(1 hunks)apps/native/app/src/ui/lib/problem/problem-template.tsx(1 hunks)apps/native/app/src/ui/lib/search-bar/search-bar.tsx(1 hunks)apps/native/app/src/utils/get-theme-with-preferences.ts(1 hunks)tsconfig.base.json(0 hunks)
💤 Files with no reviewable changes (1)
- tsconfig.base.json
✅ Files skipped from review due to trivial changes (35)
- apps/native/app/src/screens/air-discount/airfares-usage-table.tsx
- apps/native/app/src/components/visualized-pin-code/visualized-pin-code.tsx
- apps/native/app/src/ui/lib/label/label.tsx
- apps/native/app/src/screens/vehicles/components/mileage-cell.tsx
- apps/native/app/src/screens/air-discount/air-discount.tsx
- apps/native/app/src/ui/lib/search-bar/search-bar.tsx
- apps/native/app/src/hooks/use-connectivity-indicator.ts
- apps/native/app/src/screens/home/home-options.tsx
- apps/native/app/src/ui/lib/link/link-text.tsx
- apps/native/app/src/screens/finance/finance.tsx
- apps/native/app/src/screens/settings/edit-phone.tsx
- apps/native/app/src/screens/more/personal-info.tsx
- apps/native/app/src/screens/wallet-passport/wallet-passport.tsx
- apps/native/app/src/screens/health/health-overview.tsx
- apps/native/app/src/ui/lib/card/license-card.tsx
- apps/native/app/src/screens/wallet/components/wallet-item.tsx
- apps/native/app/src/screens/vaccinations/vaccinations.tsx
- apps/native/app/src/screens/cognito-auth/cognito-auth.tsx
- apps/native/app/src/screens/settings/edit-confirm.tsx
- apps/native/app/src/screens/wallet-pass/wallet-pass.tsx
- apps/native/app/src/components/bottom-tabs-indicator/bottom-tabs-indicator.tsx
- apps/native/app/src/screens/vehicles/vehicles-detail.tsx
- apps/native/app/src/screens/inbox/inbox-filter.tsx
- apps/native/app/src/screens/applications/components/applications-preview.tsx
- apps/native/app/src/ui/lib/date-picker/date-picker.tsx
- apps/native/app/src/screens/vaccinations/components/vaccination-card.tsx
- apps/native/app/src/screens/vehicles/vehicle-mileage.screen.tsx
- apps/native/app/src/screens/assets/assets-detail.tsx
- apps/native/app/src/screens/family/family-details.tsx
- apps/native/app/src/ui/lib/list/list-item.tsx
- apps/native/app/src/screens/home/home.tsx
- apps/native/app/src/screens/wallet-pass/components/field-render.tsx
- apps/native/app/src/screens/login/login.tsx
- apps/native/app/src/screens/passkey/passkey.tsx
- apps/native/app/src/screens/inbox/inbox.tsx
🚧 Files skipped from review as they are similar to previous changes (1)
- apps/native/app/.babelrc.js
🧰 Additional context used
📓 Path-based instructions (42)
apps/native/app/src/screens/wallet/wallet.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/native/app/src/ui/lib/empty-state/empty-list.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/native/app/src/screens/settings/settings.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/native/app/src/screens/document-detail/utils/get-buttons-for-actions.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/native/app/src/components/offline/offline-banner.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/native/app/src/screens/license-scanner/license-scan-detail.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/native/app/src/screens/home/onboarding-module.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/native/app/src/ui/lib/empty-state/empty-state.stories.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/native/app/src/lib/show-picker.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/native/app/src/ui/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/native/app/src/screens/applications/components/applications-list.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/native/app/src/screens/vehicles/components/vehicle-item.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/native/app/src/types/styled-components.d.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/native/app/src/screens/notifications/notifications.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/native/app/src/screens/onboarding/onboarding-notifications.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/native/app/src/screens/settings/edit-email.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/native/app/src/screens/update-app/update-app.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/native/app/src/screens/home/applications-module.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/native/app/src/screens/more/more.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/native/app/src/screens/settings/edit-bank-info.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/native/app/src/screens/finance/finance-status-detail.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/native/app/src/ui/lib/input/input.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/native/app/src/screens/vehicles/vehicles.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/native/app/src/screens/applications/applications.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/native/app/src/screens/finance/components/finance-status-card.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/native/app/src/screens/onboarding/onboarding-biometrics.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/native/app/src/screens/home/hello-module.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/native/app/src/screens/assets/assets-overview.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/native/app/src/screens/home/inbox-module.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/native/app/src/screens/family/family-overview.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/native/app/src/ui/lib/detail/header.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/native/app/src/screens/login/testing-login.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/native/app/src/screens/home/vehicles-module.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/native/app/src/components/pin-keypad/pin-keypad.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/native/app/src/screens/license-scanner/license-scanner.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/native/app/src/screens/home/air-discount-module.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/native/app/src/screens/onboarding/onboarding-pin-code.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/native/app/src/screens/app-lock/app-lock.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/native/app/src/screens/document-detail/document-detail.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/native/app/src/ui/lib/problem/problem-template.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/native/app/src/screens/home/licenses-module.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/native/app/src/utils/get-theme-with-preferences.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 (44)
apps/native/app/src/screens/vehicles/components/vehicle-item.tsx (1)
Line range hint 1-93: Implementation looks good!
The component is well-structured with:
- Proper TypeScript types
- Performance optimization using React.memo
- Clean separation of styled components
- Good handling of inspection deadlines and mileage requirements
apps/native/app/src/screens/home/onboarding-module.tsx (1)
4-6: LGTM! Import reorganization aligns with nx migration.
The separation of imports and switch to relative paths from @ui package aligns well with the PR objective of moving to nx framework and improving library management within the monorepo.
apps/native/app/src/types/styled-components.d.ts (1)
2-2: Verify the relative import path.
The change from @ui to ../ui aligns with the PR objective of moving to nx framework. However, let's verify that this relative path correctly resolves to the UI package.
✅ Verification successful
Import path is correct and properly resolves to the UI package
The relative import path ../ui is correct as:
- The Theme type is exported from
apps/native/app/src/ui/utils/theme.ts - The path correctly resolves from
apps/native/app/src/types/styled-components.d.tsto the UI package - Multiple UI components in the codebase are using Theme-related functionality from this package
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the UI package location relative to the styled-components.d.ts file
# Check if the ui directory exists at the expected location
cd apps/native/app/src && ls -la ui
# Verify other files importing from the same location
rg -t typescript "from ['|\"].*ui['|\"]" .
Length of output: 459
Script:
#!/bin/bash
# Let's verify the import path more thoroughly
# First, check if there's a Theme export in the ui directory
rg --type-add 'ts:*.{ts,tsx}' -l "export.*Theme" apps/native/app/src/ui/
# Check for any Theme-related files in the ui directory
fd -e ts -e tsx . apps/native/app/src/ui/ -x grep -l "Theme"
# Look for other files importing Theme from ui
rg --type-add 'ts:*.{ts,tsx}' "import.*Theme.*from.*ui" apps/native/app/src/
Length of output: 1833
apps/native/app/src/screens/family/family-overview.tsx (2)
Line range hint 14-19: LGTM: Import paths updated correctly for nx migration
The change from absolute to relative imports aligns with the nx framework migration and ensures consistent import patterns across the codebase.
Line range hint 29-45: LGTM: Well-structured component with proper optimizations
The component implementation demonstrates good practices:
- Effective use of React.memo for performance
- Clean component structure
- Proper type safety with TypeScript
apps/native/app/src/screens/document-detail/utils/get-buttons-for-actions.tsx (1)
Line range hint 10-20: LGTM! Well-structured styled components
The styled components are well-implemented with proper TypeScript typing, consistent theme usage, and flexible layout handling.
apps/native/app/src/screens/license-scanner/license-scan-detail.tsx (1)
10-10: LGTM: Import path update aligns with nx structure
The change from @ui to relative path ../../ui is correct for the nx monorepo structure.
apps/native/app/src/screens/license-scanner/license-scanner.tsx (1)
37-38: LGTM: Import updates align with nx structure
The changes to import paths and addition of flashlight icon are correct.
apps/native/app/src/screens/update-app/update-app.tsx (1)
9-10: Verify import path consistency across the Nx workspace
The change from @ui to relative imports should be consistent with Nx workspace patterns.
✅ Verification successful
Import path changes are consistent across the codebase
The migration from @ui to relative imports has been consistently implemented across the native app. All UI component imports now use relative paths (../../ui or ../../../ui depending on the file location), and there are no remaining @ui imports in the codebase. This change aligns with the Nx workspace structure.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for any remaining @ui imports that should have been migrated
# and verify the consistency of UI component imports across the native app
# Check for any remaining @ui imports
echo "Checking for remaining @ui imports..."
rg "from ['|\"]@ui" apps/native/app/src
# Verify UI component import patterns
echo "Verifying UI component import patterns..."
rg "from ['\"]\.\.\/\.\.\/ui['\"]" apps/native/app/src
Length of output: 389
Script:
#!/bin/bash
# Let's try a simpler approach to check import patterns
# Check for any remaining @ui imports
echo "Checking for remaining @ui imports..."
rg "@ui" apps/native/app/src
# Check relative UI imports with proper escaping
echo "Checking relative UI imports..."
rg "from ['\"]\\.\\./.*/ui['\"]" apps/native/app/src
# List all files that import from UI to analyze the patterns
echo "Listing files with UI imports..."
rg -l "from.*ui['\"]" apps/native/app/src
Length of output: 10795
apps/native/app/src/utils/get-theme-with-preferences.ts (1)
Line range hint 1-105: Verify theme usage across the application
Since this is a critical UI utility affecting the entire app, let's verify its usage.
✅ Verification successful
Theme implementation is correctly used and isolated
The verification shows that the theme implementation in get-theme-with-preferences.ts is properly isolated and used consistently:
- The theme utility is only imported and used within the native app context (
apps/native/app/src/) - Theme usage is properly scoped through the
getThemeWithPreferencesfunction which is used by core app components liketheme-provider.tsxand navigation hooks - Direct theme property access follows a consistent pattern across components using the defined theme structure
- No conflicting or inconsistent theme implementations were found
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for all theme usages to ensure consistency
echo "Checking theme imports..."
rg -l "import.*theme" --type ts --type tsx
echo "\nChecking getThemeWithPreferences usage..."
rg -l "getThemeWithPreferences" --type ts --type tsx
echo "\nChecking direct theme property access..."
rg "theme\.(color|shade|spacing)" --type ts --type tsx
Length of output: 491
Script:
#!/bin/bash
# Search for all theme usages to ensure consistency
echo "Checking theme imports..."
rg -l "import.*theme"
echo -e "\nChecking getThemeWithPreferences usage..."
rg -l "getThemeWithPreferences"
echo -e "\nChecking direct theme property access..."
rg "theme\.(color|shade|spacing)"
# Also check for theme object usage
echo -e "\nChecking theme object usage..."
rg "themes\.[a-zA-Z]+"
Length of output: 66644
apps/native/app/src/screens/finance/finance-status-detail.tsx (1)
8-8: LGTM: Import path change aligns with nx migration
The change from @ui to relative import path ../../ui is consistent with the PR objective of moving to nx framework.
apps/native/app/src/screens/finance/components/finance-status-card.tsx (2)
1-12: LGTM: Import organization aligns with nx standards
The restructured imports and relative paths are consistent with nx framework standards.
Line range hint 89-279: Verify GraphQL query optimization
The GraphQL query is skipped when the card is not open, which is good. However, consider implementing data caching to prevent unnecessary refetches when reopening the card.
apps/native/app/src/screens/settings/settings.tsx (1)
22-29: Verify UI component imports after nx migration
The change from '@ui' to relative imports aligns with the nx migration. However, we should ensure these components exist in the new location.
✅ Verification successful
UI components are correctly imported after nx migration
All imported UI components are properly available in the new location:
Alertis exported from './lib/alert/alert'NavigationBarSheetis exported from './lib/navigation-bar-sheet/navigation-bar-sheet'TableViewCellandTableViewAccessoryare defined in './lib/tableview/tableview-cell'TableViewGroupis exported from './lib/tableview/tableview-group'
The relative import path '../../ui' correctly points to these components, which are all properly exported through the UI package's index.ts file.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify that the UI components exist in the new location
# Check if the UI components exist in the new location
fd -t f "^(Alert|NavigationBarSheet|TableViewAccessory|TableViewCell|TableViewGroup)\.(tsx|ts)$" "apps/native/app/src/ui"
Length of output: 121
Script:
#!/bin/bash
# Let's try a broader search to understand the UI components structure
fd -t f "index.ts" "apps/native/app/src/ui"
# Also search for these components in case they are exported from a different file
rg -l "export.*\b(Alert|NavigationBarSheet|TableViewAccessory|TableViewCell|TableViewGroup)\b" "apps/native/app/src/ui"
# Check if these components are defined in any tsx/ts files under ui directory
rg -l "class.*(Alert|NavigationBarSheet|TableViewAccessory|TableViewCell|TableViewGroup)|function.*(Alert|NavigationBarSheet|TableViewAccessory|TableViewCell|TableViewGroup)" "apps/native/app/src/ui"
Length of output: 776
Script:
#!/bin/bash
# Let's verify TableViewAccessory specifically as it wasn't found in previous searches
rg -l "TableViewAccessory" "apps/native/app/src/ui"
# Also check the index.ts to see how these components are exported
cat "apps/native/app/src/ui/index.ts"
Length of output: 2860
Script:
#!/bin/bash
# Let's check the content of tableview-cell.tsx to understand TableViewAccessory
cat "apps/native/app/src/ui/lib/tableview/tableview-cell.tsx"
Length of output: 3965
apps/native/app/src/screens/home/licenses-module.tsx (1)
Line range hint 1-196: Verify integration with Nx framework
As part of the migration to Nx, let's verify the module's integration with the framework and its dependencies.
✅ Verification successful
Module integration with Nx framework is properly structured
The verification shows that:
- All UI components are correctly imported from the relative path
../../ui - GraphQL types and queries are properly structured and imported from the schema
- The app has the required Nx configuration files (project.json and tsconfig files)
- Import paths follow a consistent relative path pattern
- No circular dependencies were detected in the module structure
The module maintains proper boundaries and follows Nx's recommended practices for module organization.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify module integration with Nx framework
# Check for proper module boundaries in Nx
ast-grep --pattern 'from "@island-is/[^"]*"'
# Verify import paths are correctly updated
rg -l "from '@ui'"
# Check for potential circular dependencies
ast-grep --pattern 'from "../../'
Length of output: 109
Script:
#!/bin/bash
# Let's verify the module's integration and dependencies with more specific checks
# Check all imports in the file
rg -A 1 "^import .* from" "apps/native/app/src/screens/home/licenses-module.tsx"
# Check if UI components are properly imported
rg -A 1 "from '../../ui'" "apps/native/app/src/screens/home/licenses-module.tsx"
# Check GraphQL types and queries
rg -A 1 "from '../../graphql'" "apps/native/app/src/screens/home/licenses-module.tsx"
# Check for any potential circular dependencies with wallet
rg -A 1 "from '../wallet'" "apps/native/app/src/screens/home/licenses-module.tsx"
Length of output: 934
Script:
#!/bin/bash
# Let's verify the module structure and dependencies more thoroughly
# Check the UI components being used
rg -A 1 "Typography|Heading|ChevronRight|ViewPager|EmptyCard|GeneralCardSkeleton" "apps/native/app/src/screens/home/licenses-module.tsx"
# Check the actual GraphQL types and queries being used
rg -A 1 "GenericLicenseType|GetIdentityDocumentQuery|ListLicensesQuery|useGetIdentityDocumentQuery|useListLicensesQuery" "apps/native/app/src/screens/home/licenses-module.tsx"
# Check if there are any project.json or similar Nx configuration files
fd -t f "project.json|workspace.json" apps/native/app/
# Check for tsconfig paths to verify module resolution
fd -t f "tsconfig.*json" apps/native/app/
Length of output: 2173
apps/native/app/src/ui/lib/empty-state/empty-list.tsx (1)
5-5: LGTM! Import path update aligns with nx migration.
The relative import path change is correct and consistent with the nx monorepo structure.
apps/native/app/src/ui/lib/empty-state/empty-state.stories.tsx (1)
5-8: LGTM! Import organization and story structure.
The relative import path changes are correct and the story structure follows Storybook best practices.
apps/native/app/src/components/offline/offline-banner.tsx (1)
5-5: LGTM! Import path updates are consistent.
The relative import paths for UI components align with the nx migration strategy.
apps/native/app/src/screens/onboarding/onboarding-notifications.tsx (1)
4-5: Verify the relative import path resolution
The import path change from '@ui' to '../../ui' aligns with the nx migration. However, let's verify that the path resolution works correctly in the nx workspace.
✅ Verification successful
Import path resolution is correct
The relative import path ../../ui is valid and correct. The verification shows that:
- The UI module exists at
apps/native/app/src/ui/index.ts - All imported components (Button, CancelButton, Illustration, Onboarding) are properly exported from the UI module
- The relative path correctly resolves from the onboarding-notifications.tsx location to the UI module
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the UI module's location and import path resolution
# Expected: Find the UI module at the specified relative path
# Check if the UI module exists at the relative path
fd -t f "index.ts" apps/native/app/src/ui
# Verify no remaining @ui imports in the codebase
rg "@ui" apps/native/app
Length of output: 136
Script:
#!/bin/bash
# Let's verify the actual content and exports from the UI module
cat apps/native/app/src/ui/index.ts
# Check if the components mentioned in the import are actually exported
rg -l "Button|CancelButton|Illustration|Onboarding" apps/native/app/src/ui/
Length of output: 3537
apps/native/app/src/screens/home/applications-module.tsx (1)
7-7: LGTM! Import path change is consistent
The import path modification aligns with the nx migration pattern seen across other files while maintaining the component's functionality.
apps/native/app/src/ui/index.ts (2)
65-65: Verify bullet component existence and usage
Let's ensure the bullet component exists and is properly utilized in the codebase.
✅ Verification successful
Bullet component exists and is properly used in the codebase
The verification confirms that:
- The bullet component exists at
apps/native/app/src/ui/lib/bullet/bullet.tsx - It's actively used in the air-discount screen component
- The export statement in the index file correctly corresponds to the component's location
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify bullet component existence and usage
# Expected: Find component file and its imports
# Check if component exists
fd -t f "bullet.tsx" apps/native/app/src/ui/lib/bullet
# Find usages of the component
rg "Bullet" apps/native/app
Length of output: 920
23-23: Verify air-discount-card component existence and usage
Let's ensure the newly exported component exists and is properly utilized in the codebase.
✅ Verification successful
Component exists and is properly used in the codebase
The AirDiscountCard component is correctly implemented and actively used:
- Component is defined in
apps/native/app/src/ui/lib/card/air-discount-card.tsx - Used in multiple screens:
- Home screen's air discount module
- Air discount screen with multiple instances
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify air-discount-card component existence and usage
# Expected: Find component file and its imports
# Check if component exists
fd -t f "air-discount-card.tsx" apps/native/app/src/ui/lib/card
# Find usages of the component
rg "AirDiscountCard" apps/native/app
Length of output: 659
apps/native/app/src/ui/lib/detail/header.tsx (1)
7-7: LGTM: Import path update aligns with Nx migration
The relative import path change is consistent with the PR's objective of moving to Nx framework for better monorepo library management.
apps/native/app/src/ui/lib/input/input.tsx (1)
5-6: LGTM: Import path update aligns with Nx migration
The relative import path change is consistent with the PR's objective of moving to Nx framework for better monorepo library management.
apps/native/app/src/ui/lib/problem/problem-template.tsx (1)
5-7: LGTM: Import path updates align with Nx migration
The relative import paths are consistent with the PR's objective of moving to Nx framework for better monorepo library management.
apps/native/app/src/screens/home/hello-module.tsx (1)
7-7: LGTM: Import path update aligns with monorepo structure
The change from @ui to relative import path is consistent with the PR objective of improving monorepo library imports.
apps/native/app/src/screens/home/inbox-module.tsx (1)
7-14: LGTM: Import consolidation improves maintainability
The consolidation of UI component imports from @ui to relative paths aligns with the PR objective and improves code organization.
apps/native/app/src/lib/show-picker.ts (1)
3-3: LGTM: Import path update aligns with monorepo structure
The change from @ui to relative import path is consistent with the PR objective.
apps/native/app/src/screens/settings/edit-bank-info.tsx (1)
9-9: LGTM: Import path change aligns with nx monorepo structure
The change from @ui to ../../ui is consistent with the PR objective of moving to nx framework.
apps/native/app/src/screens/settings/edit-email.tsx (1)
10-10: LGTM: Import path change aligns with nx monorepo structure
The change from @ui to ../../ui is consistent with the PR objective of moving to nx framework.
apps/native/app/src/screens/more/more.tsx (2)
8-8: LGTM: Import path change aligns with nx monorepo structure
The change from @ui to ../../ui is consistent with the PR objective of moving to nx framework.
8-10: Verify consistent import path updates across the codebase
Let's ensure all UI component imports have been consistently updated from '@ui' to relative paths.
Also applies to: 8-8, 10-10
✅ Verification successful
Import paths have been consistently updated across the codebase
The verification shows that:
- No instances of imports from '@ui' were found in the codebase
- All UI component imports consistently use the relative path '../../ui'
- The changes in the reviewed file align with the project-wide import pattern
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for any remaining '@ui' imports and verify relative path imports
echo "Checking for any remaining '@ui' imports..."
rg "from '@ui'" apps/native/app/src
echo "Verifying relative UI imports..."
rg "from '../../ui'" apps/native/app/src
Length of output: 5761
apps/native/app/src/screens/onboarding/onboarding-pin-code.tsx (2)
11-11: LGTM: Import path updated for nx compatibility
The change from @ui to relative path ../../ui aligns with the nx monorepo structure, improving maintainability and module resolution.
Line range hint 71-86: Verify PIN code storage security implementation
The PIN code storage implementation uses Keychain, which is secure. However, let's verify the implementation across the codebase for consistency.
✅ Verification successful
Let me gather more information about the PIN code implementation to ensure complete verification.
Let me gather more specific information about the PIN code validation and security patterns.
Based on the gathered information, I can now provide a final response about the PIN code storage security implementation.
PIN code implementation is secure with appropriate safeguards
- PIN code is stored securely using Keychain with a dedicated service identifier 'PIN_CODE'
- Implementation includes:
- Fixed PIN length (MAX_PIN_CHARS = 4)
- Maximum attempts limit (MAX_ATTEMPTS = 3)
- State management through preferencesStore for onboarding status
- Proper validation before unlocking the app
- Clean reset functionality on logout/failure
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check PIN code storage implementation across the codebase
# Look for any other Keychain usage patterns that might need similar updates
# Search for Keychain usage patterns
rg -A 5 "Keychain\.setGenericPassword"
# Look for PIN_CODE service usage
rg "service: 'PIN_CODE'"
Length of output: 1795
Script:
#!/bin/bash
# Check for any PIN code constants or configurations
rg -i "pin.*code" -A 3
# Look for any other Keychain related operations
ast-grep --pattern 'Keychain.$_($$$)'
# Check for any PIN validation or security related patterns
rg -i "validate.*pin|check.*pin" -A 3
Length of output: 95263
Script:
#!/bin/bash
# Look for PIN code validation and security related code
rg -A 5 "hasOnboardedPinCode|PIN_CODE"
# Check for any PIN code related constants
rg -A 2 "MAX_PIN|PIN_LENGTH"
# Look for any PIN code related store or state management
rg -A 5 "preferencesStore.*pin"
Length of output: 6749
apps/native/app/src/screens/applications/applications.tsx (1)
8-8: LGTM: Import path updated for nx compatibility
The change from @ui to relative path ../../ui aligns with the nx monorepo structure.
apps/native/app/src/screens/vehicles/vehicles.tsx (1)
14-14: LGTM: Import path updated for nx compatibility
The change from @ui to relative path ../../ui aligns with the nx monorepo structure.
apps/native/app/src/screens/applications/components/applications-list.tsx (1)
Line range hint 1-24: LGTM: Well-structured imports and type definitions
The imports are well-organized, and proper TypeScript types are used for the component props.
apps/native/app/src/screens/assets/assets-overview.tsx (1)
Line range hint 110-146: Verify pagination edge cases
The pagination logic handles the basic cases but might have edge cases around the cursor calculation. Consider adding additional checks:
✅ Verification successful
Based on the search results, I can now provide a comprehensive verification of the pagination implementation. The code shows several pagination implementations across the codebase, and I can make a definitive assessment.
Cursor calculation and edge cases are properly handled
The current implementation correctly handles the essential edge cases:
- The cursor calculation uses Math.ceil() to ensure proper page boundaries
- There's a guard clause checking against total pages to prevent over-pagination
- The fetchMore is only called when there's data and the fetchMore function exists
- The updateQuery properly merges previous and new data arrays
The implementation follows the same pattern as other paginated lists in the codebase, like in libs/portals/my-pages/assets/src/screens/AssetsOverview/AssetsOverview.tsx which uses a similar cursor calculation approach.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for other pagination implementations to ensure consistency
ast-grep --pattern 'fetchMore({
$$$
updateQuery: $_
$$$
})'
Length of output: 67
Script:
#!/bin/bash
# Let's try a different pattern to search for pagination implementations
rg -A 5 "fetchMore\("
# Also search for cursor calculations
rg -A 3 "cursor.*=|newCursor.*="
# And search for updateQuery implementations
rg -A 5 "updateQuery.*="
Length of output: 92305
apps/native/app/src/screens/app-lock/app-lock.tsx (1)
19-20: LGTM: Clean import restructuring
The import path changes align with the PR objective of moving to Nx and enabling monorepo library imports.
apps/native/app/src/components/pin-keypad/pin-keypad.tsx (1)
12-12: Verify UI package path resolution in Nx workspace
The import path change aligns with the migration to Nx. However, we should verify that the relative path correctly resolves in the new Nx workspace structure.
✅ Verification successful
Import path change is correct and verified
The relative import path ../../ui correctly resolves to the UI utilities in the native app. The search results confirm:
- The component is located at
apps/native/app/src/components/pin-keypad/pin-keypad.tsx - The imported utilities exist at:
apps/native/app/src/ui/utils/dynamic-color.tsapps/native/app/src/ui/utils/font.ts
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the existence and structure of the UI package
# Test: Check if the UI package exists at the expected location and exports the required components
# Check if the ui directory exists
fd -t d "ui$" --max-depth 4
# Verify the exports from the UI package
rg -l "export.*{.*dynamicColor.*font"
Length of output: 206
Script:
#!/bin/bash
# Let's fix the regex and check both the old and new paths for UI exports
# Check the content of the UI directory
fd -t f . libs/island-ui/
# Search for exports of dynamicColor and font with proper regex
rg -l "export.*dynamicColor"
rg -l "export.*font"
# Check the relative path resolution from the component
fd "pin-keypad.tsx"
Length of output: 35688
apps/native/app/src/screens/wallet/wallet.tsx (1)
16-16: Verify all UI components are exported from the new path
The import path change is consistent with the Nx migration. Let's ensure all required UI components (Alert, EmptyList, GeneralCardSkeleton, TopLine) are properly exported from the new location.
✅ Verification successful
All required UI components are available in the new path
The verification confirms that all components (Alert, EmptyList, GeneralCardSkeleton, TopLine) are present in the app's UI directory:
apps/native/app/src/ui/lib/alert/alert.tsxapps/native/app/src/ui/lib/empty-state/empty-list.tsxapps/native/app/src/ui/lib/skeleton/general-card-skeleton.tsxapps/native/app/src/ui/lib/top-line/top-line.tsx
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify that all required UI components are exported from the new path
# Test: Check for component exports in the UI package
# Search for component exports
ast-grep --pattern 'export { $_ as Alert }'
ast-grep --pattern 'export { $_ as EmptyList }'
ast-grep --pattern 'export { $_ as GeneralCardSkeleton }'
ast-grep --pattern 'export { $_ as TopLine }'
Length of output: 203
Script:
#!/bin/bash
# Let's try a different approach to find these components and their exports
# First, let's find the UI components directory
fd -t f "index.ts" -X grep -l "export.*Alert\|export.*EmptyList\|export.*GeneralCardSkeleton\|export.*TopLine"
# Then let's search for the component definitions
fd -t f "Alert.tsx|EmptyList.tsx|GeneralCardSkeleton.tsx|TopLine.tsx"
# Also search for these components in barrel files
rg "export.*Alert|export.*EmptyList|export.*GeneralCardSkeleton|export.*TopLine" -g "index.ts"
Length of output: 2368
Script:
#!/bin/bash
# Let's specifically look in the ui directory relative to the wallet.tsx file location
# and its parent directories for these components
# First, find the exact location of wallet.tsx to understand the relative path
fd -t f "wallet.tsx"
# Then search for component definitions and exports in nearby ui directories
rg -l "Alert|EmptyList|GeneralCardSkeleton|TopLine" --type typescript -g "ui/**"
# Also check for these specific component definitions
ast-grep --pattern 'const $_: React.FC = $_' -l
Length of output: 392
Script:
#!/bin/bash
# Let's try one final approach to locate these components
# Search for the components in TypeScript/React files
rg -t tsx -t ts -l "export.*Alert|export.*EmptyList|export.*GeneralCardSkeleton|export.*TopLine"
# Look for component definitions
rg -t tsx -t ts "const (Alert|EmptyList|GeneralCardSkeleton|TopLine).*=.*React" -A 2
# Search specifically in the app's ui directory
fd -t f -e tsx -e ts . apps/native/app/src/ui -x grep -l "Alert\|EmptyList\|GeneralCardSkeleton\|TopLine"
Length of output: 712
apps/native/app/src/screens/notifications/notifications.tsx (1)
19-26: LGTM! Import restructuring improves readability
The multi-line import structure and path change are well-organized. The changes are consistent with the Nx migration pattern seen across other files.
✅ Verification successful
Import changes are correctly structured and components are available
The verification confirms that all imported components (Button, NavigationBarSheet, NotificationCard, Problem, ListItemSkeleton, EmptyList) are properly exported from the UI library through the barrel file at apps/native/app/src/ui/index.ts. The import path ../../ui is also correctly structured according to the project's directory layout.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify UI components availability and exports
# Test: Check for component exports in the new structure
# Verify UI package exports
ast-grep --pattern 'export {
$$$
Button,
NavigationBarSheet,
NotificationCard,
Problem,
ListItemSkeleton,
EmptyList,
$$$
}'
Length of output: 141
Script:
#!/bin/bash
# Let's verify each component's existence and their exports individually
# First, find potential UI component files
fd -e tsx -e ts "Button|NavigationBarSheet|NotificationCard|Problem|ListItemSkeleton|EmptyList" src/ui
# Then check for exports of these components
rg -l "export.*Button|export.*NavigationBarSheet|export.*NotificationCard|export.*Problem|export.*ListItemSkeleton|export.*EmptyList" --type ts --type tsx
# Check for barrel exports in ui directory
fd "index.ts" src/ui -x cat {}
# Check if these components are imported from ui directory in other files
rg "from ['|\"].*ui['|\"].*Button|from ['|\"].*ui['|\"].*NavigationBarSheet|from ['|\"].*ui['|\"].*NotificationCard|from ['|\"].*ui['|\"].*Problem|from ['|\"].*ui['|\"].*ListItemSkeleton|from ['|\"].*ui['|\"].*EmptyList"
Length of output: 757
Script:
#!/bin/bash
# Let's first find the correct UI components directory structure
fd -t d "ui"
# Then search for these component files in the entire codebase
fd -e tsx -e ts "Button|NavigationBarSheet|NotificationCard|Problem|ListItemSkeleton|EmptyList"
# Look for imports of these components across the codebase
rg "import.*\{.*(?:Button|NavigationBarSheet|NotificationCard|Problem|ListItemSkeleton|EmptyList).*\}.*from.*ui"
# Find any index files that might export these components
fd "index" -e ts -e tsx -x cat {}
Length of output: 103141
Script:
#!/bin/bash
# Let's try to find the UI components in the apps/native directory
fd -t f -e tsx -e ts . apps/native/app/src/ui
# Check for exports in any index files under ui directory
fd index.ts -e tsx apps/native/app/src/ui -x cat {}
# Look for these specific component imports in notifications.tsx
rg "import.*\{.*(?:Button|NavigationBarSheet|NotificationCard|Problem|ListItemSkeleton|EmptyList).*\}.*from.*['\"]\.\.\/\.\.\/ui['\"]" apps/native/app/src/screens/notifications/notifications.tsx
Length of output: 5685
Script:
#!/bin/bash
# Check contents of index.ts in ui directory
cat apps/native/app/src/ui/index.ts
# Check for imports in notifications.tsx with simpler pattern
rg "from '../../ui'" apps/native/app/src/screens/notifications/notifications.tsx
Length of output: 2861
apps/native/app/src/screens/login/testing-login.tsx (1)
17-18: LGTM: Import path changes align with nx framework migration
The change from absolute imports (@ui) to relative imports (../../ui) is consistent with the PR's objective of transitioning to the nx framework.
apps/native/app/src/screens/document-detail/document-detail.tsx (1)
Line range hint 523-534: Consider using an HTML sanitizer library
The current approach of using regex to remove <br /> tags is fragile and might break with complex HTML content. Consider using a proper HTML sanitization library.
thoreyjona
force-pushed
the
feat/use-nx-for-native-app
branch
from
1e62804 to
b1c9d16
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (1)
apps/native/app/Gemfile (1)
9-9: LGTM with minor formatting suggestionThe dependency versions are appropriately constrained. Consider sorting gems alphabetically within their sections for better maintainability.
-gem 'cocoapods', '>= 1.13', '< 1.15' -gem 'activesupport', '>= 6.1.7.5', '< 7.1.0' +gem 'activesupport', '>= 6.1.7.5', '< 7.1.0' +gem 'cocoapods', '>= 1.13', '< 1.15'🧰 Tools
🪛 rubocop (1.68.0)
[convention] 9-9: Gems should be sorted in an alphabetical order within their section of the Gemfile. Gem
activesupportshould appear beforecocoapods.(Bundler/OrderedGems)
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (82)
.gitignore(1 hunks)apps/native/app/.babelrc.js(1 hunks)apps/native/app/.bundle/config(1 hunks)apps/native/app/.eslintrc.json(1 hunks)apps/native/app/.gitignore(0 hunks)apps/native/app/Gemfile(1 hunks)apps/native/app/android/app/build.gradle(2 hunks)apps/native/app/android/settings.gradle(1 hunks)apps/native/app/babel.config.js(0 hunks)apps/native/app/ios/IslandApp.xcodeproj/project.pbxproj(3 hunks)apps/native/app/ios/IslandApp/Info.plist(1 hunks)apps/native/app/jest.config.js(0 hunks)apps/native/app/jest.config.ts(1 hunks)apps/native/app/metro.config.js(1 hunks)apps/native/app/package.json(3 hunks)apps/native/app/project.json(1 hunks)apps/native/app/src/components/bottom-tabs-indicator/bottom-tabs-indicator.tsx(1 hunks)apps/native/app/src/components/offline/offline-banner.tsx(1 hunks)apps/native/app/src/components/pin-keypad/pin-keypad.tsx(1 hunks)apps/native/app/src/components/visualized-pin-code/visualized-pin-code.tsx(1 hunks)apps/native/app/src/hooks/use-connectivity-indicator.ts(1 hunks)apps/native/app/src/lib/show-picker.ts(1 hunks)apps/native/app/src/screens/air-discount/air-discount.tsx(1 hunks)apps/native/app/src/screens/air-discount/airfares-usage-table.tsx(1 hunks)apps/native/app/src/screens/app-lock/app-lock.tsx(1 hunks)apps/native/app/src/screens/applications/applications.tsx(1 hunks)apps/native/app/src/screens/applications/components/applications-list.tsx(1 hunks)apps/native/app/src/screens/applications/components/applications-preview.tsx(2 hunks)apps/native/app/src/screens/assets/assets-detail.tsx(1 hunks)apps/native/app/src/screens/assets/assets-overview.tsx(1 hunks)apps/native/app/src/screens/cognito-auth/cognito-auth.tsx(1 hunks)apps/native/app/src/screens/document-detail/document-detail.tsx(1 hunks)apps/native/app/src/screens/document-detail/utils/get-buttons-for-actions.tsx(1 hunks)apps/native/app/src/screens/family/family-details.tsx(1 hunks)apps/native/app/src/screens/family/family-overview.tsx(1 hunks)apps/native/app/src/screens/finance/components/finance-status-card.tsx(1 hunks)apps/native/app/src/screens/finance/finance-status-detail.tsx(1 hunks)apps/native/app/src/screens/finance/finance.tsx(1 hunks)apps/native/app/src/screens/health/health-overview.tsx(1 hunks)apps/native/app/src/screens/home/air-discount-module.tsx(1 hunks)apps/native/app/src/screens/home/applications-module.tsx(1 hunks)apps/native/app/src/screens/home/hello-module.tsx(1 hunks)apps/native/app/src/screens/home/home-options.tsx(1 hunks)apps/native/app/src/screens/home/home.tsx(1 hunks)apps/native/app/src/screens/home/inbox-module.tsx(1 hunks)apps/native/app/src/screens/home/licenses-module.tsx(1 hunks)apps/native/app/src/screens/home/onboarding-module.tsx(1 hunks)apps/native/app/src/screens/home/vehicles-module.tsx(1 hunks)apps/native/app/src/screens/inbox/inbox-filter.tsx(1 hunks)apps/native/app/src/screens/inbox/inbox.tsx(1 hunks)apps/native/app/src/screens/license-scanner/license-scan-detail.tsx(1 hunks)apps/native/app/src/screens/license-scanner/license-scanner.tsx(1 hunks)apps/native/app/src/screens/login/login.tsx(1 hunks)apps/native/app/src/screens/login/testing-login.tsx(1 hunks)apps/native/app/src/screens/more/more.tsx(1 hunks)apps/native/app/src/screens/more/personal-info.tsx(1 hunks)apps/native/app/src/screens/notifications/notifications.tsx(1 hunks)apps/native/app/src/screens/onboarding/onboarding-biometrics.tsx(1 hunks)apps/native/app/src/screens/onboarding/onboarding-notifications.tsx(1 hunks)apps/native/app/src/screens/onboarding/onboarding-pin-code.tsx(1 hunks)apps/native/app/src/screens/passkey/passkey.tsx(1 hunks)apps/native/app/src/screens/settings/edit-bank-info.tsx(1 hunks)apps/native/app/src/screens/settings/edit-confirm.tsx(1 hunks)apps/native/app/src/screens/settings/edit-email.tsx(1 hunks)apps/native/app/src/screens/settings/edit-phone.tsx(1 hunks)apps/native/app/src/screens/settings/settings.tsx(1 hunks)apps/native/app/src/screens/update-app/update-app.tsx(1 hunks)apps/native/app/src/screens/vaccinations/components/vaccination-card.tsx(1 hunks)apps/native/app/src/screens/vaccinations/vaccinations.tsx(1 hunks)apps/native/app/src/screens/vehicles/components/mileage-cell.tsx(1 hunks)apps/native/app/src/screens/vehicles/components/vehicle-item.tsx(1 hunks)apps/native/app/src/screens/vehicles/vehicle-mileage.screen.tsx(1 hunks)apps/native/app/src/screens/vehicles/vehicles-detail.tsx(1 hunks)apps/native/app/src/screens/vehicles/vehicles.tsx(1 hunks)apps/native/app/src/screens/wallet-pass/components/field-render.tsx(1 hunks)apps/native/app/src/screens/wallet-pass/wallet-pass.tsx(1 hunks)apps/native/app/src/screens/wallet-passport/wallet-passport.tsx(1 hunks)apps/native/app/src/screens/wallet/components/wallet-item.tsx(1 hunks)apps/native/app/src/screens/wallet/wallet.tsx(1 hunks)apps/native/app/src/test-setup.ts(1 hunks)apps/native/app/src/types/react-native.d.ts(0 hunks)apps/native/app/src/types/styled-components.d.ts(1 hunks)
⛔ Files not processed due to max files limit (17)
- apps/native/app/src/ui/index.ts
- apps/native/app/src/ui/lib/card/license-card.tsx
- apps/native/app/src/ui/lib/date-picker/date-picker.tsx
- apps/native/app/src/ui/lib/detail/header.tsx
- apps/native/app/src/ui/lib/empty-state/empty-list.tsx
- apps/native/app/src/ui/lib/empty-state/empty-state.stories.tsx
- apps/native/app/src/ui/lib/input/input.tsx
- apps/native/app/src/ui/lib/label/label.tsx
- apps/native/app/src/ui/lib/link/link-text.tsx
- apps/native/app/src/ui/lib/list/list-item.tsx
- apps/native/app/src/ui/lib/problem/problem-template.tsx
- apps/native/app/src/ui/lib/search-bar/search-bar.tsx
- apps/native/app/src/utils/applications-utils.ts
- apps/native/app/src/utils/get-theme-with-preferences.ts
- apps/native/app/tsconfig.app.json
- apps/native/app/tsconfig.json
- apps/native/app/tsconfig.spec.json
💤 Files with no reviewable changes (4)
- apps/native/app/jest.config.js
- apps/native/app/.gitignore
- apps/native/app/babel.config.js
- apps/native/app/src/types/react-native.d.ts
✅ Files skipped from review due to trivial changes (2)
- apps/native/app/src/screens/finance/finance.tsx
- apps/native/app/jest.config.ts
🚧 Files skipped from review as they are similar to previous changes (73)
- apps/native/app/.bundle/config
- apps/native/app/src/test-setup.ts
- apps/native/app/src/screens/air-discount/airfares-usage-table.tsx
- apps/native/app/src/screens/health/health-overview.tsx
- apps/native/app/src/screens/vehicles/components/mileage-cell.tsx
- apps/native/app/src/screens/wallet/wallet.tsx
- apps/native/app/src/screens/family/family-details.tsx
- apps/native/app/src/screens/settings/edit-phone.tsx
- apps/native/app/src/screens/vaccinations/components/vaccination-card.tsx
- apps/native/app/src/types/styled-components.d.ts
- apps/native/app/src/screens/wallet-passport/wallet-passport.tsx
- apps/native/app/src/screens/document-detail/utils/get-buttons-for-actions.tsx
- apps/native/app/ios/IslandApp/Info.plist
- apps/native/app/src/screens/settings/settings.tsx
- apps/native/app/src/hooks/use-connectivity-indicator.ts
- apps/native/app/.babelrc.js
- apps/native/app/src/screens/inbox/inbox-filter.tsx
- apps/native/app/src/components/offline/offline-banner.tsx
- apps/native/app/src/lib/show-picker.ts
- apps/native/app/src/screens/license-scanner/license-scan-detail.tsx
- apps/native/app/src/screens/home/home-options.tsx
- apps/native/app/src/screens/settings/edit-bank-info.tsx
- apps/native/app/src/screens/settings/edit-confirm.tsx
- apps/native/app/src/screens/wallet/components/wallet-item.tsx
- apps/native/app/src/screens/air-discount/air-discount.tsx
- apps/native/app/src/screens/more/more.tsx
- apps/native/app/src/screens/applications/components/applications-list.tsx
- apps/native/app/src/screens/notifications/notifications.tsx
- apps/native/app/android/settings.gradle
- apps/native/app/src/components/visualized-pin-code/visualized-pin-code.tsx
- apps/native/app/.eslintrc.json
- apps/native/app/src/screens/home/onboarding-module.tsx
- apps/native/app/src/screens/onboarding/onboarding-notifications.tsx
- apps/native/app/src/components/bottom-tabs-indicator/bottom-tabs-indicator.tsx
- apps/native/app/src/screens/home/home.tsx
- apps/native/app/src/screens/assets/assets-detail.tsx
- apps/native/app/src/screens/home/applications-module.tsx
- apps/native/app/src/screens/wallet-pass/components/field-render.tsx
- apps/native/app/src/screens/settings/edit-email.tsx
- apps/native/app/src/screens/more/personal-info.tsx
- apps/native/app/src/screens/vehicles/vehicles-detail.tsx
- apps/native/app/src/screens/app-lock/app-lock.tsx
- apps/native/app/src/screens/finance/finance-status-detail.tsx
- apps/native/app/src/screens/cognito-auth/cognito-auth.tsx
- apps/native/app/src/screens/vehicles/vehicles.tsx
- apps/native/app/src/screens/vehicles/vehicle-mileage.screen.tsx
- apps/native/app/src/screens/finance/components/finance-status-card.tsx
- apps/native/app/src/screens/login/login.tsx
- apps/native/app/ios/IslandApp.xcodeproj/project.pbxproj
- apps/native/app/src/screens/login/testing-login.tsx
- apps/native/app/src/screens/onboarding/onboarding-pin-code.tsx
- apps/native/app/src/screens/assets/assets-overview.tsx
- apps/native/app/src/components/pin-keypad/pin-keypad.tsx
- apps/native/app/src/screens/passkey/passkey.tsx
- apps/native/app/src/screens/home/vehicles-module.tsx
- apps/native/app/src/screens/inbox/inbox.tsx
- apps/native/app/src/screens/applications/applications.tsx
- apps/native/app/src/screens/vehicles/components/vehicle-item.tsx
- apps/native/app/src/screens/family/family-overview.tsx
- apps/native/app/src/screens/wallet-pass/wallet-pass.tsx
- apps/native/app/src/screens/update-app/update-app.tsx
- apps/native/app/src/screens/home/inbox-module.tsx
- apps/native/app/src/screens/onboarding/onboarding-biometrics.tsx
- apps/native/app/src/screens/document-detail/document-detail.tsx
- apps/native/app/src/screens/home/hello-module.tsx
- apps/native/app/package.json
- apps/native/app/src/screens/license-scanner/license-scanner.tsx
- apps/native/app/src/screens/home/licenses-module.tsx
- apps/native/app/src/screens/vaccinations/vaccinations.tsx
- apps/native/app/project.json
- apps/native/app/android/app/build.gradle
- apps/native/app/src/screens/applications/components/applications-preview.tsx
- apps/native/app/src/screens/home/air-discount-module.tsx
🧰 Additional context used
📓 Path-based instructions (2)
apps/native/app/metro.config.js (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/native/app/Gemfile (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."
🪛 rubocop (1.68.0)
apps/native/app/Gemfile
[convention] 9-9: Gems should be sorted in an alphabetical order within their section of the Gemfile. Gem activesupport should appear before cocoapods.
(Bundler/OrderedGems)
🔇 Additional comments (4)
apps/native/app/metro.config.js (2)
29-30: Add workspace libraries to watchFolders
Since this PR moves the app to nx monorepo structure, the watchFolders array should include the workspace libraries to ensure proper rebuilding when library code changes.
1-31: LGTM: Proper nx integration configuration
The Metro configuration correctly integrates with nx using withNxMetro and properly sets up SVG transformation. The configuration includes:
- Correct imports from @nx/react-native
- Proper merger of default and custom configs
- Appropriate resolver extensions
.gitignore (2)
107-168: LGTM: Comprehensive React Native ignore patterns
The added patterns appropriately cover all necessary React Native build outputs and development files including:
- iOS build artifacts and certificates
- Android build outputs and credentials
- Fastlane outputs
- Metro temporary files
129-132: Additional sensitive file patterns needed
Based on the codebase scan, consider adding these security-sensitive patterns:
- Environment files (
.env*,.envrc*) - Client configuration files
- Additional certificate formats
There was a problem hiding this comment.
Actionable comments posted: 2
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
⛔ Files ignored due to path filters (1)
yarn.lockis excluded by!**/yarn.lock,!**/*.lock
📒 Files selected for processing (1)
package.json(5 hunks)
🔇 Additional comments (2)
package.json (2)
475-475: 🛠️ Refactor suggestion
Pin react-native-web version
Using caret (^) version range for react-native-web could lead to unexpected updates and compatibility issues.
- "react-native-web": "^0.19.11",
+ "react-native-web": "0.19.11",Likely invalid or redundant comment.
384-386: Verify React Native testing library compatibility
The testing libraries (jest-react-native@18.0.0, @testing-library/jest-native@5.4.3, @testing-library/react-native@12.9.0) need to be verified for compatibility with React Native 0.74.5.
Also applies to: 465-465
✅ Verification successful
Let me gather more information about the specific React Native version in the project to ensure compatibility.
Testing libraries are compatible with React Native 0.74.5
Based on the verification:
- The installed versions (@testing-library/jest-native@5.4.3 and @testing-library/react-native@12.9.0) are the latest available versions
- The related issue "RN 0.74 breaking testing library" in the react-native-testing-library repository has been resolved and closed
- These versions are actively maintained and compatible with React Native 0.74.5
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for compatibility issues between React Native and testing libraries
# Check the latest compatible versions
npm info jest-react-native@* version
npm info @testing-library/jest-native@* version
npm info @testing-library/react-native@* version
# Check for any reported issues or breaking changes
gh api graphql -f query='
{
search(query: "repo:callstack/react-native-testing-library is:issue react native 0.74", type: ISSUE, first: 5) {
nodes {
... on Issue {
title
url
state
}
}
}
}'
Length of output: 700
Script:
#!/bin/bash
# Check React Native version in package.json
rg '"react-native":\s*"[^"]*"' package.json
# Check if there are any test files using these libraries
fd -e test.js -e test.tsx -e spec.js -e spec.tsx --exec rg -l "@testing-library/(react-native|jest-native)"
Length of output: 185
* feat: init nx create app stuff * feat: copy src folder from app project * feat: add dependencies * feat: updating podFile * feat copy ios folder from older project * feat: copy android folder * feat: final fixes for ios app working locally * feat: remove old src folder * feat: add readme * feat: add storybook folder * feat: add back test stuff in * feat: add more stuff from old project * feat: add all scripts to package.json * feat: update packages that still have * to proper version * feat: final additions * feat: renaming app folder and removing old native folder * fix: remove mobile from workspaces * fix: remove extra extension * feat: add back root level read me * feat: add prettier and bundle config files * remove google-services.json file * feat: update gitignore file * fix: path for e2e project.json * chore: bump version to 1.4.8 * remove cache: true from nx.json * add tags to project.json * feat: fix yarn.lock * fix: valid json in nx.json * fix: remove app-e2e folder * fix: update package.json * feat: add license to package.json in app * remove private: true to fix license check * chore: nx format:write update dirty files * fix: remove dom from lib in tsconfig.json * update entryFilein project.json * fix: update settings.gradle after android build failing * fix: update import from build.gradle * feat: use relative import for ui * fix: remove duplicates from gitignore * fix: remove from tsconfig things that are already inherited * chore: remove babel-plugin-module-resolver * remove webpack.config.js * fix: update package.json to have same version as package.json in app * fix: update yarn.lock * fix: linting * chore: update react version to match root project * chore: update Podfile * chore: remove patch for old version of rn --------- Co-authored-by: andes-it <builders@andes.is> Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
What
Moving mobile app into nx.
Why
To be able to import libs from the monorepo.
I have tested running the app locally both on an ios simulator and on an android device and everything works as before.
Checklist:
Summary by CodeRabbit
New Features
Bug Fixes
Refactor
getThemeWithPreferencesfunction to enforce a default light theme.Chores
.gitignoreto accommodate various development environments.package.jsonfor improved functionality and performance.