The problem is that there are SOO many ways an API provider could configure SORT. We have not tried to support them all. Generally there is an “OrderBy” parameter in the API URL - and you can set up dynamic parameters that get replaced using action fwk sequences. But of course - this does not work with the Sort Builder. Bah.

We are looking at increased support of the OpenApiSpec (Previously known as SWAGGR). As part of that work we will make it easier to set up the data source, and will also work on increased support of things like server side sort. Stay tuned.

Thank you for the reply, and it’s awesome to hear that more support is being considered/added.

I’ve been looking into client-side table filters and sort builder. When it’s client-side it allows me to do what I want to do. Though, this causes to re-query the model when sorting/table-filter is applied.

selecting an option from the table filter or selecting ‘save’ on sort builder applies sorting/condition, but it also re-queries the model.

Rest Model - re-queries the model only for table filter conditions and not for sort builder.

SF Model - re-queries for table filter conditions and sort builder.

What should be happening? Given there is inconsistency regarding sort builder, as well as the sorting/filtering is meant to happen on the client-side but there is a call to the server.

My opinion: I like that it re-queries the model. Otherwise, there is no way to listen for an event to know if a condition/sorting has been applied.

Thank you,

Lukas

Yea, these are good questions. I’ll stew on them for a while. I don’t think there is a clear winner - but I do think we should be consistent between Rest and SF data source processing