Disabled on click buttons with LitRenderer

Flow
1

Hello !
I’m currently rewriting some ComponentRenderer to LitRenderer for optimization, and I couldn’t find an equivalent for disabledOnClick from Buttons.

I can disable the button on the click event :

LitRenderer.of("""
    <vaadin-button>
    @click='${(e) => {
        e.currentTarget.disabled=true;
        handleClick();
      }
    }'
    </vaadin-button>
""")
.withFunction("handleClick", e -> myFunction(e));

but I don’t know how to re-enable it after my click event is finished.

Adding e.currentTarget.disabled=false; after handleClick(); re-enable the button immediately, and async/await is the same.

Is it possible ? Or do I have to go back to component renderer ?

2

I assume you are inside a grid. Have you tried using refreshItem inside your “myFunction”? This should re-render the respective row and re-enable the button.

3

Indeed, it was inside a Grid. Your answer looks logic to me !
But I tried it, with no sucess, the button is still disabled after refresh.
I’m using a ListDataProvider, I tried refreshItem(item), refreshAll() and even redo the search function that populate the list bound to the ListDataProvider, but the button is still disabled.

Here’s some code, just in case :

  private final List<Student> students = new ArrayList<>();
  private final ListDataProvider<Student> dataProvider = new ListDataProvider<>(students);
...
grid.addColumn(LitRenderer.of("""
    <vaadin-button>
    @click='${(e) => {
        e.currentTarget.disabled = true;
        handleClick();
      }
    }'
    </vaadin-button>
""")
  .withFunction("handleClick", e -> {
    myFunction(e);
    dataProvider.refreshItem(e);
  });

...
@PostConstruct
private void init() {
  grid.setItems(dataProvider);
  
  searchBtn.addClickListener(l -> {
    students.clear();
// search items    
    students.addAll(items);
    dataProvider.refreshAll();
  }
}
4

Hm, I think that might be due to the way how LitRenderer works to be performant.

Sorry, then I have no real alternative atM to the Component Renderer. Maybe someone else has an idea.

What you could do anyways would be to file an issue in the Vaadin Flow Components Github regarding this issue. Seems not like a very uncommon use case to me.

2 Likes
5

The performance drawback with Component Renderer is not major, especially when your rendered content starts to have logic requirments like in your case, it is viable option. I would even recommend to implement your views using Component Renderer approach first and optimize them with LitRenderer in case you must achieve some performance gains based on actual findings when the application is being used. I.e. do not do premature optimization.

Having said that, if you need to apply complex logic in your LitRenderer, the next step is to implement custom web component, which encapsulates the logic in some manner, and use the component in the LitRenderer. I do not have example with the same use case as your, but I have one demo application with this approach here: rich-tooltip-demo/src/main/java/com/example/tooltip/views/masterdetail/MasterDetailView.java at main · TatuLund/rich-tooltip-demo · GitHub

1 Like
6

Thanks both of you for your answer ! I will take a look at your demo.
Since currently it’s just for rendering a button, I will use a Component Renderer for that case

7

A web component in itself doesn’t help since what you still need is a way of informing that web component when the server is ready. For that, you would need some boilerplate logic to relay the update to the right location. That could possibly be through an additional withProperty on the renderer though you would then need to use that as a counter if you need to support multiple clicks. Another way could be that the client-side click listener registers a callback somewhere in the global namespace and then there’s a server-side executeJs that triggers that callback.

1 Like