Add feature : Added auto fill country and search country featueres #148
Conversation
📝 WalkthroughWalkthroughThe changes implement automatic location detection to auto-fill the country field during user registration. Location permissions are added for both iOS and Android platforms, the geolocation service dependency is introduced, location detection logic with error handling is implemented in the registration screen, and a country search feature enables manual selection if location access is denied. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
Frontend/src/Screens/BasicDetailsScreen.jsx (1)
170-174: ResetsearchQuerywhen country is selected or modal is closed.The
searchQuerystate persists after selection or cancellation, so reopening the modal shows filtered results from the previous search instead of the full list.🔎 Proposed fix
const handleSelectCountry = selectedCountry => { setCountry(selectedCountry); setShowCountryModal(false); + setSearchQuery(''); setErrors(prev => ({...prev, country: ''})); };Also update the cancel button handler:
onPress={() => { setShowCountryModal(false); setSearchQuery(''); }}
🧹 Nitpick comments (2)
Frontend/android/app/src/main/AndroidManifest.xml (1)
4-5: Consider whetherACCESS_FINE_LOCATIONis necessary.For country detection,
ACCESS_COARSE_LOCATIONalone would typically suffice and is more privacy-friendly. The code currently usesenableHighAccuracy: true, which requires fine location. If precise GPS coordinates aren't needed for reverse geocoding to country level, consider removingACCESS_FINE_LOCATIONand settingenableHighAccuracy: falseto request only approximate location.Frontend/src/Screens/BasicDetailsScreen.jsx (1)
102-106: Minor: Useconsole.errorfor error logging consistency.Line 103 uses
console.logwhile line 96 usesconsole.error. For consistency and proper error severity in logs, consider usingconsole.errorhere as well.🔎 Proposed fix
error => { - console.log(error.code, error.message); + console.error('Geolocation error:', error.code, error.message); setErrors(prev => ({...prev, country: 'Error getting location'})); setLoadingLocation(false); },
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (3)
Frontend/ios/Podfile.lockis excluded by!**/*.lockFrontend/package-lock.jsonis excluded by!**/package-lock.jsonpackage-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (6)
Backend/cache/context_default.jsonFrontend/android/app/src/main/AndroidManifest.xmlFrontend/ios/BabyNest/Info.plistFrontend/package.jsonFrontend/src/Screens/BasicDetailsScreen.jsxpackage.json
🧰 Additional context used
🧬 Code graph analysis (1)
Frontend/src/Screens/BasicDetailsScreen.jsx (1)
Frontend/src/data/countries.js (2)
countries(1-23)countries(1-23)
🔇 Additional comments (8)
Backend/cache/context_default.json (1)
2-7: Verify if these are intended default values or leftover test data.The updated values (location: "Australia", age: 30, weight: 65, due_date: "2026-09-17", lmp: "2025-12-11") appear to be from a testing session rather than meaningful defaults. Consider resetting to neutral placeholder values or documenting why these specific values are the intended defaults.
Frontend/ios/BabyNest/Info.plist (1)
34-35: LGTM!The location usage description is clear and appropriately scoped. Using
NSLocationWhenInUseUsageDescription(foreground-only) is the correct choice since the app only needs location during registration for country detection.Frontend/src/Screens/BasicDetailsScreen.jsx (5)
1-1: LGTM on imports.The necessary imports for location functionality are correctly added.
40-42: LGTM on mount effect.The
useEffectcorrectly triggers location detection once on component mount. The empty dependency array is appropriate here.
193-197: LGTM on loading indicator.The conditional rendering logic correctly shows the spinner during location detection and the dropdown arrow otherwise.
396-403: LGTM on search input styling.The styling is consistent with the existing input styles in the component.
44-49: No action required. TheGeolocation.requestAuthorization('whenInUse')call on iOS correctly returns'granted'when the user permits location access, so the permission check is properly implemented.Likely an incorrect or invalid review comment.
Frontend/package.json (1)
33-33: Use the latest stable version of the geolocation service.The
react-native-geolocation-serviceversion 5.3.1 is the latest stable release and has no known security vulnerabilities. Ensurepod installis run for iOS and that native linking is properly configured.
| if (data && data.address && data.address.country) { | ||
| setCountry(data.address.country); | ||
| setErrors(prev => ({...prev, country: ''})); | ||
| } else { | ||
| setErrors(prev => ({...prev, country: 'Could not detect country'})); | ||
| } |
There was a problem hiding this comment.
Country name mismatch risk with local countries list.
Nominatim may return country names that don't exactly match the entries in your countries array (e.g., "United States of America" vs "United States", "United Kingdom of Great Britain and Northern Ireland" vs "United Kingdom"). This could cause form validation issues since handleContinue checks country.trim() but doesn't validate against the allowed list.
Consider normalizing the returned country name or finding the closest match in the countries array:
🔎 Proposed fix to match against countries list
if (data && data.address && data.address.country) {
- setCountry(data.address.country);
- setErrors(prev => ({...prev, country: ''}));
+ const detectedCountry = data.address.country;
+ // Find exact or partial match in countries list
+ const matchedCountry = countries.find(
+ c => c.toLowerCase() === detectedCountry.toLowerCase()
+ ) || countries.find(
+ c => detectedCountry.toLowerCase().includes(c.toLowerCase()) ||
+ c.toLowerCase().includes(detectedCountry.toLowerCase())
+ );
+ if (matchedCountry) {
+ setCountry(matchedCountry);
+ setErrors(prev => ({...prev, country: ''}));
+ } else {
+ setErrors(prev => ({...prev, country: 'Please select your country manually'}));
+ }
} else {🤖 Prompt for AI Agents
In Frontend/src/Screens/BasicDetailsScreen.jsx around lines 89-94, the country
returned by Nominatim may not exactly match entries in your local countries
array which can break validation; instead of setting the raw returned country
string, normalize and resolve it to an allowed country before calling setCountry
— e.g., trim and compare case-insensitively, try exact match first, then try
startsWith/contains matches or a small normalization map (handle common variants
like "United States of America" -> "United States", "United Kingdom of Great
Britain and Northern Ireland" -> "United Kingdom"), and as a fallback run a
fuzzy/Levenshtein or report “Could not detect country” via setErrors if no
confident match is found.
1 participant
Closes #138
📝 Description
🔧 Changes Made
📷 Screenshots or Visual Changes (if applicable)
🤝 Collaboration
Collaborated with:
@username(optional)✅ Checklist
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.