[wallytax]

You are right about the 2 b/c point. Reading it a day later makes me realise that is not desired behavior. But I don't think I want the sorting settings to be cleared. That part is not clear to me. Can't everything just stay in place? So that - if I manually refresh the grid - it still uses the same sort as was already selected?

I'm trying to prevent the unsort() call now, but simply overriding it doesn't help I guess, because it should unsort() in case the user clicks the header context menu and selects "Clear sort".

So basically I want nothing to happen if a record is created or updated on the field that is also selected as (one of the) sorting column(s). No calls to unsort().

[wallytax]

BTW, maybe I'm lost in the whole discussion but for me it's unclear if this behavior has changed since around April 1st, 2020. If this is the case, then I understand that my customer now complains that his records are sorted differently after certain updates.

[Blama]

Hi wallytax

this is my problem here as well. There does not seem to be a solution to this other than saving the sort settings yourself, if I get the old post right.
Perhaps (if you do not care for the changes from the add/update in the Form in you ListGrid, you could also make the ListGrid using a separate ResultSet by using a different operationId.
See the ResultSet docs.

Regarding operationIds and how they affect caching, take into account that cache sync is based on the fetch used - any add or update operation uses a fetch to retrieve updated data, and the operationId of that fetch can be set via cacheSyncOperation. If the operationId of the cache is different from the operationId of the cache update data, it won't be used to update the cache, since the fields included and other aspects of the data are allowed to be different across different operationIds. This allows to maintain distinct caches on a per component basis, so when two components are using separate operationIds they are assumed to have distinct caches, because updates performed with one operationId will not affect the cache obtained via another operationId. Also, take into account that operationId must be unique per DataSource, across all operationTypes for that DataSource.

Best regards
Blama

[wallytax]

I think (and hope) that I have a working solution for my project. I discussed this with a fellow programmer and we think that it is consistent to clear the sorting flag because the inserted/updated record (most likely) is not in sync with the sorting order. However, from an user's perspective, we believe that it is more beneficial to show the inserted/updated record and keep the sorting specifier. Call me stubborn if you like...

Looking into the code, I found out that after a save unsort() is called which in turn calls setSort(null). I therefore overwrite the setSort() method and call the super method only if the argument is not null. This handles the situation where the user selects "Clear sort" from the context menu, because then an (empty) array is passed as argument to setSort().

setSort: function(sortSpecifiers) {
  if (sortSpecifiers !== null) {
    this.Super('setSort', arguments);
  }
}

This way I don't need to "remember" the sort before the actual submit is done and restore that sort afterwards. This seems to be a concise solution. Hopefully it works as intended (by us).

Because I want to refresh the data after the user selects "Clear sort" in the context menu, I restored my invalidateCacheOnSort setting to true. Maybe also stubborn. I believe we have the behavior back as it was like a year ago.

Please, let me know if this would help you as well Blama . And of course, if my approach is very bad, let me know as wel..

[Isomorphic]

Since the data is not sorted, it must not be represented to the user as sorted, because that's incorrect.

We don't really see room for argument here ...?

Also, just FYI, many years ago (~14) we had the behavior where the sort indicator was left in place, and that was cited as a bug in an accessibility review, because it is that much more important for a non-sighted user to have correct information.

This also answers your question with regards to recent changes - this behavior is about 14 years old.

We really don't understand the desire to drop cache and go to the server in this case. We regard the framework's existing behavior as ideal: the sort change is correctly represented to the user, the cache is preserved (which is a benefit for performance and for the user's productivity - doesn't have to wait for new server data), and the user has the ability to re-sort if they want.

So we would strongly recommend leaving this alone unless you have a very unusual use case, such as inserting new records into a continuously updated stream of existing records.

As far as your implementation, you are relying on undocumented behavior (setSort() does not have docs that would allow you to assume this is a correct way to prevent unsort), breaking the ability to clear the sort for all cases, not just this case, and also, your application is broken, because the indicator is simply wrong - if your application enjoys widespread use, someone will eventually report this as a bug, because it is a bug.

So again our recommendation is do nothing - leave the already correct and optimal behavior in place. But if you wanted to do something that's correct, you should detect this specific case via sortChanged() and dataChanged(), and force retrieval of data via calling setSort() to restore the prior sort.

[wallytax]

I've read your answer and I've decided to drop my functionality. So when a record is created or updated (and I believe then it only happens if the sorting columns are changed), the sort indicator disappears.

But what if the user uses the "Clear sort" option in the header's context menu? Is it not valid to refetch the data then?

[Isomorphic]

If "Clear Sort" dropped data and refetched, then what you would get is the "natural order" of whatever the underlying data store is, that is, what it returns if you don't ask for a sort.

With most kinds of data stores, this is intentionally left undefined; it's basically whatever is most efficient to implement. Sometimes it's roughly the most recent updates first; other times it's a pseudo-random order that is an artifact of the indexing strategy or disk block storage approach.

So the question is really: is there some reason that the "natural order" is useful to end users, so that an option to drop cache and pull data in the "natural order" would be useful to them?

Well, in real world deployments, we have seen:

1) end users getting rid of sort because the "unsorted" order happened to be something useful, like most recently updated, which the application didn't offer any other way

2) end users getting rid of sort because for whatever reason asking for unsorted data is far, far faster (could be bad DB, or bad application code)

We include "Clear Sort" principally for completeness, and also so that, if an interface is provided for saving a "view" (that is, a combination of criteria, visible columns, sort, etc) the user has a way to specify a "saved view" that doesn't include sort.

If, in your application, the "natural order" is a particularly useful order, or is far faster to retrieve, you might want Clear Sort to immediately refetch data, which you can implement via the strategies explained above.

However if the "natural order" is a useful order like "most recently updated", it might be best to give the user a way to request this explicitly, so that it's more discoverable.

[wallytax]

Suppose the screen has no initial sorting, the user adds a sorting column and later decides that sort order has to made undone. In this case, I would think that clear sort makes sense. If so, how can I trigger a refetch of the data or will it happen automatically (I don't think so)? I'm still in doubt of how to do this. fetchData(), refreshData(), resort(), invalidateCache()? Is there one you would advice?

[Isomorphic]

We would recommend that you closely re-read our reply above, and think about why the end user would want an unsort - because again, in order to care about clearing the sort, the unsorted order must be useful in some way. So please re-read closely and think about it.

As far as implementing a Clear Sort command that removes the cache, we have answered this thrice. Here it is again:

If there is some reason you want Clear Sort to also drop cache, then we would recommend customizing that menu item to perhaps call refreshData(), rather than attempting to use an undocumented API.

We don't know why you keep asking, but the API to override is getHeaderContextMenuItems(), if that helps.

[wallytax]

I come to a point that I hardly dare to ask anything, without feeling stupid... It's not feeling very comfortable.

Let's say that having no sort column specified leaves the sorting to the database (basically the query becomes "SELECT * FROM <table>"). It's up to the database how that is sorted. The table might in theory be a database view that has internal ordering. It might also show records in the order they are created. For simplicity's sake, let's say it sorts by the "id" column. If I have a grid that doesn't show the "id" column, a way to get ordering on "id", is by clearing the sort. I believe you wrote this in the earlier reply, or not?

So if an user sorts the data by a specific column and wants to return to the unspecified sort, this is not really unrealistic or is it? So in this case, I think a drop of cache makes sense. But if that's not the case, I will drop the discussion and try to forget this about this behavior.

[Blama]

Hi wallytax,

I agree with Isomorphic. If your users want/expect/assume a sort every time, start the grid sorted and perhaps override the menu entry to apply this sort again. If the column is an ID column that should not be visible to the user, make it hidden:true, canHide:false.

I would not rely on DB sort without an explicit ORDER BY for many reasons: statistics and plan changes, indexes and plan changes, partitions and plan changes, new join because of includeFrom and plan changes. The SELECT * FROM ViewWithOrderBy is a bad practice, see here.
I had a problem with this recently, where a user relied on the order of the data because it *seemed* to be ordered. "But it started with 1, 2, 3, 4, so I assumed...".

Best regards
Blama

[wallytax]

I should not have mentioned the SQL example where no ORDER BY was specified. I would indeed not leave the sorting to the database: in case no sorting was selected in the front-end, I still would have the back-end sort by the most logical column for that entity.

My question is not answered, but I will I rest my case: I can't get it explained without creating extensive stand-alone examples. I show the desired behavior to my colleagues and they seem to understand my point.

Okay, maybe one final attempt.

I show orders, but without their ID or creation date in the table. I sort them in the back-end on ID DESC. If the user clicks on the "customer name" column, then I sort the orders by customer name. I can also click that column again to change the direction. So far, so good... but then the user wants to return to the sorting on ID DESC. How to do that? My idea was that the user clicks the "Clear sort" button which is default functionality. But after doing that, no data refresh occurs.

[Blama]

Hi wallytax,

my assumption is that the frontend does not know about any implicit sorting in this case and is not built for this case.
I'd go with this then:

• Have the ID in your .ds.xml / DataSource
• Return ID column with the request
• Start the grid sorted by that ID
• Make the ID column not be visible to the user -> hidden:true, canHide:false
• Override the "Clear sort" menu entry to apply sort by ID again

This would solve your use case without any hacks, even though you need some code for it.

Best regards
Blama

[wallytax]

Hi Blama,

Thanks for your reply. My comments per bullet:

• Check
• Check
• Either via initialSort: [{ property: 'id', direction: 'descending' }] or sortField: 'id' / sortDirection: 'descending'?
• Check
• Can you give me an example of how to do this?

[Blama]

Hi wallytax,

I think initialSort/sortField will result in the same.
W.r.t. the menu click handler unfortunately I can't, but according to #6 this is possible. Perhaps these two posts help: 1, 2

Best regards
Blama