Filter Query with a URL Parameter

Introduction

URL-driven filtering is the right pattern when the current list state should survive refreshes, bookmarks, back-button navigation, or shared links. In Wappler, this usually means the filter is no longer just a local control. It becomes part of the page contract, which is why the address bar, Query Manager, and the displayed list need to stay in sync.

Bookmarkable state

The filter belongs in the URL when users may want to return to the same view later.

Shared context

Links become more useful when the recipient opens the same filtered result the sender intended.

Put long-lived list state in the URL.

Treat the address bar as part of the page state model.

Keep links, refreshes, and navigation consistent with the current filter.

Use URL filtering when the view should be reproducible by link.

Design URL filtering deliberately

The URL should clarify state, not expose chaos.

Choose which state belongs in the URL

Search terms, category filters, paging, and selected records often belong in query parameters. Temporary micro-interactions usually do not. Make that distinction on purpose.

Good rule

If the state should survive a reload or be shareable, it is a strong URL candidate.

Keep parameter meaning stable

A parameter should represent the same kind of filter every time. Reusing one key for unrelated meanings makes linked views harder to trust and debug.

Readable links

Stable parameter meaning keeps the URL understandable to both users and developers.

Connect URL state to the displayed view cleanly

Users should never have to guess whether the URL still matches the visible filter. The page should read from and write to the same state model consistently.

Single source of truth

The page view and the address bar should tell the same story.

Next steps

URL filters combine especially well with sortable tables, totals, and detail views that should survive a reload.