Screen Lifecycle Events: OnInitialize, OnReady, OnParametersChanged
Key Takeaways
- OnInitialize fires before the screen renders — it is the correct place to set Local Variable defaults, compute initial values, and prepare screen state before first render.
- OnReady fires after the screen finishes its initial render and the DOM is ready for interaction — use it for DOM manipulation or JavaScript integration.
- OnParametersChanged fires when the screen is already displayed and the user navigates to the same screen with different input parameters — use it to refresh data for the new context.
- The firing order on first load is OnInitialize → (screen renders) → OnReady; OnParametersChanged fires only on subsequent parameter changes, not on first load.
- Traditional Web Apps use a server-side Preparation action that runs before page render on every request — reactive apps replace this with client-side OnInitialize and Data Actions.
Quick Answer: Reactive Web App screens have three lifecycle events. OnInitialize fires before the screen renders and is where you set Local Variable defaults and prepare initial state. OnReady fires after the screen finishes rendering and the DOM is ready, for DOM manipulation or JavaScript integration. OnParametersChanged fires when the screen is already displayed and receives new input parameter values via navigation, letting you refresh data for the new context. Traditional Web Apps use a server-side Preparation action instead.
The Three Lifecycle Events and Their Firing Order
Every reactive screen has three lifecycle events that fire at different points in the screen's existence. Understanding the firing order is essential for placing logic correctly.
| Event | Fires When | Runs On | Typical Use |
|---|---|---|---|
| OnInitialize | Before first render, when the screen is instantiated | Client | Set Local Variable defaults, compute initial values |
| OnReady | After the screen finishes its initial render, DOM ready | Client | DOM manipulation, JavaScript integration |
| OnParametersChanged | After the screen is already displayed and input parameters change | Client | Refresh data for new parameter context |
The firing order on first load is: OnInitialize → screen renders → OnReady. OnParametersChanged does not fire on first load — it only fires on subsequent navigations to the same screen when the input parameter values differ from the current ones. If a user navigates from Screen A to Screen B with Id=5, OnInitialize and OnReady fire. If the user then navigates from Screen B back to Screen B with Id=10 (same screen, different parameter), OnParametersChanged fires but OnInitialize does not — the screen instance is reused, not recreated.
OnInitialize: Pre-Render Initialization
OnInitialize is a client-side event that fires before the screen renders for the first time. It runs exactly once per screen instance. This is the correct place to:
- Set initial values for Local Variables (default selections, computed display values, counters).
- Conditionally configure screen state based on input parameters that arrived via Navigate.
- Initialize flags or toggles before the first render.
OnInitialize executes before Data Actions fetch their data, making it the right place to set up parameters that Data Actions depend on — for example, setting a Local Variable that an Aggregate's filter uses as input. If you set the filter value in OnReady (which fires after render), the Data Action may already have fetched data with the old or null filter value, requiring an explicit refresh.
A common exam scenario: a screen has a Local Variable SelectedTab that defaults to the first tab. Setting SelectedTab = 1 in OnInitialize ensures the correct tab is highlighted on first render. Setting it in OnReady would cause a flash where no tab is selected before the value is applied.
OnReady: Post-Render DOM Interaction
OnReady is a client-side event that fires after the screen finishes its initial render and the DOM is fully ready for interaction. Use OnReady when you need to interact with the rendered DOM:
- Integrating third-party JavaScript libraries that require a rendered DOM element (charts, maps, rich text editors).
- Reading computed DOM properties (element dimensions, scroll positions).
- Setting up event listeners on DOM elements.
Do NOT use OnReady for setting Local Variable defaults — that belongs in OnInitialize, which runs before render. Setting a variable in OnReady means the first render uses the uninitialized value, and the screen updates only after OnReady runs, causing a visual flicker.
OnParametersChanged: Responding to Parameter Updates
OnParametersChanged fires when the screen is already displayed and receives new input parameter values — typically because the user navigated to the same screen with different parameters (for example, clicking a different item in a list while already viewing a detail screen). This event lets you refresh the screen's data based on the new context without recreating the entire screen instance.
Typical logic in OnParametersChanged:
- Call RefreshData on a Data Action to re-fetch records for the new parameter value.
- Update Local Variables that depend on the input parameter.
- Reset UI state (scroll position, selected filters) for the new context.
If a screen does not use OnParametersChanged, navigating to the same screen with different parameters will update the parameter values but will NOT automatically refresh any Data Actions or Aggregates that depend on those parameters — the developer must explicitly refresh the data.
Traditional Web Preparation as Contrast
Traditional Web Apps use a different model: the Preparation action. Preparation is a server-side action that runs before the screen renders, on every request. It fetches Aggregates, calls Server Actions, and sets Local Variables that the screen's widgets bind to. Preparation is the Traditional Web equivalent of combining OnInitialize and Data Action logic into a single server-side step.
| Aspect | Traditional Web Preparation | Reactive OnInitialize |
|---|---|---|
| Runs on | Server | Client (browser) |
| Fires | Every request (postbacks included) | Once per screen instance, before first render |
| Data fetching | Aggregates fetched in Preparation | Data Actions run independently, in parallel with render |
| Use case | Server-rendered pages with full postback | Client-side reactive rendering |
The exam may contrast these two models. The key distinction: Traditional Web Preparation is server-side and runs on every request including postbacks; reactive OnInitialize is client-side and runs once per screen instance. Data fetching in reactive apps is handled by Data Actions (which run in parallel with screen rendering), not by OnInitialize itself — OnInitialize prepares the state that Data Actions depend on.
Which screen lifecycle event fires after the screen finishes its initial render and the DOM is ready for interaction?
In a Traditional Web App, what is the purpose of the Preparation action?
When does the OnParametersChanged event fire on a reactive screen?