1. Event → action
“Look,” Alex starts breaking it down in plain terms. “Before I show you the trick, understand one simple thing it rests on. Think about any system around you — your laptop, your phone, even the entrance to your building. Things are constantly happening in them. You press a button. A message arrives. Someone walks through the door. All of this is events. Little ‘something happened’ moments.”
“Well, things happen, so what?” Tommy shrugs, like, what’s the big discovery?
“Well,” Alex continues, “a ton of handy things in tech rely on that. The main idea is simple: you can attach an action to an event. One thing happens — another one runs automatically. Nobody stands next to it and does the second thing by hand.”
He shows the whole model on screen in one arrow:
EVENT → ACTION
(something happened) (in response, something else happened automatically)“And here are some real-life examples, just so it really clicks,” he adds:
- someone walked into the entryway → the light turned on;
- a message arrived → the phone beeped;
- the file was saved → the check started.
“Notice the main thing.” Alex zeroes in on exactly this. “Nobody stands there and does the second thing manually. The connection is set up once — and after that everything happens on its own, every time. There can be a hundred different events, but the scheme is always the same: event → action. Keep that part, the event names are secondary.”
“That really is simple.” Tommy nods. “The message arrived — it beeped. Nobody sits there and beeps by hand after every message.”
2. The same thing — but in code
“And now the main thing I’ve been torturing you for.” Alex shifts into business mode. “This is not just about entryways. Code works exactly the same way. In any program, things are always happening too — only its events are its own, software ones: the user clicked the mouse, a file was saved, a network request came in, a task finished. And to each such event you can attach a piece of code that will run in response.”
“Wait.” Tommy squints. “Is that like in my games? I press a button — the game launches. A click is an event, right?”
“Exactly.” Alex is pleased that it clicked by itself. “A click on a button is an event. Launching the game is the action in response. You’ve been using this whole course and didn’t know the thing had a name. And that name is: the piece of code that hangs on an event and runs when it comes is called a handler. The event comes in — the handler runs.”
He sketches the form — not real code, but how it reads:
when (file saved):
check spelling“See?” Alex traces it with his finger. “On the left is the event we are waiting for. On the right is the handler, what to do when it happens. The whole event-driven machinery is about this connection.”
One scheme everywhere: event → handler. Left — the event: something happened, picked from the system’s ready list; right — the handler: what to do in response, it hangs on the event and runs. Entryway: someone walked in — turn on the light. Phone: a message arrived — beep. Code: file saved — check spelling; in code it is written as “when (file saved):” — the event we wait for, and below it “check spelling” — the handler, what to do in response. The link is set up once — then it runs by itself, every time; event names differ, the scheme is the same One scheme everywhere: event → handler Event something happened — from the system’s list Handler what to do in response — hangs on the event and runs Entryway Phone Code In code someone walked in a message arrived file saved turn on the light beep check spelling when (file saved): check spelling ← the event we wait for ← the handler: what to do in response The link is set up once — then it runs by itself, every time. Event names differ — the scheme is the same“So where do I get this event from?” Tommy thinks it through. “I make it up?”
“Good question, and an important answer.” Alex does not let him get away with guessing. “Usually you do not make it up. Events are almost always fixed in advance — the system gives you a ready-made list of what it can notice: ‘file saved,’ ‘button pressed,’ ‘the program launched.’ You choose from that list, not invent your own. Remember this — it will come in handy in five minutes.”
3. Three controls: subscription, switch, filter
“And since a handler is a separate thing that you hang on an event,” Alex continues, “that means you can control it. There are three controls here, remember them, they are simple.”
“First — subscription. Attach a handler to an event — that is called subscribing. Changed your mind — remove the handler, that is unsubscribing. The event keeps living as it was, you just connect to it or disconnect from it. By the way, you can attach as many as 33 handlers to one event at once — they all run.”
“Second — switch. A handler can be temporarily turned off without deleting it. Like a breaker: the event comes in, but the response stays silent until you turn it back on. Handy when you do not need the thing all the time.”
“Third — filter. This is so you react not to everything at once, but only under a condition. Say the ‘file saved’ event arrives for any file — an image and code alike. But maybe you only want to react to code. Attach a filter:”
when (file saved) and (it is .js):
check the code“Save an image — the handler stays silent. Save .js — it runs. A filter is the condition under which the response turns on, otherwise it skips it.”
“Oh, that is handy.” Tommy nods. “Otherwise it would twitch on every sneeze.”
Three handler controls. In all three cards the same “file saved” event comes three times: an image .png, code .js, more code .js; only the control changes. Subscription: while subscribed, the handler runs on everything; unsubscribed — there is no handler any more, the event comes and no one reacts. Switch: the handler is in place but turned off — events come, the reaction is silent; it is not deleted, switch it back on and it works. Filter: the condition “is it .js?” cuts off the .png image and runs on the .js code. The event lives on its own; the controls decide only whether there is a reaction to it Three handler controls In all three — the same “file saved” events. Only the control changes Subscription Switch Filter attach — subscribe, remove — unsubscribe turned off for a while, not deleted reacts only under a condition eventreaction eventreaction eventreaction .png.js.js .png.js.js .png.js.js unsubscribed ✗ ✓ ran✓ ran ✓ ran✓ ran no one silentsilentsilent cut off OFF is it .js? Subscribed — runs on everything. Unsubscribed — no handler, the event comes, no one to react Events come, the handler is there but silent. Not deleted: switch it on — it works again Cuts off the image, runs on the code: the reaction fires only under the condition The event lives on its own. The controls decide only one thing — whether there is a reaction to it4. Code that does not run, but waits
“And this is where,” Alex says, catching the moment, “one thing about how this differs from ordinary code has to sink in.”
“In ordinary code, commands go in order, top to bottom: do one, do two, do three — and the program ends. Events break that order. You do not write ‘do it’ — you write ‘when this happens, do that’ and leave it there. The program does not end — it waits. An event comes in — the handler runs. No event — it lies there and keeps waiting. A lot of real systems live exactly like this: they do not run through the list to the end, they sit and react to events.”
Plain code runs, event code waits. Left — plain code: commands in order from top to bottom — do step one, do step two, do step three — and the end, the program has finished; you write “do”. Right — event code: the rule “when someone walks in — turn on the light” hangs and waits; events come along the timeline — you walk in, the neighbor walks in, the cat walks in — and each one triggers the light; between events the handler just waits, there is no end. You write “when it happens — do” and leave it. The sensor is dumb: it fires for anyone — even the cat, even when you are on vacation; that is its strength and its weakness Plain code runs, event code waits Plain code you write “do” do step one do step two do step three ■ end the program ended Event code you write “when it happens — do” and leave it when (someone walks in): turn on the light the rule was set once — the handler hangs and waits events you walk in neighbor walks in cat walks in reaction lightlightlight waitswaitswaits… no end — time goes on The sensor is dumb: it fires for anyone — even the cat, even when you’re on vacation. It doesn’t think whether it’s needed now. That is its strength and its weakness“That is my morning motion sensor.” Tommy figures it out on his own. “In the entryway. Remember: you walk into a dark entryway, and before I used to feel for the switch on the wall myself. With the sensor — walk in → light. The sensor does not ‘run and turn off forever.’ It hangs there and waits. You walk in, a neighbor walks in, a cat walks in — it triggers every time.”
“There, that is a great picture, hold on to it.” Alex is pleased. “Set it up once — and it lives without you, for every incoming one, always. And notice: the sensor is dumb. You are on vacation, you do not need the light — and it will still turn on if someone goes in. It does not think whether it is needed right now or not. It just reacts to its own event. That is both its strength and its weakness — remember it, it will come back to bite you when you have a lot of these automations.”
5. Shift: from “do it by hand” to “configure the system”
“And here is what is most important in all this for you personally.” Alex turns it back to the practical side. “Up to now, how have you worked? You called actions by hand. Wanted something — asked the agent, it did it. Wanted something else — asked again. You are the executor: you do everything yourself, keep everything in your head, forget something — it is gone. But event-driven stuff moves you into a different chair: you start configuring the system’s behavior. Set the rule once, ‘when this happens, do that’ — and the system carries it without you, forgetting nothing.”
“So I stop being the one who pulls the lever every time,” Tommy says it out loud so it settles in. “I become the one who set that lever once.”
flowchart TB
subgraph E["The executor — pulls the lever every time"]
direction LR
E1["Wanted it"] --> E2["Asked the agent"] --> E3["It did it"] --> E4["Keep it
in your head"] --> E5["Forgot —
it’s gone"]
E3 -.->|"and again, by hand"| E1
end
subgraph N["The setup person — set the lever once"]
direction LR
N1["Set the rule once:
when — do"] --> N2["The event
happened"] --> N3["The system
did it itself"] --> N4["A log outside:
no need to remember"]
N3 -.->|"the next event —
again by itself, without you"| N2
end
E ~~~ N
“Exactly. The executor — or the setup person. And notice how this fixes your morning problem. You spent the whole day as the executor: tweaking the ticker by hand, keeping the successful option in your head — and your head, damn it, did not hold on to it. If you had been the setup person, the log would have been kept automatically, and you would not have had to guess anything today. One of the most useful examples of this arrow is exactly this: the system writes the log itself. Something important happened — it was written to an external file on its own. An external trace: no need to remember, everything is recorded.”
And here Alex puts a marker down — firmly, so it sticks:
“Just nail this down now so you do not get confused: the log outside is a trace for you, not the system’s own ‘memory.’ Different things — we will come back to them.” And he adds in passing: “Keep one small thing in the background: every trigger is work, and work costs something. Load too many such automations or clumsy ones — the system churns in idle and burns resources. It is useful, but in moderation.”
“Yeah, yeah, in moderation.” Tommy brushes the caution aside, all fired up about “I’ll attach more.” What mattered most to him was this: event → handler, set it once — it lives on its own. “Hey, and what is it called with the agent? You said it has a fixed list — what events does it have?”
“Now you have asked the right question.” Alex nods. “The agent has exactly the same mechanics: its own ready-made list of events — ‘you sent a request,’ ‘the agent finished its answer’ — and you can attach a handler to each one. It is called by one short word. Let’s go, I’ll show you.”