Screen and Block Lifecycle Events
On Initialize
The On Initialize event handler executes after checking the permission of the user to access the Screen, but before navigating to the Screen and starting to fetch data.
In Blocks, including any server action calls or local storage operations in this flow might cause the render of the Block to start before this action finishes. You will have issues if you set any variables in this flow that affect the render.
Notes:
Keep this event handler action simple and avoid slow actions such as local storage operations, since it may delay the rendering of the Screen or Block.
Avoid accessing the data of the Screen or Block since this action runs before the data is fetched.
Use cases you can implement with this event handler:
Assign a variable based on inputs.
Assign a variable based on some computation in JavaScript, such as a random number.
Redirect the application to another Screen if the user doesn’t have the authorization to see the Screen (only possible if the event handler belongs to a Screen).
Assign the parameters of a child Block based on the inputs of the Screen.
Access variables of the JavaScript window object.
On Ready
The On Ready event handler runs when the Screen or Block is ready, i.e. when the DOM is ready, after the first render. In Blocks, this event happens before the same event of the parent Screen or Block. To ensure a fast and smooth Screen or Block render, this event is triggered even before the transition to the Screen ends.
Notes:
The DOM of the previous and current Screens are loaded when this event is triggered. To ensure that you are operating on the screen being created, execute logic only for the HTML div element with the class active-screen.
Keep this event handler action simple and avoid using Screen Aggregates or Data Actions, which run in parallel, to manipulate data that might not be available.
Avoid accessing the data of the Screen or Block since this action runs before the data is fetched. If you need to develop some logic on these data, use the On After Fetch event handler of the respective Aggregate or Data Action.
Use cases you can implement with this event handler:
Initialize a third-party component that needs the DOM.
Add listeners to a DOM element.
Set the focus on an input widget.
Add listeners to the JavaScript window object.
On Render
The On Render event handler runs after each time the Screen or Block is rendered, i.e. whenever the Screen or Block is opened (right after the On Ready event handler execution) and after any change of the data of the Screen. In Blocks, this event happens before the same event of the parent Screen or Block. You can use this event handler to update a third-party component such as a progress bar.
Notes:
Avoid changing Screen or Block data since every time this data changes the On Render event is triggered again and the app might run in an infinite loop.
Keep this event handler action simple and avoid slow actions such as server requests, since it may delay the render of the Screen or Block.
On the first render of the Screen or Block avoid accessing the data of the Screen or Block since there is no guarantee that the data is already fetched. If you need to develop some logic on these data, use the On After Fetch event handler of the respective Aggregate or Data Action.
Use cases you can implement with this event handler:
Act upon a change in the data of the Screen or Block to update a third-party component.
The same use cases as for the On Ready event handler.
On After Fetch
The On After Fetch event handler executes right after an Aggregate or Data Action finishes fetching data. Since each Aggregate or Data Action has its own On After Fetch event handler, you can implement logic to act upon the data retrieved from that data source.
Notes:
When the On After Fetch event handler runs, the data has arrived and is available but it isn't bound to widgets. This means that the widgets haven't updated yet.
Use cases you can implement with this event handler:
Assign the first or last record returned by the query to a variable.
In the master-detail pattern, to iterate a query to populate a list of lists.
For queries dependent on other queries, you can use this event handler to trigger the dependent Aggregate.
Use cases you shouldn't implement with this event handler:
Don't use the GetUserId() function at this moment to know the user that is currently authenticated. The parallel execution of Data Actions and client-side Agreggates in a Screen overrides the session authentication cookie. Therefore, using the GetUserId() function in the On After Fetch event might return an empty value.
On Parameters Changed
The On Parameters Changed is an event handler only for Blocks that runs after the parent Screen or Block changes an input of the Block. In case you have a Block inside another Block and a change of an input of the outside Block affects an input of the nested Block, the On Parameters Changed event handler of the outer Block runs b