Add search, filters and maps to your App

What search and filters add to your App

If your App stores data, you can let your visitors search and filter it. That means a search box that matches text across your records, plus filter facets that let visitors narrow results by a value like a category.

A facet is more than a filter: it also tells the visitor how many records fall under each value, so you can show filter chips like "Shoes (12)" and "Shirts (8)". Visitors pick a value to narrow the list, and the counts update as they refine.

Search and filters only work once your App saves data, because there has to be saved data to search. If your App doesn't store anything yet, open Develop › Data, press Settings on Storage, and turn Saving on — then come back and add search.

This searches your App's own data — the records your App saves. It is not web search, and it never reaches outside your App.

The drop-in search starter recipe

The fastest way to add search is the ready-made search starter recipe — a drop-in search box with filter chips and paginated results, already wired to your App's data. Instead of writing the query, the wiring and the pagination yourself, the starter gives you all three at once.

You don't write it by hand. Install Search and filters from Our features in Develop › About, or ask the building assistant for it — either way the assistant composes it against your data: it drops in the search box, the filter chips backed by facet counts, and the paged result list, all reading from the fields your App already stores.

Because it's built on the same window.mfData.query(...) helper your own code would use, you can start from the starter and then ask the assistant to adjust it — change which fields it filters on, how many results per page, or how the chips are laid out.

Query your App's data in code

Your App's code reads its data through the built-in window.mfData.query(...) helper. It runs against your App's own saved records, and it powers both the search box and the filter chips.

window.mfData.query(...) supports two things that matter for search:

• A text search — you pass the words the visitor typed, and it matches them across your records and returns the matching ones.
• Facet counts — you name the fields you want counted (like a category field), and it returns each distinct value together with how many records have it. Those counts are exactly what fills in filter chips.

You can combine the two: search for a term and ask for facet counts at the same time, so the visitor sees matching results and a live breakdown of how those matches split across each category.

A page searches only your App's own lists. An action — your App's server code — can query with ctx.data.query(...) too, text search included, and an action that acts as your App can also name a data link there: a list another of your Apps shares with this one, read in place under that list's own rules.

Build a query without writing it

To see the exact call for a query before you use it, open Develop › Data and press the code icon on a list's card under Lists. The Build a query window lets you pick:

• Filters — press Add a filter and choose a field, a comparison and a value.
• Sort and limit — Sort by a field (or when a record was Added or Changed), in Ascending or Descending Order; a full-text Search; and a Limit on how many records come back — at most 200 in one query (50 when you set none), so a longer list is read a page at a time with an offset.

Code shows the window.mfData.query(...) call that asks for exactly that — with a join for each linked field — ready to copy into your App.

Which fields can be searched and faceted

A text search can match across whole records with no setup. To search inside one particular field, turn that field's Search switch on in the list's Fields table (Develop › Data → Lists → the list's settings icon).

Faceting — counting records per value — works only on fields declared as indexed, and the editor has no switch for that. The building assistant declares it when it builds a filter against the field, and you can ask it to ("index the category field so visitors can filter by it"). Ordinary filtering needs neither: your App can filter on any field it stores.

If you try to facet on a field that isn't indexed, it won't be available for counts or filters. So before you build a category filter, make sure the category field is indexed.

A facet counts short values — a category, a size, a tag. A value longer than 512 characters, such as a whole description, is left out of its counts; nobody picks a filter chip that long.

Ask the building assistant to add search

You don't have to write any of this yourself. Just ask the App's building assistant in plain language, and it builds search against your data for you.

Describe what you want the way you'd say it out loud — for example, "add a search box with category filters to my product list." The assistant reads your App's data, picks the right fields, composes the search helper and the facet counts, and drops the working search box, filter chips and paginated results into your App.

From there you can keep refining in the same plain-language way: ask it to add another filter, change the wording on the chips, or show more results per page.

Show a map with your records as markers

Your App can show an interactive map — one your visitors can pan and zoom — and drop a marker on it for each of your records. That's what powers a store locator, an events map, or a directory of places: every place you've saved shows up as a pin, and a visitor can tap a pin to see the record behind it.

The markers come from your App's own saved data. Each record that has a location becomes a pin, so as you add, edit or remove records, the map stays in step with what your App stores. You decide what the map covers — all your records at once, or just the ones that match the current search or filter — and the map draws a marker for each.

To show a map you need records with a location to place. A record's location is stored as two number fields on it: a latitude and a longitude. Records that have those two fields get a marker; records without them simply don't appear on the map.

Offer a "near me" view

"Near me" lets a visitor see the records closest to where they are, nearest first — the café down the street before the one across town. It's the natural companion to a map: the map shows everything, and near me re-centers the whole experience on the person using your App.

When a visitor chooses near me, your App asks their browser for permission to use their location. If they allow it, your App finds the records in your data that are closest to them and lists them in order of distance — closest at the top. You can show that list on its own or alongside the map, with the nearest pins highlighted.

Near me is optional for the visitor every time. If they decline the location prompt, the map and your records still work exactly as before — they just see everything rather than a distance-sorted list. Build near me as an enhancement on top of a map that stands on its own.

How near-me finds the closest records

Near me works on any record that has a latitude and a longitude stored on it — two number fields holding the record's coordinates. Those two fields are all it needs; there's no special map database to set up. If a record has both, it can be ranked by distance; if it's missing either, it's skipped for near me.

Behind the scenes, MotherFluxer does this in two steps so it stays fast even with a lot of records. First it narrows to records in a nearby area around the visitor — a quick box around their position — so it isn't measuring every record you have. Then it sorts that shortlist by true distance from the visitor, so the order you get back is genuinely closest-first, not just "roughly nearby."

The practical takeaway: make sure the records you want to appear in near me have their latitude and longitude filled in. A place with no coordinates can still live in your data and show elsewhere in your App — it just won't rank in a near-me list until it has both numbers.

The drop-in maps starter recipe

The fastest way to add a map is the ready-made maps starter recipe — a map with your records shown as markers, plus a near-me button already wired to your data. Instead of assembling the map, the markers and the distance sorting yourself, the starter gives you all three at once.

You don't write it by hand. Install Map and near me from Our features in Develop › About, or ask the building assistant for it, and the assistant composes it against your data. Describe what you want the way you'd say it out loud — for example, "show my cafés on a map with a near-me button" — and it reads your App's records, uses your latitude and longitude fields, and drops in the working map, the markers and the near-me list.

From there you can keep refining in the same plain-language way: ask it to change which records show as pins, restyle the markers, or show the near-me results as a list beside the map instead of on it.

The starter's map tiles — the pictures of streets and places the map is drawn from — are free and need no key, and the map shows a small credit line for them in its corner. Their licence requires that credit, so it always stays visible. The free tiles are meant for light use: before an App that will see real traffic launches, ask the assistant to switch the map to a commercial tile service or to tiles you host yourself, keeping a credit line on the map.

Connect a maps service for richer location features

The built-in map, markers and near me work on your own data with nothing to set up. If you want richer location features — letting visitors search for a place by name, or getting directions to one of your records — your App can connect a maps service using your own account key.

You do this once, as the App's owner: get a key from a maps service you have an account with, then open Equip › Connect, press the settings icon on Maps, paste the key into Key, and press Connect. MotherFluxer stores your key securely, in your account's Settings › Account › Connections & Keys, and uses it on the server to call the service for your App — you never handle the raw key in your App's code, and it's never shown to your visitors. To replace the key later, paste a new one and press Update; Remove takes it off this App, and the key stays in your vault, where only removing it deletes it. Connections belong to your published App, so until you publish once, the Maps settings open Publish first instead.

Connecting the key gives your App three things on top of the built-in map: searching for places by name, turning an address into coordinates and back again, and getting a route between two points with its distance and travel time. Each is a ready-made action no page can run by itself, because it spends your account: a visitor reaches one through your own action, which you open under Who can run it.

Choose this only when you need the extra features. A map with your records and a near-me button doesn't require any connected service — the key is what unlocks searching for places and directions on top of what your own data already gives you.

Ask before using a visitor's location

A visitor's location is only ever used with their permission. The moment your App needs it — when someone chooses near me — their browser shows its own location prompt, and nothing happens until they allow it. Your App can't read a visitor's position silently, and MotherFluxer never assumes consent on their behalf.

If a visitor allows it, your App gets their approximate position for that visit and uses it to rank your records by distance. If they decline, or their browser blocks location, your App carries on without near me: the map still shows every record and the rest of your App is unaffected. Treat near me as a bonus that some visitors opt into, and make sure the map is useful even for the ones who don't.