feat: implement location type filtering

[prudentbird]

Description

This update introduces support for filtering locations by type on both the user and admin location pages. Corresponding API calls have been updated to accept and handle the new filter criteria, enabling a more refined and contextual data experience.

Related Issue

Fixes #63

Type of Change

• feat: New feature

How Has This Been Tested?

• Manual tests

Checklist

• My code follows the project's coding style
• My changes generate no new warnings

Additional Notes

This enhancement improves usability by allowing users and admins to quickly narrow down location results based on specific categories.

[claude]

Claude finished @prudentbird's task —— View job

---

PR Review: Location Type Filtering Implementation

Review Checklist:

• Read repository guidelines (CLAUDE.md)
• Analyze modified files and implementation
• Review code quality and best practices
• Check for potential bugs and issues
• Evaluate performance considerations
• Assess security concerns
• Review test coverage
• Provide comprehensive feedback

---

Summary

This PR successfully implements store type filtering functionality for both admin and user location pages. The implementation adds filtering capabilities to both the map data fetching and the sidebar list views.

Code Quality Assessment

✅ Strengths:

1. Consistent Implementation: Both admin and user pages implement identical filtering patterns, maintaining code consistency across user roles.

2. Proper Type Handling: The code correctly handles the storeType parameter with proper trimming and conditional inclusion in API calls.

3. UI/UX Consistency: The filter dropdown includes the same comprehensive list of store types for both admin and user interfaces.

4. Debounced Search: Good performance optimization with debounced search that triggers on both name and store type changes.

5. Cache Integration: The cache keys properly include the store type parameter for efficient caching.

⚠️ Areas for Improvement:

Performance Considerations

1. Cache Key Strategy (admin/locations/content.tsx:170, user/locations/content.tsx:170):

   • The current cache includes storeType in the key, which is good
   • However, the cache could be more efficient by normalizing the storeType value before creating the key

2. API Call Optimization (admin/actions.ts:46-47, user/actions.ts:42-43):

   if (storeType && storeType.trim().length > 0)
     queryParams.append('storeType', storeType.trim());

   • ✅ Good: Proper validation and trimming before adding to query params

Security Assessment

1. Input Sanitization: ✅ Proper trimming and validation of storeType parameter
2. SQL Injection Prevention: ✅ Using query parameters instead of string concatenation
3. XSS Prevention: ✅ No direct DOM manipulation with user input

Bug Analysis

Minor Issues Found:

1. Hardcoded Store Types (admin/locations/content.tsx:428-447, user/locations/content.tsx:427-446):

   • The store type options are hardcoded in both components
   • Consider extracting these to a shared constant to avoid drift between admin/user interfaces

2. Type Safety (admin/locations/content.tsx:204, user/locations/content.tsx:204):

   storeType: storeType === 'ALL' ? undefined : storeType,

   • This logic is duplicated across files
   • Consider creating a utility function for this transformation

Recommendations

High Priority:

1. Extract Store Type Constants: Create a shared STORE_TYPES constant to maintain consistency
2. Create Utility Function: Extract the storeType === 'ALL' ? undefined : storeType logic into a reusable utility

Medium Priority:

1. Add PropTypes/Interface: Consider adding a StoreType union type for better type safety
2. Error Handling: Add specific error handling for invalid store type values

Low Priority:

1. Performance: Consider memoizing the store type options list

Test Coverage

⚠️ Missing Tests: No test files were included in this PR. Consider adding:

• Unit tests for the filtering logic
• Integration tests for the API parameter handling
• UI tests for the filter dropdown functionality

Example Implementation Suggestions:

// shared/constants/store-types.ts
export const STORE_TYPES = [
  { value: 'ALL', label: 'All Types' },
  { value: 'SHOP', label: 'Shop' },
  // ... rest of the types
] as const;

export type StoreType = typeof STORE_TYPES[number]['value'];

// shared/utils/store-filters.ts
export const normalizeStoreType = (storeType: string): string | undefined => {
  return storeType === 'ALL' ? undefined : storeType;
};

Final Assessment

Overall Rating: ✅ Approve with Suggestions

The implementation is solid and functional, with consistent patterns across both admin and user interfaces. The core functionality works correctly, and the code follows good practices for React and TypeScript. The suggestions above would enhance maintainability and reduce code duplication, but the current implementation is production-ready.

The filtering feature successfully addresses issue #63 and maintains good performance characteristics with proper debouncing and caching strategies.

---