An event to execute code after the component has become visible?

Flow
1

Currently I’m abusing executeJS. I’m sometimes feeding it the best JS snippet in the world (“” :rofl:), so that I do that so that I can first do something in the UI and then do something more expensive (like a longer blocking backend call). Example visible here:

https://sa.dokku1.parttio.org/announcetheslowaction

While I was developing that example/demo app, I became to think that are we actually missing a feature here? The AttachEvent is executed in the server (in some cases a lot) earlier than the component is actually shown in the UI. It is kind of “preAttach” event. For handling slower actions and sometimes also for example displaying heavy components, it might make sense to also have some sort of “postAttach” event, that would be executed after the component really is visible in the browser.

Do you think that could be helpful in the Component interface?

Like always, naming would be essential for this. I haven’t yet tought that much, but dropping in some possibilities:

  • PostAttachEvent
  • InteractiveEvent
  • VisibleEvent
  • DisplayedEvent
  • RenderedEvent
1 Like
2

In my (limited) experience, this has only come up in the context of a Grid, but then I’ve heard the question “how do I know when a Grid has finished rendering?” quite many times.

3

What are those cases? IMHO it sounds like a “improveable” problem in User’s code if they attach things that never get shown… (talking to you setVisible(true/false) user…)

I don’t think another event is going to help… it might make things even more complicated or confusing for users with all possible hooks already present (constructor / pre construct / onAttach / beforeEnter / afterNavigation / beforeClientResponse …)

4

Starting an action and showing something (progress indicator, notification or some other component) during the task is quite obvious. Currently the order of execution in the UI can easily be correct, but the problme is that the changes are reflected on the UI in one batch (where e.g. the progress indicator would be both added and removed). If that is the only case then it probably better to accomplish with something more specific in UI only.

There has been also solutions/addons where rendering of a heavy page is broken into “chunks”. With this kind of event, that could be implemented core features.

And yeah, we sure should have some sort better referece for all these events whan explanation/diagram on when they are actually called…

@ollit.1 Do you remember what people usually want to do “after grid is displayed”?

5

That reminds me of this :slightly_smiling_face: [popover] Popover lazy loading of content · Issue #7689 · vaadin/web-components · GitHub

6

Never used Popover yet myself (I have missed this kind of component in the past though). I gotta agree with your issue, even so much that I’d push that kind of lazy loading of the content as the default mechanism for developers.

The API I’m thinking here might indeed help to workaroud the missing callback API for Popover. One could “only” instantiate an empty layout and defer the creation of the content until the layout is actually becoming visible/rendered in the browser :thinking:

7

Yeah… your comment made me remember the shortcomings of some components… like flow IMHO does not need more hooks… but the components need a bit more lazy-loading capabilities… ranging from

  • details
  • tab(sheet)
  • tooltip / popover
  • messagelist
    (And probably other I don’t have on hand)

Tab(sheet) makes it pretty obvious that this feature is missing by advertising a “solution” / workaround… Tabs | Components | Vaadin Docs

1 Like
8

I’m not sure when the event is supposed to be fired or what it does.

The after rendered (for a grid or any component) seems to be difficult . For example in the grid you can show the empty grid then the first rows,…

So AfterRenderedEvent would be my favorite name

To me, VisibleEvent = when it’s visible, it can be useful to update a placeholder to a real component (very likely not the event you want to create).

I’m bookmarking your demo, since it has a lot of nice things :slight_smile:

9

PopOver does not have lazy content provider callback, but has listener for the open / close event.

popover.addOpenedChangeListener(event -> {
   if (event.isOpen()) {
      popover.removeAll();
      popover.add(content);
   });
});
10

Nice @Tatu2 :+1: Would deserve some demo/example how to use that. At least I missed it from the docs.

Thanks @Jean-Christophe.1 :bowing_man: , I made even a teaser post for it to blog, but all the “meat” is in the demo itself.

11

It hasn’t been one single reason. One use case was getting the exact widths of the columns (which were auto-width sized based on the contents) to visualize data points on top of the Grid in a chart. In another case, it was just measuring the time until the user could enter information to make sure the performance was staying adequate. In a third one, setting the focus in an editor field inside the Grid once it was ready.

12

Here’s another use case which has come up more than once: Grid and preserving selection - #5 by Tatu2