23

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 ?

23

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.

  • Not so off topic that's a great info, exactly the kind of feedback I need – Raphael at Digital Pianism May 4 '16 at 11:59
  • @Raphael you can save bookmarks by ui_component. Configuration via xml More details you can see in ui_bookmark table – mrtuvn May 5 '16 at 9:30
22

@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.

  • that is true that difficult to understand UI component.Are you thought magento will come with another solution on UI grid component i future?.It become head Cache to me.......Donot find any proper blog (: – Amit Bera Nov 17 '17 at 22:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.