What do you gain by declaring behaviour such as prevent-default or run-once on an event binding rather than in the handler?
answer
- the binding carries more than a function
- the runtime reads it before your code
- a filtered event never calls you
- registration-time options are already fixed
basics
~20 sThe declaration is data the framework reads before your code runs, so it can act, skip the call entirely, or register the listener the host needs - and the handler body stays about your domain rather than plumbing.
solid answer
~50 sAn event binding is more than "call this function". Frameworks let the author attach declarations to it: suppress the host default, constrain host propagation, run at most once, ignore events that originated inside a descendant, fire only for a given key or pointer button, or request a registration-time choice such as observing the event on the way down. The gain is threefold. The runtime can act before or instead of calling you, so a filtered event never enters your code at all; registration-time options can be supplied because the framework owns the registration and your handler runs far too late to change it; and the handler body carries domain logic only. The costs are a per-framework grammar a reader has to know, framework-defined behaviour when several declarations combine, and the temptation to hide a business condition in a terse modifier. Mechanics on the binding, decisions in the handler.
go deeper
Know that a binding can say more than which function to call - suppress the default, run once, only for one key - and that the runtime applies those before your handler would run.
Explain the mechanics: a filtered event never enters your code, a one-shot release is the runtime's job, and registration-time options must be chosen before any event exists.
Draw the line in review: mechanics on the binding, domain decisions in the handler, and remember that a silent drop gives a bug report nothing to work with.
Treat the grammar as a portability and reviewability question. Terse modifiers compress plumbing well and hide business rules badly; say which categories your codebase allows.
A binding connects an event to a handler, but most frameworks let the author say more at that site than "which function". The extra declarations look like cosmetic shorthand and are not: they move work to a place where the runtime, not your code, can act on it. ## What authors typically declare - **Suppress the host's default action** for the interaction. - **Constrain host propagation** so layers above do not also react. - **Run at most once**, after which the wiring is released. - **Only if the event originated here**, ignoring ones that came from inside a descendant. - **Only for a specific key or pointer button**, so the handler is not called for anything else. - **Observe on the way down** rather than on the way back up, or hint how the registration should be made. The exact grammar is a framework detail. The categories are not: each is either something that can be done *without* your handler, or something that must be decided *before* the event exists. ## Why the binding is a better place than the body | Declaration on the binding | The same thing in the handler body | |---|---| | the filtered event never calls your code | your code runs and returns early on every event | | a one-shot release is handled by the runtime | you track "already done" state yourself | | a registration-time option can be honoured | too late - registration happened before the event | | the intent is visible at the usage site | the intent is buried in the first lines of a function | | the handler stays a domain function | the handler mixes plumbing with meaning | Three gains are worth separating: 1. **Avoided work.** A declaration the runtime evaluates can decline to invoke you. An early return does the same thing conceptually, but your function was still entered, and every reader of it has to scan past the guard to find the meaning. 2. **Things only the registrar can choose.** Whether the framework observes an event on its way down, or with what options it registers with the host, is fixed when the listener is created. Your handler runs during dispatch, long after that decision was made - which is exactly why the framework exposes it on the binding. 3. **Readable intent.** "This button does not submit the form" belongs where the binding is written, next to the element, not three lines into a function that is also doing something else. ## Where declarations stop being the right tool - **Domain conditions.** "Ignore this unless the row is editable" is business logic. In a terse modifier it is unreviewable and untestable; in the handler it is a named condition. - **Combinations.** When several declarations apply to one binding, the order they are evaluated in is defined by the framework, not by intuition. Stacking four and relying on their interaction is fragile. - **Conditions the handler already needs.** If the handler must know which key was pressed anyway, filtering by key on the binding splits one decision across two places. - **Anything needing a message.** A declaration silently drops the event; a handler can log, count or report why nothing happened, which matters when someone asks why a click did nothing. ## Interaction with the layer underneath Declarations that constrain host behaviour act through whatever the framework does with the host. That means two things worth remembering. First, the framework has to have the host event in hand to suppress its default action, so a declaration is not a magic pre-emption of the host - it is the framework calling the host's own control for you at the right moment. Second, code that also observes the same interaction by registering with the host directly is not looking through the framework's layer at all, and reasoning about the two together is a framework-specific exercise. ## Interview signal The answer to listen for has both halves. The gains: work the runtime can skip, decisions only the registrar can make, and a handler that stays about the domain. The limits: a grammar that is not portable, framework-defined combination behaviour, and the fact that a silent drop is invisible in a bug report. A candidate who says declarations are "just shorthand" has missed that a filtered event never reaches their code; one who encodes business rules in them has turned a readability feature into a place bugs hide.
- Why can a registration-time choice be declared on a binding but not decided inside the handler?Because the framework registers the listener with the host on your behalf, and such options are fixed at registration. By the time your handler runs, the event is already being dispatched under whatever options were chosen. The binding is the only place the author can influence them.
- When should a condition live in the handler instead of on the binding?When it is a domain rule, when it needs to report why nothing happened, or when the handler needs the same information anyway. Declarations are good at mechanics - defaults, one-shot, origin, key filtering - and bad at business logic, which becomes unreviewable and untestable in a terse modifier.
- What is the risk of stacking several declarations on one binding?The order in which they are evaluated, and how they interact, is defined by the framework rather than by intuition, so the combined behaviour is not portable and is easy to misread. If the combination needs explaining, put the logic in the handler where it can be named and tested.
saying these in an interview costs you the question
- Calls binding declarations pure shorthand with no behavioural difference
- Puts a business condition in a terse binding declaration instead of the handler
- Assumes declarations combine in the same order in every framework
- Believes a filtered-out event still invokes the handler
- Expects a registration-time option to be selectable from inside the handler
- Forgets that a silently dropped event leaves nothing to diagnose