Entonces Magento 2 introdujo los componentes de la interfaz de usuario.

Una de ellas es la cuadrícula de componentes de la interfaz de usuario (puede encontrar más información al respecto aquí: Explicación de la cuadrícula de componentes de la interfaz de usuario en Magento 2 )

Al crear un módulo personalizado, me quedé con el antiguo método Magento 1, creé un Grid.phparchivo que maneja mi grilla adminhtml.

Me pregunto cuáles son los beneficios de usar la cuadrícula de componentes de la interfaz de usuario en lugar del Grid.phpmétodo.

Voy a enumerar los que encontré hasta ahora.

• extensibilidad. Puede agregar un nuevo xml para agregar nuevas columnas.
• configuración sobre código. Menos código para la lógica, más xmls declarativos.
• Menos tráfico en la red. El xml se transforma en un json y se envía al navegador. Además, cada tipo de campo se envía una sola vez al navegador y la generación del formulario ocurre en el cliente.
• El nuevo sistema permite el reordenamiento de columnas y el ahorro de estado.

Fuera del tema: obtuve "información privilegiada" de que el plan es mover todas las cuadrículas y formularios a los componentes de la interfaz de usuario. Entonces deberías comenzar a usarlos.

@ raphael-at-digital-pianism me pidió que publicara esta lista de cosas que creo que están mal con el XML del componente de la interfaz de usuario de la cuadrícula adminhtml, así que aquí va:

¿Qué tiene de malo el componente XML de componente de interfaz de usuario adminhtml?

• Ciclo de retroalimentación lento durante el desarrollo
• Difícil de entender
• Difícil de depurar si algo sale mal (principalmente solo comparando con XML en el núcleo)
• Muchos detalles de implementación expuestos
• Fomenta copiar y pegar
• XML no fue diseñado para que los humanos lean y escriban
• Difícil de probar
• No está claro qué otras opciones están disponibles.
• Un montón de repeticiones Y magia (lo peor de ambos mundos)
• Junto con la idea de mostrar datos de la tabla DB
• Muchas cadenas de nombres duplicados en el archivo

"¿Se te ocurre una solución mejor", dices?

Pues no. Pero aquí hay una idea aproximada de cómo, como desarrollador, me gustaría poder crear cuadrículas y formularios adminhtml.

• Crear una implementación de GridDataSourceInterface
• El componente de cuadrícula utiliza un GridDataSourceInterface::getGridItemType()método para obtener un nombre de clase o nombre de interfaz
• La interfaz se refleja y todos los captadores se utilizan para determinar las posibles columnas.
• Los tipos de columna se infieren de los tipos de retorno
• Los tipos que no se pueden inferir automáticamente como tipos de columna válidos se ignoran.
• La GridDataSourceInterfaceinstancia de implementación se puede usar para configurar tipos de columna y visibilidad no predeterminados utilizando métodos descriptivos agradables cuando sea necesario.

Los beneficios:

• Definición asistida por IDE de cuadrículas (y formularios) a través del método de autocompletado
• Valores predeterminados sensibles
• Implementación agnóstica
• Para entidades simples, solo se necesitaría escribir muy poco código
• En comparación con el enfoque XML, sin pérdida de características
• Extensibilidad a través de interceptores
• Si las interfaces de clase se realizan, la definición de cuadrículas y formularios también puede ser tan declarativa como XML (pero mucho más simple)
• Coincide con la "forma de pensar" de Magento 2 para las clases de contrato de servicio
• No se requiere ningún cambio en la interacción actual con el código frontend (mismo tráfico por cable)
• La clasificación y configuración de columnas frontend puede continuar funcionando tal como lo hace ahora
• NO MOAR XML

Con respecto a la pregunta original, no creo que usar los viejos bloques de estilo Magento 1 para construir interfaces adminhtml sea lo correcto.
Solo estoy recomendando que la nueva declaración de cuadrícula basada en XML se reemplace por algo mejor lo más rápido posible.