When a page displays a large number of View Entities (e.g., within a DataGrid2), an unexpected behavior occurs: these displayed View Entities are included in the payload of backend requests, even if they are not directly used by the microflow or target page triggered by the request. This behavior is similar to how Non-Persistent Entities (NPEs) are handled.

For example, consider a page displaying hundreds of Example View Entities in a DataGrid2. If a button on this page triggers a microflow to open a pop-up for creating a Calendar (a persistent entity not correlated with Example), the backend request initiated by clicking the button will include all the Example View Entities in its changes section.

This can lead to significant performance lag and a degraded user experience, especially when hundreds of View Entities are present on the page, due to the large amount of data unnecessarily sent to the backend.

This behavior is an intentional design choice related to Mendix's optimization strategy. View Entities are treated similarly to Non-Persistent Entities (NPEs) in certain scenarios regarding backend requests.

The core reason for sending these objects back to the server is the lack of a persistent identifier for View Entities on the client side.

• Persistent Objects: These have stable object IDs stored in the database. The client only needs to remember this ID, and the server can retrieve the exact object from the database when needed.

• View Entities: These are translated into SQL queries that return rows, which are then converted into objects. The IDs assigned to these client-side View Entity objects are ephemeral and cannot be used by the server to reliably retrieve a specific row from the original View Entity query.

Therefore, to maintain data consistency and prevent potential mismatches, the system sends the client-side View Entity objects back to the backend. This ensures that the server has the exact state of the objects the client is interacting with, even if they are not explicitly passed as microflow parameters. The complexity of the microflow being called can also influence whether certain optimizations, which might otherwise prevent sending these objects, are applied.

To mitigate the performance impact caused by a large number of View Entities being sent to the backend, consider the following strategies:

1. Reduce the Number of Displayed View Entities:

   • Implement Pagination: Use pagination for DataGrid2 or other list widgets to limit the number of View Entities displayed on a single page. This significantly reduces the payload size.

   • Apply Filters: Utilize filters to narrow down the displayed View Entities to only those relevant to the user at a given time.

   • Lazy Loading: If applicable, explore options for lazy loading data, where View Entities are only fetched and displayed when they are actively needed or scrolled into view.

2. Optimize Microflow Design:

   • Review Microflow Parameters: Ensure that microflows are designed to accept only the necessary parameters. While the system might still send other objects in the payload, explicitly defining parameters can sometimes help the runtime optimize what is processed.

   • Simplify Microflows: Complex microflows can sometimes prevent certain runtime optimizations. Where possible, simplify microflow logic, especially for actions that do not directly interact with the displayed View Entities.