Hi Harshad,

The flickering is most likely caused by saving the grid configuration on every filter change. When the user types quickly, multiple changes can be triggered before the previous save has completed, so the requests can finish in a different order and overwrite each other.

I wouldn't switch to OnEnter / OnLeave for this. Those events are not really intended to control the Data Grid 2 filter lifecycle. The filter widgets expose an On Change event, which is triggered when the filter value changes.

If you're using the standard DG2 filter widgets, I would first check the On Change Behavior → Apply after (ms) setting. For Text Filter and Number Filter, Mendix provides this specifically to delay applying the filter while the user is typing. The default is 500 ms.

Also, if the JSON is only being stored to persist the user's filter configuration, I would avoid maintaining a separate persistence flow if possible. Data Grid 2 already has Store Filters in Personalization, which is intended to persist filter states. Mendix supports storing the filter state as part of the user's personalization settings.

If you do need the custom persistence entity because you have additional requirements, I would decouple the filter interaction from the persistence save. In other words, don't commit the JSON entity for every keystroke. Save the final filter state after the user has stopped changing it, and make sure only one save operation for a given user/grid configuration can be processed at a time.

So I would try this order:

1. Enable an appropriate Apply after (ms) value on the Text/Number filters.
2. If the JSON is only for restoring filter preferences, use DG2's built-in Store Filters in Personalization instead of a custom save flow.
3. If custom persistence is required, debounce/serialize the persistence operation itself, not only the filter input.
4. Check the browser Network tab as well. If you see multiple requests updating the same preference entity concurrently, that confirms the race condition.

The important distinction is that debouncing the UI input and preventing concurrent persistence writes are two different things. A JavaScript debounce alone won't completely solve the problem if already-started save requests can still complete out of order.

Hope this helps.

Hi Harshad,

Switching to OnLeave or OnEnter will reduce the flickering, but I'd treat that as a partial fix. The real cause is that every keystroke triggers a commit and refresh, so the grid re-renders while the user is still typing. A debouncer in JavaScript can only delay that, it can't stop it.

Here is what I'd do, roughly in order of effort:

• Save less often. With OnLeave or OnEnter, one filter change produces one save instead of one per character. This is the quickest change, and it also fixes the race condition, because the saves no longer overlap.
• Use the widget's own delay. The Text filter widget has an apply-after delay setting. Raise it to around 800-1000 ms so the filter only fires once the user pauses. Then you can drop the custom debouncer.
• Don't commit on every change. If the saved filter object is being refreshed in the client after each commit, the grid re-renders each time. Change the attribute without committing, and commit later (when the user leaves the page or clicks Apply).
• Consider browser storage. If the preferences only need to be remembered per user on one device, the grid's built-in personalization can store the configuration in the browser instead of your database. That removes the server round trip entirely.

I'd start with OnLeave plus a longer delay. If it still flickers, look at the commit and refresh behaviour next.

Kindly mark this as the accepted answer if it helps.