Magento 2: what are the benefits of using UI grid components over the standard Grid.php?

Question

So Magento 2 introduced the UI Components.

One of them is the UI Component Grid (you can find more information about it here: Explanation of UI Component Grid in Magento 2)

When creating a custom module, I sticked to the old Magento 1 method, I've created a Grid.php file that handles my adminhtml grid.

I'm wondering what are the benefits of using the UI components grid instead of the Grid.php method ?

Answer 1

I will list the ones I found so far.

• extensibility. You can add a new xml in order to add new columns.
• configuration over code. Less code for logic, more declarative xmls.
• less traffic over the network. The xml is transformed into a json and sent to the browser. Also each field type is sent only once to the browser and the form generation happens on the client.
• the new system allows column reordering and state saving.

Off topic: I got "inside info" that the plan is to move all the grids and forms to UI components. So you should start using them.

Answer 2

@raphael-at-digital-pianism asked me to post this list of things I think are wrong with the adminhtml grid UI component XML, so here goes:

What is wrong with adminhtml grid UI component XML?

• Slow feedback cycle during dev
• Hard to understand
• Hard to debug if something goes wrong (mostly only by comparing to XML in core)
• Much implementation detail exposed
• Encourages copy and paste
• XML was not meant for humans to read and write
• Hard to test
• Not clear what other options are available
• Lots of boilerplate AND magic (worst of both worlds)
• Coupled to the idea of displaying DB table data
• Lots of duplicated name strings in the file

"Come up with a better solution" you say?

Well, I haven't. But here is a rough idea how I, as a developer, would like to be able to create adminhtml grids and forms.

• Create an implementation of GridDataSourceInterface
• The grid component uses a GridDataSourceInterface::getGridItemType() method to fetch a class name or interface name
• The interface is reflected upon and all getters are used to determine the possible columns
• Column types are inferred from the return types
• Types that can't be automatically inferred as valid column types are ignored.
• The GridDataSourceInterface implementation instance can be used to configure non-default visibility and column types using nice descriptive methods where needed.

The benefits:

• IDE assisted definition of grids (and forms) through method autocompletion
• Sensible defaults
• Implementation agnostic
• For simple entities only very little code would need to be written
• Compared to the XML approach, no loss of features
• Extendability via interceptors
• If the class interfaces are done defining grids and forms can also be just as declarative as XML (but much more simple)
• Matches Magento 2s "way-of-thinking" for service contract classes
• No change to current interaction with the frontend code required (same traffic over the wire)
• Frontend column sorting and configuration can continue to work just as it does now
• NO MOAR XML

Regarding the original question, I don't think that using the old, Magento 1 style, blocks to build adminhtml interfaces it the right thing to do.
I'm only advocating the new XML based grid declaration should be replaced by something better as quickly as possible.