Magento 2: what are the benefits of using UI grid components over the standard Grid.php?
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.
@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.