Is there a handler used when loading a List element for the first time or when reloading the list, including after changing quick filters? The crt.LoadDataRequest handler appears to only be called when reloading the list or loading in additional records via the infinite scroll mechanic, but not on the first load of the data or when reloading the data after quick filters are changed, so it does not fit the need.
What I'm looking to do is to intercept the initial loading of the data for the list to perform some async task, and once that async task has been completed allow the load to resume as usual. This should be triggered when the page first loads the list in, and whenever the user clicks to reload the list manually or changes quick filters that change the list data, but shouldn't be triggered on the infinite scroll.
Like
Hello,
The initial data loading request 'crt.LoadDataRequest' was not included in this step because it’s part of the system's core loading process, ensuring that essential page elements are set up first.
On subsequent loads, the system publishes 'crt.LoadDataRequest' where users can apply their customizations.
Currently, there’s no default handler to directly intercept the system’s initial load, but there are other options for customization depending on the user’s needs.
Additional options include:
1) System "crt.HandleViewModelInitRequest" on view model initialization.
2) A change request on view model attribute change, more details on this approach below:
! Warning: Theoretically, this approach could cause slower performance when working with the card, as it increases the total number of handler calls (the approach will trigger on every list change: loading, reloading, sorting change, column list change, and column value change).
To use this approach, add a change marker to the appropriate DataGrid attribute (example below):
T
hen, add a handler to process the usr.MyRequest in the handlers, similar to how it's done for crt.LoadDataRequest and crt.DataGridCreateItemRequest.
As a result, your custom logic will execute when a new column is added, or when a column is deleted, and for other list changes.
Hope this helps, and thank you for reaching out!
Hi Pavlo, thank you for the detailed response! I'm sure that functionality will come in handy.
Unfortunately, for our use case, we need to perform an action before the data is fetched for the reload, whereas this change triggers only after the data has already been fetched from the database to reload the list. Is there anything that would fire in a similar way but before the data is requested from the server? LoadDataRequest does this, but has the drawbacks of being called only in certain circumstances.
Is there any documentation on the event handler "call stack"? This would be really useful, knowing that, for example, when a user clicks the reload button, first handler X is called to do some action, then handler crt.LoadDataRequest is called to handle the outbound data call to the servers, then the data is sent to the user's browser, then handler Y is called to do some action, then handlers that are associated with the change property of viewModelConfig are called when updating the data stored in the List, etc.
Many thanks,
Harvey
Harvey Adcock,
Hello,
Thank you for the additional clarification. Unfortunately, at this time, this option is not available.
I have created a task for the development team to implement such a handler in the system.
Thank you for helping us improve our product.
Best regards,
Pavlo
Hi Pavlo, thanks - I think we really need some more consistency in what triggers handlers and what doesn't. Performance implications of overriding certain handlers is something for the developers to consider (ideally armed with documentation on any things to look out for - the current info on request handlers in the Academy is incredibly limited) and not really something that should be prevented from being done entirely. Why even have the ability to override LoadDataRequest when one of the main times it should be called (first loading data for a List) it doesn't even fire? Developers just end up having to do workarounds that are even worse for performance, such as triggering a reload of the data from code, so the data gets requested twice.
There are so many page events which would've previously in Classic UI triggered something in the page code that developers could override as needed, but now it's just flipping a coin to find out if the event you need to capture and handle in some custom way is possible to be overridden or not.