# JENTIS States Framework

## Page Lifecycle, Events, and JENTIS Data Layer <a href="#jentisstatesframework-pagelifecycle-events-andjentisdatalayer" id="jentisstatesframework-pagelifecycle-events-andjentisdatalayer"></a>

To understand the JENTIS States and how they function, it’s essential to first delve into the **Page Lifecycle** and **Events** concepts in web development and how the JENTIS Data Layer works. JENTIS States are built on an event-driven data model architecture, so they are often used interchangeably with events. However, there are key differences between them that we will explore in detail in this article.

### Page Lifecycle <a href="#jentisstatesframework-pagelifecycle" id="jentisstatesframework-pagelifecycle"></a>

We all know what it means to browse a website—but what does that technically mean? In the web development community, there is a thing often described as the **page lifecycle**. A page lifecycle refers to the different stages a webpage goes through, from when it loads in a browser to when it is closed or navigated away from. It helps developers understand how a page interacts with the browser and when specific events happen so they can optimize performance and manage resources efficiently.

### Events <a href="#jentisstatesframework-events" id="jentisstatesframework-events"></a>

**Events** are milestones or triggers that occur during the page lifecycle, signaling key moments in the lifecycle stages. Developers use these events to execute specific actions, like initializing scripts, managing resources, or saving data. **DOMReady** (`DOMContentLoaded`) and **On Page Load (**`load`) are specific events within the **page lifecycle** that indicate when certain things are ready on the webpage.

* The **DOMReady** event happens after the HTML is fully loaded and the DOM (Document Object Model) is built. The page structure is ready for interaction, but images, styles, and other resources may still be loading.
* The **On Page Load** event happens after the entire page, including all images, styles, scripts, and other resources, is fully loaded. the page is completely ready for use.

{% hint style="info" %}
If you want to know more about events, we recommend reading <https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Building_blocks/Events>
{% endhint %}

## JENTIS Data Layer <a href="#jentisstatesframework-jentisdatalayer" id="jentisstatesframework-jentisdatalayer"></a>

The most resilient way to connect JENTIS to your data is to actively push data to the **JENTIS Data Layer**—read more on [JENTIS Data Layer: Push Data](https://docs.jentis.com/documentation/jentis-data-layer-fundamentals). With that approach, you will push descriptive data (product name, page title, etc.) and commands (events, tracking signals to invoke a state like pageview, virtual pageview, productview, etc.). We highly recommend implementing JENTIS using this approach with an aligned up-tracking map that displays all requirements and parameters.

However, that is not the only option in practice. Signals and data can also be picked up during the **page lifecycle** and on certain **events**. These can be any interactions of the user or other applications submitting data to a generic (non-JENTIS flavor) data layer.

{% hint style="info" %}
In the following articles, we have covered popular examples and use cases for events translated into JENTIS States:

* Listen to Google Tag Manager Data Layer Events: [Listen to Datalayer Events](https://docs.jentis.com/use-cases-and-tutorials/events-and-custom-states/listen-to-datalayer-events)
* Clicks, Form Submits and Scroll Tracking: [Form Submit, Click and Other Actions](https://docs.jentis.com/use-cases-and-tutorials/events-and-custom-states/form-submit-click-and-other-actions)
* History Change States and Virtual Pageviews: [History Change State and Virtual Pageviews](https://docs.jentis.com/use-cases-and-tutorials/events-and-custom-states/history-change-state-and-virtual-pageviews)

Both implementation types, pushing or listening, will create a JENTIS State. The default push of events, page views, etc., is the same in the internal framework, and we will treat both options equally in the architecture.
{% endhint %}

## JENTIS States Architecture <a href="#jentisstatesframework-jentisstatesarchitecture" id="jentisstatesframework-jentisstatesarchitecture"></a>

Now that we better understand **page lifecycle**, **events,** and both options to **push active data on the JENTIS Data Layer** and/or listen to **page lifecycle events**, we can zoom out on the topic and understand the **States Architecture**.

In the JENTIS States, there are the **triggers**. When a JENTIS State is activated, all variables and triggers will be evaluated as the event is called or the push is submitted. This is where the tags can now be activated, creating a logical chain of events, as in the following diagram:

<figure><img src="https://2315305008-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy15ncufYr341K5U8q6Of%2Fuploads%2F7gb7cW06F955MMrlmbNL%2Fimage.png?alt=media&#x26;token=866a02a3-1e9f-4477-ba77-dc36096bd89d" alt=""><figcaption></figcaption></figure>

In each JENTIS State, all variables and triggers are evaluated simultaneously. This ensures that each variable has a single, static value at that specific moment. As a result, all triggers and tags activated within that JENTIS State use the same consistent parameter values.

For example, a new JENTIS State is created when a user clicks a button. This state signals the relevant triggers to evaluate whether they should fire based on the updated conditions (e.g., the button's ID or the current user session).

Variables are re-evaluated at different moments (e.g., when a button is clicked on the same page a few seconds later). At that time, their values may change if they are updated due to changes in the website's presentation during interaction or loading.

For a better understanding, here is an example:

<table><thead><tr><th width="174.734375">JENTIS State</th><th width="228.6328125">Variable "Page Title" Value</th><th>Variable "Price Tag" (CSS Selector - Text Value)</th></tr></thead><tbody><tr><td>_jts.push({<br>track: "submit"<br>});</td><td>"My Product Detail Page"</td><td>undefined</td></tr><tr><td>DOM ready</td><td>"My Product Detail Page"</td><td>19.99 €</td></tr><tr><td>Button Click</td><td>"My Product Detail Page"</td><td>19.99 €</td></tr></tbody></table>

Imagine a user is shopping in an online store. They visit a product page, and the price tag is initially hidden or dynamically loaded by JavaScript after the page starts rendering. You want to track the price tag value when the user clicks the "Add to Cart" button.

1. **Page Load**: When the page first loads, the JavaScript begins to render the page.
   * **JENTIS State 1**: The “Price Tag” element is not yet visible because the script hasn't rendered it. The **Price Tag variable** is **undefined** at this moment.
2. **DOM Ready**: After a short delay, the DOM is ready, and the page structure is fully loaded.
   * **JENTIS State 2**: The "Price Tag" is now visible on the page, and its value has been set (e.g., "19.99 €"). This value is available for tracking.
3. **Button Click**: The user clicks the "Add to Cart" button, triggering another event.
   * **JENTIS State 3**: The "Price Tag" variable is evaluated again, but now the price is available and can be tracked accurately.

In this scenario, the **JENTIS State** ensures that the value of the "Price Tag" variable is consistent and tied to specific moments, such as when the DOM is ready or when the button is clicked.

{% hint style="info" %}
If you want to understand better how to create and manage JENTIS States on our platform, read [States](https://docs.jentis.com/jentis-dcp-elements/states)
{% endhint %}