Events Are Changes That May Or May Not Matter

This is kind of a programming essay, focused on understanding events and actions. All mistakes herein are mine.

Systems are abstractions of our understanding of {x}.

Understanding is never entirely consistent nor entirely complete. We receive new information (an event) and may update our understanding – we may accept or reject the new information, and take any resulting action.

We can choose to ignore information, but we cannot choose to be “clueless” – that is our given state from which we grow.

Within any system, then…

“Understanding” Is A Dependency

There is no completely shared understanding of how things should work in userland, except that every change to what we do understand can affect something else we understand.

“Ignorance” Is A Dependency

Everyone is dutifully learning, copying, reproducing, iterating and improving on something, but fundamentally, concepts underlying 3rd-party and open-source software deviate in subtle ways we don’t understand when starting out.

Stated more brutally, everyone is in some way “clueless” about what they are doing or how they are doing it. Faddish, cargo cult, adoption of something for the sake of action may be justified because of this. There is danger in persistent shared cluelessness – of which the most poignant sign is that nothing is improving no matter how we do it.

“Abstraction” is a dependency

We should spend far more time understanding what we are trying to accomplish with our software without deciding what software to use.

“Action” is a dependency

Like it or not, we have to ask, what behavior do we want? A thing on a page is changed, so what should happen to other things, if anything at all?

“Listening” is a dependency

In the typical abstract system, something must “listen” for events or messages from something else.

Events Are Changes That May Or May Not Matter

What we usually call “events” are really changes to the system state. A user clicks a element – that is a “change” because there is new information (click event at timestamp on element). [Note: This may or may not include an input element’s change event, where the value is modified and the user focus moves out of the input.]

A Change That Matters Results In Action(s)… Eventually

‘Action’ doesn’t capture the idea of a change, ‘event’ doesn’t capture it, only ‘change’ steers us toward the idea of temporal logic. A change may sometimes have a temporal consequence (action), but a change is itself always a temporal consequence. “Do nothing until {x},” “Repeat {y} until {z},” “Next {x},” “Eventually {x}…”

Thinking of events and actions more generically as “changes” whether they mean anything or not, we can see more directly that a change has meaning if we can apply the information about it to something else (an internal state, a log, a REST call, a dialog displayed or dismissed).

Traffic Lights

As a driver – or a pedestrian – in a traffic-light regulated system, I am effectively one system in communication with at least one other.

Next event, a signal changes from green to yellow. Next action, apply the brake.

Automated Fail-safe Example

In live-man switch systems (e.g., locomotives), the system listens for an event (e.g., a press of a control) indicating the system may continue in its present state. The system is initialized at startup or acceleration, to expect this event within 60 seconds. If the event is not received within 60 seconds, the system then “takes action” to reset itself to another state (slowing down, stopping). If the event is received within 60 seconds, the listener’s timer is reset to another 60 seconds.

Changes in Sequence

A page or application loads, then after a second there appears a modal overlay with a dialog message or call to action with form fields or a button or both, and/or a link that reads “close” or “no thanks” or just “X”.

What has really happened? The page starts loading (that is a change), then completes loading (that is a change). A timer is started (that is a change), then expires (that is a change). A function is called (is that a change? maybe…). The function checks for the presence of the dialog or its “open” state (is that a change?). If the dialog is not open, the function sets it to open or calls another function to do that (that is a change). Finally, the dialog initializes its open state (add event listeners, e.g.) and displays (that is a change).

If the dialog displays an advertisement, the user clicks something or presses the Esc key to dismiss the dialog (that is a change).

If the dialog is an authentication prompt, the user fills in the criteria and clicks a button or presses the Enter to submit them (that is a change). The dialog validates the criteria and rejects them (that is a change). The rejection is handled by displaying an error message (that is a change). The user corrects the input criteria and re-submits (that is a change).

And on it goes. With every action or event, there is a change. What change is applied? What is it being applied to? The “state” of the application? The “view” of the state? The “model” of the change?

End of Act I

I hope to answer these thoughts in a subsequent post, tentatively titled, “Temporal Logic of Changes” – which you may recognize from TLA+ (@see but which I understand only a little so far…

  • [ This post started 20 Jan 2018 ]
  • [ This post updated 16 Aug 2019 ]

Or not.

Change my mind.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s