Front-end Development
What the Front-end Development domain tests
This domain tests UI composition in Reactive Web: blocks, layouts, client-side events, OutSystems UI patterns, CSS, responsiveness, accessibility, and rendering performance.
Core rules
- Compose screens from Blocks. A block exposes input parameters and events; the parent screen handles the event with a client action. This keeps UI reusable without coupling it to one screen.
- Use the OutSystems UI framework's layouts, patterns, and style guide before writing custom CSS. Customize with CSS variables and classes; avoid inline styles that cannot be themed.
- Responsive design uses the grid and breakpoints. Design mobile-first and verify columns, font sizes, and touch targets at each breakpoint.
- Accessibility is part of the definition of done: associate labels with inputs, provide alternative text, keep keyboard order logical, and maintain contrast.
- Client actions run in the browser. Use JavaScript nodes for browser APIs, but keep data access in Data Actions or server actions.
- Performance: paginate or lazy-load long lists, avoid rendering large hidden sections, and keep client variables small.
Worked example
A reusable Rating block takes Value as an input and raises OnChange. The parent screen listens, runs a client action that updates a local variable, and only calls a server action when the user saves. The block uses a CSS class, not an ID, so multiple instances do not collide. Reasoning: input and event contracts make the block reusable; the local variable keeps typing responsive; the server call is deferred until persistence is needed.
Traps
Using duplicate IDs in reusable blocks, putting server-only logic in client actions, hiding accessibility problems with visual-only labels, and fighting the framework with heavy custom CSS instead of using OutSystems UI patterns.