The middle path SAPUI5 developers were missing
For years, Fiori Elements gave you two choices: a standard floorplan as-is, or full freestyle hand-built. The middle ground — "I want the standard table, but with my own section below it" — was painful.
Building blocks are that middle ground: reusable, annotation-driven UI components (tables, filter bars, charts, forms) you drop into custom pages and sections — without abandoning the Fiori Elements programming model.
With 1.142 adding the ConditionalSwitch block and the Fiori development portal putting blocks front and center, this is the direction SAP is betting on.
The blocks you'll actually use
Table block
The workhorse — OData-bound table with sorting, filtering, personalization from annotations. Since 1.142 the framework picks a sensible default table type for you. Learn one block, learn this one.
Filter bar block
Annotation-driven filter bar with value helps, date ranges, variant management. Drop it above a table block: list-report-style header in minutes.
Chart block
Analytical charts bound to OData. Pair with the filter bar block and the chart filters along automatically.
Form and field blocks
Object-page-style sections: labels, values, and edit controls from annotations — including the custom message strips from 1.142.
ConditionalSwitch block (new in 1.142)
Declaratively switch UI content based on conditions. The canonical case: status-dependent sections or role-based content, without setVisible spaghetti.
Blocks vs floorplan vs freestyle
- Standard floorplan covers 90%? → Floorplan. Don't be clever.
- Floorplan + custom sections? → Building blocks. Keep annotations, draft handling, Fiori semantics for free.
- Truly custom UI, no OData V4 semantics? → Freestyle.
The classic mistake: going freestyle for "one custom section," then re-implementing draft handling, message handling, and navigation by hand. Blocks exist so you don't.
Adding a block to a custom section
Declare the block in your XML view or fragment, point it at your OData V4 model and entity set, let annotations drive the rest:
<fe:TableBlock
entitySet="SalesOrders"
selectionMode="Single"
personalization="Sort,Filter" />Namespace and attributes vary per block — the Fiori development portal shows each with a live preview and copy-paste snippets. Fastest way to get the syntax right.
Practical tips
- Annotations first. Blocks are only as good as your annotations — invest in
UI.LineItem,UI.SelectionFields,UI.Chart. - Mock data early. Blocks + local OData mocking = fast iteration without backend round-trips.
- Compose, don't nest cleverly. Filter bar + table + chart covers an enormous number of real requirements.
- Check the portal before hand-rolling. SAP keeps adding blocks.
Building blocks are the most important Fiori Elements concept of the last two years — and most teams still underuse them. Your future self, maintaining half the custom code, will be grateful.
Questions on a specific block? Tell me which one in the comments.