There are no tracking or monitoring cookies on this site. There are only cookies used for documentation examples related to cookies.
Close

Processing...
This may take a few seconds.

The "observe" event

This is a custom Active CSS event (introduced in 2.9.0) that can be used to monitor changes as they occur in the DOM. You can monitor changes from the viewpoint of disassociated elements, and if all conditions pass the test, then the event can run. It will only run once. If the conditions continue to match, it will not run again.

To get the event to run again, a conditional in the observe event must fail. When a failure has occurred in a particular observe event, it resets and waits for all the conditions to match again. When it matches again, it re-runs the event. And so on. It will probably make more sense if you see an example.

Observe events must be declared in the scope that the related element is used. If an element is drawn inside a component, the observe event must be placed inside that component. If the element is pre-rendered on the page, or in the document scope, the observe event must be outside of all components.

button:click {
body { toggle-class: .helloWorld; }
}

body.helloWorld:observe {
p { render: "The helloWorld class is now on the body tag."; }
}

body:not(.helloWorld):observe {
p { render: "The body tag does not have the helloWorld class."; }
}

The example above has two opposite observe events. Both react to specific changes made on the body tag.

 

This event is in the same class of events as the "draw" event. It is a passive event that reacts to DOM changes. You could call it a reactive event, or an indirect event, because it applies to changes in the DOM rather than direct user interaction.

It works with regular CSS, and with all ACSS conditionals in the regular way, as documented elsewhere. So it is quite a powerful feature.

A whole different paradigm of coding is made possible with this command. Event logic can come out of the UI and into the element itself. With the observe event, you can think about coding from the viewpoint of the element itself, rather than from the user interaction, so it's a slightly different way to think about doing things. It can make certain scenarios a bit easier to work with.

But it is best used in combination with all events, because like a lot of programming techniques if it is over-used your code may get more complex than needed. It is simply another useful tool to apply when you think it is appropriate.

 

Important usage note: Observe events must be declared in the scope that the related element is used, or it will not run. If an element is drawn inside a component, the observe event must be placed inside that component. If the element is pre-rendered on the page, or the element is rendered in the document scope, the observe event must be written outside of all components.

 

Technical note: The observe event is based on mutationObserver, but that wasn't enough to be fully intuitive to develop with. So it is also triggered by other things which do not trigger DOM mutations, such as changes to input fields. If you find anything that you think should be included for the observe event in the future, strike up a conversation in GitHub.

(Special credit goes to D7460N (https://github.com/dragontheory). He came up with the idea for this feature, we mauled it over, and it ended up as the observe event. Respect goes to him for his visionary thinking and contributions of ideas.)

Observe events — responding to changes on elements: