Vì vậy, Magento 2 đã giới thiệu các Thành phần UI.

Một trong số đó là Lưới thành phần UI (bạn có thể tìm thêm thông tin về nó ở đây: Giải thích về lưới thành phần UI trong Magento 2 )

Khi tạo một mô-đun tùy chỉnh, tôi đã sử dụng phương pháp Magento 1 cũ, tôi đã tạo một Grid.phptệp xử lý lưới adminhtml của mình.

Tôi đang tự hỏi những lợi ích của việc sử dụng lưới các thành phần UI thay vì Grid.phpphương thức là gì?

Tôi sẽ liệt kê những cái tôi tìm thấy cho đến nay.

• mở rộng. Bạn có thể thêm xml mới để thêm cột mới.
• cấu hình qua mã. Ít mã hơn cho logic, xmls khai báo nhiều hơn.
• lưu lượng truy cập ít hơn qua mạng. Xml được chuyển thành json và gửi đến trình duyệt. Ngoài ra, mỗi loại trường chỉ được gửi một lần đến trình duyệt và việc tạo biểu mẫu xảy ra trên máy khách.
• hệ thống mới cho phép sắp xếp lại cột và tiết kiệm trạng thái.

Chủ đề ngoài lề: Tôi đã nhận được "thông tin bên trong" rằng kế hoạch là chuyển tất cả các lưới và biểu mẫu sang các thành phần UI. Vì vậy, bạn nên bắt đầu sử dụng chúng.

@ raphael-at-digital-pianism đã yêu cầu tôi đăng danh sách này những điều tôi cho là sai với thành phần UI của lưới UI adminhtml, vì vậy hãy vào đây:

Có gì sai với XML thành phần UI UI adminhtml?

• Chu kỳ phản hồi chậm trong quá trình phát triển
• Khó hiểu
• Khó gỡ lỗi nếu có lỗi xảy ra (chủ yếu chỉ bằng cách so sánh với XML trong lõi)
• Nhiều chi tiết thực hiện tiếp xúc
• Khuyến khích sao chép và dán
• XML không có nghĩa là con người đọc và viết
• Khó kiểm tra
• Không rõ những lựa chọn khác có sẵn
• Rất nhiều nồi hơi VÀ ma thuật (tệ nhất của cả hai thế giới)
• Kết hợp với ý tưởng hiển thị dữ liệu bảng DB
• Rất nhiều chuỗi tên trùng lặp trong tệp

"Hãy đưa ra một giải pháp tốt hơn" bạn nói gì?

Chà, tôi chưa. Nhưng đây là một ý tưởng sơ bộ về cách tôi, với tư cách là một nhà phát triển, muốn có thể tạo các lưới và biểu mẫu adminhtml.

• Tạo ra một thực hiện GridDataSourceInterface
• Thành phần lưới sử dụng một GridDataSourceInterface::getGridItemType()phương thức để tìm nạp tên lớp hoặc tên giao diện
• Giao diện được phản ánh và tất cả các getters được sử dụng để xác định các cột có thể
• Các kiểu cột được suy ra từ các kiểu trả về
• Các loại không thể tự động suy ra là các loại cột hợp lệ được bỏ qua.
• Các GridDataSourceInterfaceví dụ thực hiện có thể được sử dụng để tầm nhìn và cột loại cấu hình mặc định không sử dụng phương pháp mô tả đẹp khi cần thiết.

Những lợi ích:

• IDE hỗ trợ định nghĩa lưới (và biểu mẫu) thông qua tự động hoàn thành phương thức
• Mặc định hợp lý
• Thực hiện bất khả tri
• Đối với các thực thể đơn giản, chỉ cần viết rất ít mã
• So với cách tiếp cận XML, không mất tính năng
• Khả năng mở rộng thông qua đánh chặn
• Nếu các giao diện lớp được hoàn thành, việc xác định các lưới và các biểu mẫu cũng có thể giống như khai báo như XML (nhưng đơn giản hơn nhiều)
• Phù hợp với "cách suy nghĩ" của Magento 2 cho các lớp hợp đồng dịch vụ
• Không có thay đổi đối với tương tác hiện tại với mã frontend được yêu cầu (cùng lưu lượng truy cập qua dây)
• Cấu hình và sắp xếp cột Frontend có thể tiếp tục hoạt động như hiện tại
• KHÔNG CÓ XML NHẤT

Về câu hỏi ban đầu, tôi không nghĩ rằng việc sử dụng kiểu cũ, Magento 1, các khối để xây dựng giao diện adminhtml là điều nên làm.
Tôi chỉ ủng hộ việc khai báo lưới dựa trên XML mới nên được thay thế bằng một cái gì đó tốt hơn càng nhanh càng tốt.