Hi everyone,
While working in Service Studio (Reactive Web), I noticed several standard DOM events available under the Events property section of widgets (like Containers, Inputs, etc.):
onblur
onfocus
onchange
onclick / ondoubleclick
onkeydown
onkeypress
While basic click and change events are straightforward, I’d like to get a clearer understanding of best practices and typical architectural use cases for the others within OutSystems:
Practical Use Cases: What are common real-world scenarios in OutSystems where handling onblur or onfocus on a Container or Input is preferred over built-in validation or OnChange?
Keyboard Events (onkeydown vs. onkeypress vs. onkeyup): When capturing keystrokes (e.g., triggering a search on Enter or closing a modal on Escape), what is the recommended OutSystems pattern to identify which key was pressed?
Performance Considerations: Are there any known performance pitfalls or server/client communication overheads to keep in mind when binding client actions to rapid events like keyboard or focus triggers?
Any documentation links, code snippets, or community insights would be greatly appreciated!
Thanks in advance!
Hi @Mustafa Ahmed ,Please find below link - https://success.outsystems.com/documentation/11/reference/outsystems_language/interfaces/designing_screens/container/https://developer.mozilla.org/en-US/docs/Web/API/Element/keydown_event
Best practices for handling UI events in OutSystems 11
In OutSystems Reactive Web and Traditional Web, events such as onfocus, onblur, onkeydown, and onkeyup are useful when the required behavior depends on how the user interacts with a control, rather than only on the value entered.
My recommendation is to use built-in OutSystems events for standard behavior and JavaScript event handling only when you need finer-grained control over browser interactions. This keeps the application easier to maintain and avoids unnecessary client-server communication.
1. When to use onfocus, onblur, OnChange, and built-in validation
Event / feature
Best use case
Example
React when a control receives focus
Show input instructions or highlight a field
React when the user leaves a control
Validate a completed field or normalize its value
OutSystems OnChange
React when the control value changes
Update dependent UI or initiate a search after editing
Built-in validation
Enforce required fields, formats, and constraints
Required email, date ranges, numeric limits
Container focus/blur
Manage focus-related interactions on a custom component
Focusable custom widget, keyboard navigation, or a composite control
Practical examples
A. onfocus — show contextual help
When a user focuses on a policy number input, display a hint explaining the expected format. Hide or update the hint when focus moves elsewhere.
B. onblur — validate after editing
For a phone number or claim reference, wait until the user leaves the field before running custom validation or formatting. This avoids repeatedly validating incomplete input after every keystroke.
C. OnChange — update dependent content
When a user changes a claim type, update the relevant UI or trigger a client action to retrieve associated options. Remember that OutSystems OnChange behavior depends on the widget and application type; it is not identical to a raw browser input event.
D. Built-in validation — enforce data rules
Use built-in validation for mandatory fields, data types, and standard constraints. Use custom onblur logic for supplementary interactions, not as a replacement for validation at submission time.
Important: a Container does not automatically behave like an Input for focus events. For a generic container, focus handling may require it to be focusable, for example by setting tabindex="0", or by managing focus on a child control. Use the appropriate event target rather than assuming every Container can receive focus.Hope this will help you.
Hi @Deepa Tiwari,
Thank you so much for the detailed explanation and the helpful resources! The breakdown of when to use each event versus built-in validation clarifies a lot.
Your point about containers not being inherently focusable makes complete sense. I was testing these events directly on a Container widget and noticed that events like onfocus, onblur, and keyboard triggers weren't firing as expected, whereas they work seamlessly on Input fields. Setting tabindex="0" or targeting the inputs directly explains exactly why that was happening.
Thanks again for pointing that out—it saved me a lot of debugging time!
Best regards,
Mustafa
Hi
In my experience, the best approach is to use OutSystems' built-in features whenever possible and use DOM events only when you need more specific behavior.
OnFocus: Useful for displaying hints or contextual information when a field becomes active.
OnBlur: Great for validating or formatting a value after the user leaves a field.
OnChange: Best when you need to react to changes in the input value.
Keyboard events: Prefer keydown for actions like triggering a search with Enter or closing a modal with Escape. Use event.key to identify the pressed key, and avoid keypress since it's deprecated.
Regarding performance, client-side UI updates are generally lightweight, but triggering Server Actions or data refreshes on every keystroke can generate unnecessary requests.
One more thing: if you're implementing custom DOM listeners, make sure they're properly removed when no longer needed to avoid duplicate event handlers.
My rule of thumb: use built-in OutSystems functionality first, and custom DOM events when they add real value to the user experience.
Hope this helps!