Idea - Expose a DataLoaded event for the OutSystems Data Grid

Expose a DataLoaded event for the OutSystems Data Grid

New

Components

Dear OutSystems team,

the OutSystems Data Grid lacks an event to intercept the moment when the rows in the grid are loaded and ready to be manipulated.
The Initialized event and the OnAfterFetch event do not guarantee that a cell or a row is loaded into the grid, so any action that needs to access the Data Grid data, for example, will most likely fail if used in this context.
An example would be apply a specific CSS class only to specific cells given a combination of conditions on the cell's row data: the action in API_Styles will most likely fail, together with the ones in API_Rows and the Conditional Formatting of the columns is not powerful enough to add CSS classes only to specific cells in a row or in a column.

Also by trying to intercept the loadedRows/collectionChanged event of the FlexGrid using a similar mechanism implemented for the OOTB events of the Data Grid, there is the possibility the first loading of the data is missed due to the handler being registered after the grid loaded the rows (I tried in this Forge component: https://www.outsystems.com/forge/component-overview/21664/raffaeles-data-grid-utilities-o11)

I think having an OOTB DataLoaded event exposed directly by the Grid block would help in a lot of situation where there is the need to have the data loaded and accessible into the grid.

Thank you for your time!

Best regards,
Raffaele Battipaglia

8 days ago

Miguel Angel Rudilla

Hi @Raffaele Battipaglia (and OutSystems Product Team),

Great post and fantastic initiative! We completely agree with this proposal—having an OOTB 'OnDataLoaded' or 'OnRowsLoaded' event exposed directly by the Data Grid block would be a game-changer for Reactive apps.

In our experience, trying to manipulate grid cells or apply dynamic CSS classes right after data fetching often leads to race conditions.

Since 'Initialized' fires before data binding and 'OnAfterFetch' occurs before Wijmo finishes rendering the DOM rows, executing actions like GridAPI.Styles or GridAPI.Rows can be fragile without complex JS workarounds (like checking rows.length inside formatItem or loadedRows).

Having a native event that guarantees the rows are fully bound and ready in the DOM would make custom cell formatting, dynamic styles, and post-load calculations much cleaner, low-code compliant, and easier to maintain across projects.

Fully supporting this idea! Thanks for sharing!

8 days ago