# Triggers, Events & Actions {% hint style="success" %} Much of SA5's most notable developments have been behavioral. Show or hide items, connect things to the position of a video, perform actions as your slider advances. As a result we've been rethinking how triggers, actions, and events work in SA5. This library is being re-conceptualized and is likely to be absorbed into **SA6 Core**. {% endhint %} SA5's Trigger lib was originally about triggering an interaction such as a pop-up modal from a click event. The user clicks something and we trigger an interaction event. This was useful for; * Displaying a modal from a nav button click * Displaying a pop-up definition when clicking on a linked term in a blog post * Displaying a modal when the user clicks a map pin ## How It's Evolving This concept has expanded significantly, and we're re-conceptualizing everything; * The types of trigger events we want to support * The resulting actions that we want to support * The model connecting those two At the center of this model is a more versatile structure we refer to as **Trigger-Event-Action ( TEA )**. This is the simplest TEA arrangement. Here's the basic mechanic. Elements in your webpage are marked up with attributes that identify the Triggers, Events, and Actions you want configured. 1. A Trigger is fired, such as a button click 2. This invokes the specified Event 3. The Event then performs the specified Actions Let's look at a simple example; Here's an example of a click Trigger, which invokes `my-event`. ```html ``` When a user clicks this button, SA5 invokes the Event named `my-event`. This in turn performs whatever Actions are connected to `my-event`. By itself, the above construction does nothing, because the Event is not connected to any Actions. Let's add an Action to a Webflow tab, so that clicking the button clicks ( and changes to ) that specific tab. Here's an example; ```html
Tab 1
``` When the `my-event` Event is invoked, a click Action will be performed on this tab. In this construction; * `wfu-action-click` indicates the type of Action that will be performed * `my-event` indicates the Event * The element itself is where the Action will be performed. ## More Advanced Eventing The Event is the center of the TEA architecture, and there are two crucial concepts to understand here that grant you a huge amount of flexibility in your designs; * Any number of Triggers can invoke the same Event. * When the Event is invoked, any number of Actions may be performed. ## So Many Types of TEA {% hint style="info" %} If you're familiar with systems engineering, TEA follows a familiar Pub/Sub style pattern. {% endhint %} ### Triggers Here are a few types of **SA5 Triggers** we're working on, which can invoke *SA5 Events*; * User triggers. Click, scroll, hover, etc. * Systems triggers. Timers, etc. * Webflow triggers. * Interactions, at any point in the interaction. * Possibly, certain other system.level mechanics... open or close of a hamburger menu * Tab switches * Slider events * Custom triggers. Custom code-triggered events. * Breakpoint change triggers. * Keyboard triggers. * Mutation Observer triggers. * Custom triggers. * Other triggers. ### Event An **SA5 Event** is effectively a messaging pipeline, which has a name that you assign. When an event fires, it triggers a series of *SA5 Actions*. * Multiple Triggers can invoke the same Event. * An Event can perform several Actions {% hint style="info" %} **FUTURE NOTE** \ We're considering the ability for a *single* Trigger to invoke *multiple* Events. \ For example, `wfu-trigger-click` = `event1,event2,event3` \ If built, this may be limited to certain trigger types, owever at this point we have not identified key use cases where this adds substantial value. {% endhint %} ### Action An **SA5 Action** is a resulting action that can be invoked when an SA5 Event occurs. Examples; * A click on another element * Navigation * A webhook call * A logged event * A GTM event * etc. {% hint style="info" %} **FUTURE NOTE** \ We're also considering the concept of a Trigger as an Action type, so that we can chain Trigger-Event-Action sequences. {% endhint %} ## Examples Here are some rough examples; ## Use Cases This model handles an unthinkable number of possible use cases. * Mirror click. Clicking one button clicks another. * Form submit. Clicking a non-form-submit button triggers a form submission. * * There may evolve a distinction between Named Events and Unnamed Events * Named Events can be invoked directly from script * Concept Triggers are centralized around the concept of a named event. A ## Event Detail {% hint style="info" %} UNDER CONSIDERATION {% endhint %} In some scenarios there may be detail or context bundled into the event, which can affect the Action. Considering; * Sub-triggers, such as `##link` items for * Invoke dictionary pop-ups * Map pin pop-ups * Trigger chatbots, with content * Trigger AI chatbots ( like Gista ) with a query * Trigger GTM datalayer and events ## Considerations * Need to be mindful of preventing unrestrained circular event firing. * E.g. differentiate between user-triggered and code-triggered clicks --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://attr.sygnal.com/overview/events.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.