In the documentation at: How to enable inline editing in Vaadin Grid it shows an example of inline editing on the grid with an Edit button which is exactly what I want. The only thing is that it uses Button components which this page in the user manual: Using renderers in the Vaadin Grid component (the Inline Editing tab vs the Renderers tab in the Grid documentation) suggests that using components for a larger number of rows can have performance consequences and has an example using a Lit Renderer.
Is it as simple as putting all the same event code to the withFunction() method? Do I need to do anything special? Is the example with the Edit button using the Button component just to keep things simple and that’s why it’s not using the LitRenderer although we probably almost always want to use that instead of the button component?
Also how does that work for removing the Edit button and flipping it for a Save button as well as a small cancel (x) button? Is that handled in the LitRenderer? Is there sample code for how to do that anywhere?
On a somewhat related note I’m using a theme variant on the buttons, specifically ButtonVariant.LUMO_SMALL, along with some additional custom css styling. Is there an easy way to apply the same style through the LitRenderer?
A single ComponentRenderer column with one or two Button components should not be an issue – performance degradation typically only becomes noticeable in Grids with several such columns, and even more so if the renderer is more complex.
And the warning about ComponentRenderer performance issues is perhaps a bit too pessimistic: in practice each row in your data won’t have its own instance of the component because the Grid’s contents are lazy loaded into the UI.
So, the TL;DR is that you can use ComponentRenderer for this.
If you do want to use a LitRenderer, I think the best way to handle the switch from an Edit button to a Save + Cancel button pair is to include all 3 buttons in the Lit template and switch their availability through a property set through .withProperty, but I couldn’t find an example anywhere.
Although it’s lazy loaded I can see someone with a large list of data scrolling to the bottom to get something which would could have an impact.
I’m currently using buttons but I have noticed it’s slightly slower for bigger lists. Even if it’s lazy loading it is slower. I’m working on improving this.
That being said yeah I couldn’t find an easy example to work from. I’m not that familiar with LitRenderer and although it seems simple there’s a lot of moving parts to keep track of. From hiding things, triggering the editor, and so on. But it’s more the GUI side on the LitRenderer, specifically from keeping track of the visibility state and so on. A big benefit of Vaadin is to keep as much code as possible in Java.
Yeah, this is one of those cases that really needs to be on the clientside to be lightweight, which makes a java-only solution difficult.
One thing you can do with ComponentRenderer is to use native html buttons instead of the Vaadin Button component: there’s the NativeButton class in Flow. (And using a Div instead of a HorizontalLayout for wrapping the two edit-mode buttons.)
Before jumping into optimisations, I’d suggest to first figure out why it is slow (profiling in browser and JVM). Right cure depends heavily on that. As suggested by Rolf, the issue CAN be a heavy web component (in which case LitRenderer don’t help at all) or it can be some initialization in the backend (like slow DB query).