Version 2

[bogdan]

Major Changes

1. Support Ruby open end Range for range: true filters
2. Modern modular CSS class names
3. Use HTML5 input types: date, datetime-local, number
4. Enhanced built-in partials for maximum customization of the UI

Backward compatibility

Version-2 is has some breaking changes to ensure best implementation of modern technologies in the gem.

Migration Guide

TODO

[X] Integrate into datagrid-demo
[X] Integrate into 7F app
[ ] Update wiki

Fixes #325.

[bogdan]

Good idea.
We may support everything with tag_options option (similar to input_options and label_options for filter):

column(:all, tag_options: {class: 'no-sort', "data-no-sort": true,  ...}, ...)

I prefer this for later release as this one is already big, but we can include it here if you think it facilitates migration.

[bogdan]

Regarding the deprecation of datagrid_order_for method

Wow, that is so weird that you used everything custom in the view except for the order. I tried to come up of an alternative way for you to do it, but didn't find anything better.

datagrid_order_for has some problems now as it will render order controls even for column that doesn't support order because this check in V1 happens outside of helper (definitely a datagrid design issue):

https://github.com/bogdan/datagrid/blob/v1.8.4/app/views/datagrid/_head.html.erb#L5

Also it accepts the Column object but not a name as String/Symbol which makes it inconvenient to use directly.

We can introduce a different helper datagrid_order that renders different partial app/views/datagrid/order instead of order_for while keeping datagrid_order_for with related view deprecated.

However, think the ideal way to fix this would be for apps to implement datagrid_order helper in their ApplicationHelper and extract a part of app/views/datagrid/head in the way they need.

What do you think?

[zhuravel]

@bogdan No problem, I’ll implement datagrid_order_for in our helper. Just wanted you to know that this method has specific use case and other power users might also have this case when building complex table headers.

[zhuravel]

Looks good to me. I have a pull request ready in Talkable with all tests passing, and plan to move it to QA next week.

[bogdan]

@zhuravel I found out that introducing tag_options instead of column[class] can not be done without backward incompatibility, so we have to do it in the PR.

The problem I wasn't able to solve is the merge of class attribute. In current implementation, using tag_options: {class: "my-class"} would cause the override of datagrid-order-active-asc/desc classes. That is not easily solvable as class maybe specified as String, Hash or Array. I didn't find universal utility to merge two class options of tag.whatever.

https://github.com/bogdan/datagrid/blob/version-2/app/views/datagrid/_head.html.erb#L7

[zhuravel]

@bogdan

That is not easily solvable as class maybe specified as String, Hash or Array.

You might try to delegate that to class_names method added in Rails 6.1:
https://www.bigbinary.com/blog/rails-6-1-introduces-class_names-helper
Source: https://github.com/rails/rails/blob/dd8f7185faeca6ee968a6e9367f6d8601a83b8db/actionview/lib/action_view/helpers/tag_helper.rb#L527-L543

Either way no problem, I’ll migrate to only use tag_options.