You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The GridPro currently only supports Text, Select and Checkbox fields as well as custom server-side components.
The disadvantage of the custom server-side components is, that the correct value is only shown after a roundtrip (see vaadin/web-components#2550).
As stated in a comment to this issue, probably the best way to support all custom editors would be to support custom webcomponents.
This would probably also solve the column type missing issues (vaadin/web-components#1037, vaadin/web-components#1052, vaadin/web-components#1104) as they should then be relatively simple to implement (vaadin-grid-pro-edit-text-field is just a vaadin-text-field with some custom styles).
Describe the solution you'd like
I would like to be able to set a custom webcomponent, maybe the html-tag would be enough.
The custom webcomponent ofc needs to fullfill a specific interface (needs to have a property value and a value-changed event).
Additionally it would be cool, if server-side components are supported as well, while still using the client-side api of the underlying webcomponent. That way, it would be possible to have server-side logic for the component, while the value would still be updated without a server roundtrip.
Describe alternatives you've considered
I've tried using the server-side custom component. Unfortunately they are limited to AbstractField at the moment (see #3023) and as mentioned earlier, the value of the editor is updated only after a server roundtrip.
I've also considered is to use the normal inline editing of the Grid. Unfortunately the editor is only activated after a server roundtrip, which drastically decreases the productivity of our users.
Another possible solution I tried was to use editor components to render the cells of the Grid, so that every (eitable) cell is an editor by default. We are using our own data binding so this solution would technically be possible. Unfortunately using ComponentRenderer for all cells drastically decreases the performance of the Grid and the LitRenderer API can't be used for all components we need as withFunction does not support return values.
The text was updated successfully, but these errors were encountered:
Describe your motivation
The
GridPro
currently only supportsText
,Select
andCheckbox
fields as well as custom server-side components.The disadvantage of the custom server-side components is, that the correct value is only shown after a roundtrip (see vaadin/web-components#2550).
As stated in a comment to this issue, probably the best way to support all custom editors would be to support custom webcomponents.
This would probably also solve the
column type missing
issues (vaadin/web-components#1037, vaadin/web-components#1052, vaadin/web-components#1104) as they should then be relatively simple to implement (vaadin-grid-pro-edit-text-field
is just avaadin-text-field
with some custom styles).Describe the solution you'd like
I would like to be able to set a custom webcomponent, maybe the html-tag would be enough.
The custom webcomponent ofc needs to fullfill a specific interface (needs to have a property
value
and avalue-changed
event).Additionally it would be cool, if server-side components are supported as well, while still using the client-side api of the underlying webcomponent. That way, it would be possible to have server-side logic for the component, while the value would still be updated without a server roundtrip.
Describe alternatives you've considered
I've tried using the server-side custom component. Unfortunately they are limited to
AbstractField
at the moment (see #3023) and as mentioned earlier, the value of the editor is updated only after a server roundtrip.I've also considered is to use the normal inline editing of the
Grid
. Unfortunately the editor is only activated after a server roundtrip, which drastically decreases the productivity of our users.Another possible solution I tried was to use editor components to render the cells of the
Grid
, so that every (eitable) cell is an editor by default. We are using our own data binding so this solution would technically be possible. Unfortunately usingComponentRenderer
for all cells drastically decreases the performance of theGrid
and theLitRenderer
API can't be used for all components we need aswithFunction
does not support return values.The text was updated successfully, but these errors were encountered: