Dynamic Sortable Table

Introduction

This tour opens a concrete list page so you can inspect a sortable table in the real Wappler workflow: visible sort controls, a Data View that owns the ordering, and a table that makes the active field and direction obvious instead of changing rows silently.

The sort controls belong beside the table they reorder

This page keeps the sort buttons next to the table instead of hiding them in a detached control panel. That matters because users should be able to change the order and immediately understand which list the action affects.

The table should show the active sort state, not just react to it

The header labels and summary line keep the current order explainable. A sortable table feels trustworthy when people can tell which field is active and whether the result is ascending or descending without having to guess from the row order.

The Data View properties show where the sort logic lives

With the Data View selected, the Properties panel reveals the concrete sort configuration behind the sample: sortOn decides which field drives the ordering, and sortDir carries the direction. The sort buttons simply feed those named values instead of mutating the dataset manually.

Working in Wappler

Once the Data View owns the order, the rest of the page can explain and reuse the same state instead of duplicating table logic.

Named sort values keep the table wiring readable

This sample uses list_sort_field and list_sort_direction as named App Connect values. That keeps the workflow easy to follow in Structure and Properties: buttons update the state, and the Data View consumes the same state declaratively through its sorting properties.

Visible feedback keeps the current order understandable after every change

The sort summary explains the current field and direction in plain language. That small feedback surface is what stops a dynamic table from feeling like it shuffled itself for no reason.

Sorting should cooperate with filtering and counts on the same page

This sample keeps the sort controls beside the search input, checkbox filters, and visible record counts because that is how users actually experience list state. In practice, the table, badges, and filter surfaces should all tell the same story about what is currently being shown.

Conclusion

You now have the practical Wappler pattern for a sortable table: the Data View owns sortOn and sortDir, named App Connect values make the state readable, and the page itself explains the active ordering next to the results.

Continue into adjacent list-state patterns

Continue into multiple-checkbox filtering when users need to combine several conditions, or into total counts when you want the list to explain how large the current result set really is.