Improvement: split grid.phtml

[wigman]

The grid.phtml file would ideally be split into a few phtml files, loaded via layout xml.

basically for each container (nav/filters, table), JS, and for each table part.

[Vinai]

I was wondering about this, too. Often the features interleave, for example, when massactions are defined, the extra column at the beginning needs to be rendered for the table header, too. Or when filters are applied, the reset button needs to be rendered above the grid. It is a rather large template, but would it really make things simpler to split it?

A large template can be split into smaller ones for a number of reasons, e.g. maintainability, reusability and customizability..

In this case maintainability would probably be the main driving force. Do you agree? I expect the template to stabilize in a few releases so that changes to it are required less and less.

[wigman]

Absolutely, but also for extensibility.

[adamkarnowka]

Hello - I think additional containers in specific places would increase extendibility with keeping maintainability intact. For example - if I want to add some button (f.e Add button) near Display button, I could be able to define new block and template for this area via XML update - currently I cannot see option to add buttons for grid, right?

Thanks for great work!

[Vinai]

@adamkarnowka Thank you for your input. You are right, currently there is no way to add buttons inside the grid.

I've been pondering the issue of extensibility. Because simplicity is a main design goal of the grid module, I don't want users to be able to declare only the grid block in layout XML and that should be enough. In order to add containers that can be addressed in layout XML, the whole grid would need to be declared as a layout XML data structure.

there are some ways to work around this, but all the ones I can think of are rather hacky and not simple from a developers point of view. It would require knowing layout XML and the grid module internals to be able to know them, e.g. naming conventions and such.

Buttons are definitely lacking. I'll add them very soon, hopefully today, but definitely by the end of the week.

Besides buttons, the main use case for containers I can come up with would be additional filter-like things, e.g. a full-text search input field that searches over multiple fields, or a dropdown to select the store or website scope for grid content or such (custom filters for individual fields still will need to evolve a bit over time, too).

For those use cases I could add an explicit contianer, but it would probably not be addressed via layout XML, but instead would need to be declared in the grid XML. It would require

• block name (required)
• block class (optional)
• block template (required)
• view models (optional, with name and class)

If you can think of other use cases where containers would be needed, please let me know.

The overall goal is to provide a tool that can be used in about 95% of all cases. It will always be possible to create custom grids from scratch in the remaining 5%.

[Vinai]

@adamkarnowka FYI I've added grid buttons, they still need styling so they haven't been merged just yet.

[adamkarnowka]

Thanks!

I totally see your point about simplicity of grid xml. Some other elements that might be needed for grids:

• message/alert above grid ("Cron is not running so data might be not updated") - this can be resolved by global messages, but still could be useful for grid
• dropdowns or buttons for exporting (csv/xml/xls)

I am currently building new extension which will use hyva-grids heavily so as work progresses, there will probably come some new ideas. And I've just took crashcourse with tailwind/alpine - seems like really nice way to build rich and interactive interfaces, with minimal effort / FE experience.

The overall goal is to provide a tool that can be used in about 95% of all cases. It will always be possible to create custom grids from scratch in the remaining 5%.

AMEN!

[Vinai]

I am currently building new extension which will use hyva-grids heavily so as work progresses, there will probably come some new ideas.

Looking forward to hearing them very much!

[Vinai]

@adamkarnowka FYI because you mentioned them, button support is in the just released 1.0.6.

[adamkarnowka]

Thanks, works like a charm! One suggestion / idea I'd have is the option to specify block class together with template. That would allow to create totally custom elements containing some logic, for example - custom dropdown for "Add new..." button (available options depend on settings):

With this change, you'd already have more powerful system of buttons (well, elements) than Magento while keeping it much simpler.

Regards, Adam

[adamkarnowka]

One more thing - if you're fine with it I can prepare PR with this change, should be quite easy as I can see.

Regards Adam

[Vinai]

@adamkarnowka Thanks for your offer to make a PR! Because the core deprecated custom blocks, it might be better to add a child element to add viewModels. They can provide any data or contain custom logic like blocks.

<button id="add" url="*/*/add"/ template="My_Module::my-button.phtml">
    <viewModel name="button_data" class="\My\Module\ViewModel\ButtonData"/>
</button>

They could then be automatically assigned as a template variable or maybe retrieved from the block like regular view models ($viewModel = $block->getData('button_data')).

Would that work for you?