The histogram bars — should they be real data (from your backend) or a realistic static mock distribution for now? Static mock (Recommended)
Where should the Cena / Powierzchnia fields live after this redesign? They currently sit as compact od/do inputs in the bottom row. Stay in bottom row, open popover on click (Recommended)
For the Powierzchnia quick chips — use the room-based labels from the screenshot (Kawalerka, 2 pokoje etc.) or plain m² ranges? Room-based labels (Kawalerka, 2 pokoje…) (Recommended)
Good, I have the full component. Now I'll replace the RangeInput for Cena and Powierzchnia with popover-based histogram range sliders. I'll add: mock histogram data, a dual-handle range slider via pointer events, Min/Max text inputs, and quick-select chips — all opening as a popover anchored to the field in the bottom row.
The Cena and Powierzchnia fields are now rich popover pickers. Each opens a 320px panel with a histogram (bar chart showing listing distribution, active bars rendered dark within the selected range), a dual-handle range slider built with pointer capture events, Min/Max text inputs with a dash between, and quick-select chips (price: "Do 300k", "300k–500k" etc.; area: room-based labels like "Kawalerka (do 30m²)", "2 pokoje (30–50m²)"). The trigger button itself shows the selected range value and turns dark when active, with an × to clear.
Let's chagne container 3 and make add to the top of it:
a) Enter all active filters - what's the best way to do this?
b) Smart Search for filters - for example, you enter ‘balcony’ and you get the balcony filter.
I'm also thinking taht I like this container 3 design because you can see all the filters, BUT I don't think it shows all the available filters.
Let me read the current component first to understand the full filter state before answering.
Good, I have a clear picture of the full component. Here's my honest answer before touching anything:
a) Showing all active filters at the top of Container 3
The cleanest approach is a horizontal chip strip at the top of the modal, inside the header area, that renders one dismissible chip per active filter — e.g. Balkon ×, Cena za m²: 8k–12k ×, Pierwotny ×. This keeps the full filter grid visible below without hiding anything. It also doubles as a summary: the user opens the modal, sees exactly what's on, and can kill individual filters without scrolling down to find them.
b) Smart filter search
A single search input at the top (below the active chips row) that fuzzy-matches against all filter labels. Typing "balkon" scrolls+highlights the Balkon toggle. Typing "metro" highlights Odległość od metra. Typing "pietro" finds Piętro. The rest of the filter grid stays visible — the search just visually surfaces the match (e.g. a subtle yellow ring or "jump to" behavior), rather than collapsing the layout. This preserves the "you can see all filters" quality you like.
On your third point — not all filters are visible:
You're right. The current 3-column layout is missing: heating, heated_water, cable_internet, cable_television, is_unique, windows_material, has_garage, price_changes_count, total_price_change_percentage. These could be added as a 4th group "Media i inne" in the grid. I'd suggest adding a 4th column (or stacking it under the 3rd column as a second sub-section) to house them cleanly.
Want me to implement all three of these now — the active chips strip at the top, the filter search, and the missing filters — or tackle them one at a time?
You can send messages while the preview loads