The expanded search bar has no actual search functionality

[shreyashchandratre]

Closes #125

Replaced the static, decorative layout in expanded-search-bar.tsx with a functional, native

.

Converted the static sections into actual input fields that automatically sync with the URL parameters:
Where: Added a text input named city.
When: Divided into two date inputs named checkIn and checkOut (matching the parameters consumed in app/page.tsx).
Who: Added a number input named guests.

Upgraded the submit icon into a functional , allowing it to instantly update the URL search parameters upon clicking.

[vercel]

@shreyashchandratre is attempting to deploy a commit to the Akshay Kumar's projects Team on Vercel.

A member of the Team first needs to authorize it.

[akshay0611]

Review: The expanded search bar has no actual search functionality

This is a substantial PR that does a lot of good work — the ExpandedSearchBar gets real form inputs, filters are synced to the URL via a clean useFilterParams hook, favorites are extracted into a reusable useFavorite hook, and the BookingSidebar gains a confirmation dialog. The scope is ambitious and the overall direction is solid.

What looks great ✨

• The useFilterParams hook (hooks/use-filter-params.ts) is well-designed — clean FilterParams interface, safe parsing with parseNum/parseStr, and thoughtful handling of default values (keys removed from URL when they match defaults). The clearFilters preserving non-filter params is a smart touch.
• Extracting favorites into hooks/useFavorite.ts is the right call — it eliminates duplication between PropertyCard and BookingSidebar and keeps the localStorage logic in one place.
• The ExpandedSearchBar conversion from static divs to a <form method="GET" action="/"> with real <input> fields is exactly what the issue asked for. Using name attributes that match the URL params consumed by the home page is clean.
• The FilterSidebar refactor to accept filters/onFiltersChange props instead of internal useState is a good architectural move toward controlled components.
• The Suspense boundary in PropertiesPage correctly handles the Next.js requirement for useSearchParams.
• You added thorough unit tests for both useFilterParams and the refactored FilterSidebar — that's great discipline.

Blockers

• components/BookingSidebar.tsx — Multiple missing imports that will cause build errors:

  1. Removed useLocale from @/lib/use-locale and convertPrice/formatCurrency/getLocaleForLanguage from @/lib/locale-currency, but the component still uses them for price display (settings.currency, convertPrice(), formatCurrency()).
  2. Uses useRouter() without importing it from next/navigation.
  3. Uses useFavorite(property.id) without importing it from @/hooks/useFavorite.
  4. Uses <AlertDialog>, <AlertDialogContent>, etc. without importing them from @/components/ui/alert-dialog.

  These need to be added back — adding the missing imports at the top of the file should fix it.

Optional suggestions (feel free to ignore)

• The FiltersSidebar component now has filters: FilterParams as a required prop. If this component is ever used elsewhere, that's good to keep in mind, though currently only PropertiesPage uses it.
• You might consider splitting the BookingSidebar changes into a separate PR since they're unrelated to the search bar / filter sync — but it's fine to keep them together too.

Verdict

REQUEST_CHANGES

You're close — the issues in BookingSidebar.tsx are just missing imports that need to be added back. The overall architecture of the PR (the hook extraction, the URL sync, the search form) is all well done and on the right track.