Vaadin-grid: Convenience <vaadin-grid-column> properties

[tomivirkki]

Add the following properties to <vaadin-grid-simple-column> for convenient configuration:

• path="name.first"
  
  
  
  • No need to provide a body-template, grid should use a default one that renders the path value as a String)
  
  
  • No need to provide a header-template, grid generates a default header label (in this case "First")
  
  
• label="First Name"
  
  
  
  • No need to provide a header-template, the label String is used
  
  
• sortable
  
  
  
  • No need to provide a vaadin-grid-sorter, the value is used as the path for a default sorter (if empty, use the path attribute/property if defined)
  
  
• filterable
  
  
  
  • No need to provide a vaadin-grid-filter, the value is used as the path for a default filter
  
  

[platosha]

It would be nicer to keep bare column as it is, and have these convenience APIs in a separate element, <vaadin-grid-simple-column> for example.

Would suggest to add these properties as well:

• expandable
  
  
  
  • No need to use <vaadin-grid-hierarchy-toggle> in the template and maintain its bindings
  
  
• editable
  
  
  
  • Same for making editable inputs for body rows
  
  
• text-align="start|center|end"
  
  
  
  • Specifies horizontal alignment, same alignment applies to header, footer, and body at the same time. Very handy to get columns wit humbers nicely right-aligned, for example.
  
  
• text-overflow="hidden|wrap|ellipsis"
  
  
  
  • Specifies behavior for text content that does not fit in a cell.
  
  

[tomivirkki]

Early prototype: https://jsfiddle.net/zLxncvb1/

This enhancement will reduce boilerplate code and ease adoption in frameworks where having to define the <template> elements for columns might be an issue.

[jouni]

text-overflow="hidden|wrap|ellipsis"

I’m a bit hesitant to add “ellipsis” there. I at least opted against that in Valo, and instead, use a gradient mask to fade out the overflowing content. Ellipsis truncation doesn’t work nicely with flex container, which the cell content container is.

[gilberto-torrezan]

Flow feedback here: YES PLEASE

Flow will always use vaadin-grid-simple-column if you decide to split it to a separate component.

Also make sure those properties can be changed at runtime - after the Grid is attached and rendered. We have the use case where it's possible to toggle a column to be sortable on/off for example.

[jouni]

Flow will always use vaadin-grid-simple-column if you decide to split it to a separate component.

I suppose you have to use a regular column when you want to put other than text content in the cell/column. Or would the simple column still support custom templates that just override the default, @tomivirkki?

[tomivirkki]

Yes, the proto implementation supports custom templates also.

[jouni]

Is the same true for the header template as well? Would there be any need to have a separate element for this then – can’t we just add the conveniences/helpers directly to <vaadin-grid-column>?

[tomivirkki]

That was the original plan in this ticket. But since the suggested features are higher level abstractions on top of the core functionality we ended up with this option. Also, since we have a separate vaadin-grid-selection-column (that also provides some utils on top of the core features), we thought these two should probably be aligned.

[jouni]

I trust your judgment.

My intuition says that the selection column is a specialized column, whereas the “simple” column is a regular column with a simpler API. You use the simple column for the same purpose as the normal column. I’m possibly fixated in some idea in my head right how, and will convert to your thinking again later :)

[tomivirkki]

This isn't set in stone yet, we can discuss this more in detail before starting.

[tomivirkki]

@platosha What do you think about including these features to <vaadin-grid-column> directly, considering https://github.com/vaadin/vaadin-grid/issues/492#issuecomment-343436557

BTW: There's a working implementation of <vaadin-grid-simple-column> at https://github.com/vaadin/vaadin-grid/tree/simple-column

[platosha]

Aside from naming issue, I was thinking that would be nice to have these features opt-in, or at least have opt-out possible. Any feature comes with a price of increased code size, DOM template size, and so on. This is essentially why I would prefer <vaadin-grid-simple-column> to be a different element from <vaadin-grid-column>.

Another possible option is to add these convenience features to <vaadin-grid-column> directly, and also add something like <vaadin-grid-basic-column> for what <vaadin-grid-column> is now, to make opt-out possible.

[Peppe]

I agree with Jouni. What you are able to do with simple column feels like the default that I most of the time would like to do. Then in the special cases which are more complex, I'd use the regular component. How much bigger would the regular column become if the path logic would be integrated into it? The code at least doesn't look so extensive in LOC.

The pull request with simple also shows how much easier all the examples have become and speaks for why this is important. https://github.com/vaadin/vaadin-grid/commit/15b5d3d36ff734f4c6474dcb6476281963f75726

[jouni]

Make common things simple, and more complex things possible.

I’m leaning towards opt-out, but I’m a bit worried about making the less-performant option the default one (if there is a significant difference).

[tomivirkki]

Decided to go with convenience properties for the <vaadin-grid-column> element. Including the ones implemented in the prototype and additionally text-align. Any added <template> or renderer should override stuff configured with these properties

[tomivirkki]

Just to clarify, this will cause <vaadin-grid-sorter>, <vaadin-grid-filter> (including <vaadin-text-field>) and <vaadin-grid-tree-toggle> to get imported automatically with every grid.

[tomivirkki]

...to mitigate this we could ship <vaadin-grid-bare-column> or similar with these new features excluded

[tomivirkki]

Just realized, though, that <vaadin-grid-column> gets imported automatically (for some reason) :/ We can't change this without a major bump so a <vaadin-grid-bare-column> wouldn't really do much while <vaadin-grid-column> gets imported anyway. Maybe we'll need to reconsider the additional convenience column after all.

[tomivirkki]

One plausible option would be to

• include path, label and text-align to <vaadin-grid-column>
• and create a separate convenience column for the properties that require more imports: sortable, filterable and expandable

[Legioth]

What's the actual impact in gzipped kilobytes to download if the advanced functionality is imported by default?

[Legioth]

The problem with always importing <vaadin-grid-column> could be solved by splitting up the current vaadin-grid.html and introducing a new vaadin-grid-bare.html import or similar to be used by those who only want to use <vaadin-grid-bare-column> but not get the extra download size from using <vaadin-grid-column>.

[tomivirkki]

What's the actual impact in gzipped kilobytes to download if the advanced functionality is imported by default?

Haven't checked but they're not auto-imported currently because of the same reason.

The problem with always importing could be solved by splitting up the current vaadin-grid.html and introducing a new vaadin-grid-bare.html import or similar to be used by those who only want to use but not get the extra download size from using .

https://github.com/vaadin/vaadin-grid/issues/492#issuecomment-416594755

[jouni]

Tomi, grid-bare != grid-bare-column (if I understood Leif correctly).

[tomivirkki]

Sorry, was too hasty with this. Hmmm....maybe...providing a separate -bare version of the whole grid just to avoid auto-import of -column sounds a bit overkill however. We'd probably want to consider carefully all the things we'd want to exclude from the bare grid (not just the column auto-import). That would expand the scope of delivering these convenience features quite a bit.

[Legioth]

Out of the current list of imports, is there anything except vaadin-grid-column that could be excluded? Almost all the others are mixins.

https://github.com/vaadin/vaadin-grid/blob/264aa514b55afe7704200b3b81d6b5807dd6fd42/src/vaadin-grid.html#L7-L26

[tomivirkki]

Perhaps some of the mixins. Data provider mixin could be included in the bare version while array data provider (which builds on top of data provider) could be shipped with <vaadin-grid> only. Also filter & sorter mixins only bring extra value if filter/sorter helpers are imported and could thus be excluded from grid-bare.

[Legioth]

Wouldn't including different mixins also mean that there would have to be two different custom element classes registered with different tag names?

[tomivirkki]

Postponed filterable and expandable convenience properties. Different kind of combinations of sortable, filterable, selectable, expandable, editable would need to be quite opinionated API- and design-wise so we'll revisit these later if necessary.

As sorting is quite a common use-case however and it wouldn't really require additional design, decided to ship a separate <vaadin-grid-sorter-column>. It will also nicely align with -selection-column.