Almost every admin screen in Magento 2 - the product grid, customer management, the order overview, and most edit forms - is built on the same framework: UI Components. Anyone building their own admin areas can't avoid it. This series covers it from the ground up: from the first empty table to custom renderers, inline edit, and export - demonstrated through a continuous testimonials management project starting in block 4.

Two different worlds: storefront and admin

In this project, Hyvä fully replaces KnockoutJS and UI Components on the storefront (see the Hyvä tutorial series) - that does not apply to the admin area. The backend still regularly uses UI Components with KnockoutJS templates, exactly like Magento core itself. That's not a contradiction: Hyvä is a frontend theme replacement, not an admin alternative. For admin grids and forms, UI Components simply remains the standard way - and that's a good thing, because it's a powerful, declarative framework.

The two main building blocks: listing and form

UI Components is an umbrella term for a whole family of components, but in day-to-day admin work you'll almost exclusively encounter two variants:

• Listing (grid) - a tabular overview with columns, filters, sorting, pagination, and mass actions. Declared in a {name}_listing.xml file.
• Form - an edit form with fieldsets, fields, validation, and a save button. Declared in a {name}_form.xml file.

Both live under view/adminhtml/ui_component/ in the respective module, both are wired into a controller page through a regular Layout XML file (view/adminhtml/layout/), and both follow the same basic structure: a PHP class supplies the data (the DataProvider), the XML file describes structure and presentation, and in the browser JavaScript (KnockoutJS templates plus a uiComponent registry) handles the actual rendering and interactivity.

The data flow at a glance

Roughly, for a grid it works like this: the controller calls the Layout XML, which includes a uiComponent named after the listing file. Magento loads {name}_listing.xml, which references, among other things, a DataProvider class. That class builds a collection, applies filters/sorting from the request, and returns the data as an array. The array gets serialized to JSON and handed to the JavaScript side, where KnockoutJS templates (from the Magento_Ui module) render the actual table from it - including the filter bar, pagination, and the mass action dropdown.

For a form the flow is nearly identical, except the DataProvider class returns exactly one record (keyed by request_field_name, usually the ID from the URL) instead of a list, and the XML file describes fieldsets and fields instead of columns.

the xml file as a contract

An important mental model for getting started: the XML file isn't a pure configuration format, it's a contract between PHP and JavaScript. Every <item> element with a component attribute references a RequireJS module (for example Magento_Ui/js/grid/columns/date for a date column). The PHP side only supplies raw data - what that raw data looks like once rendered (date format, dropdown options, image preview) is decided by the JavaScript component referenced in the XML.

Why this framework - and not a custom solution?

You could theoretically build every admin screen with a classic block plus a custom template and controller. The reason UI Components still pays off: filters, sorting, pagination, mass actions, confirmation dialogs, inline validation, and export are already implemented and tested - you declare them instead of writing them from scratch. The price is a certain ramp-up time on the XML structure and PHP base classes, which this tutorial breaks down systematically.

An honest look: ViewModels vs. UI Components classes

This project's coding conventions prefer ViewModels (ArgumentInterface) over classic block classes, because ViewModels cleanly separate pure data supply from presentation logic. That only applies in a limited way to UI Components: DataProvider, Column, Modifier, and Button classes must each implement a fixed Magento base class or interface (AbstractDataProvider, Column, ModifierInterface, ButtonProviderInterface), because the UI Components framework calls them through exactly those contracts. An ArgumentInterface ViewModel doesn't architecturally fit here - the framework enforces its own conventions. Wherever one of these classes needs additional, reusable business logic, this series still extracts that logic into a separate, injectable service object - the UI Components class itself stays a thin adapter to the framework.

What this series builds

The first three blocks build grid and form fundamentals on a simple practice module (Mironsoft\Announcement, announcements). Starting in block 4, a complete, standalone admin module for testimonials (Mironsoft\Testimonial) emerges - with its own database table, grid, form with image upload, delete controller, and store-view visibility. Block 5 extends that same module with advanced techniques, and block 6 wraps up with ACL details, troubleshooting, and a cheat sheet.