Implementing lazy-loading

[edan-bainglass]

This PR aims to improve the user's experience by isolating loading of widgets/resources to where they are needed (requested).

The overall approach is as follows (per widget):

1. Move bulk of __init__ logic to a new render method
2. Add a loading widget (introduced in this PR) as a child in __init__
3. Observe the container of the widget (widget might be in an accordion, a tab, etc. -> observe the selected_index trait of the container)
4. On observable notification (e.g., tab switch), trigger widget's render method

Re-rendering is guarded against using new self.rendered boolean, which is False and set to True at the end of render.

At the initial stages of this PR, most state observation (dlinking between widgets) will be disabled, as the entire logic must be rewritten to accomodate lazy-loading.
The current working approach considered here is a mediator state manager, i.e., a context manager.

More to come!

[edan-bainglass]

@PNOGillespie Hi Peter. I'm reaching out regarding this PR in hope that you may assist with one part relating to your XAS plugin.

To keep it brief, the settings module of your XAS plugin triggers a good deal of logic on import. This prevents the implementation of lazy-loading w.r.t XAS.

A simple solution would be to do as @superstar54 did in the XPS plugin, i.e., wrap such logic in a function to be lazily triggered on demand. Do you think this is something you could look into in a separate PR? If not, could you please comment on the reason?

[PNOGillespie]

Hi @edan-bainglass. I can move the logic for updating the pseudopotentials (which is what lines 67 - 112 in settings do on starting the plugin) to be under _update_element_select_panel(). This should mean that the logic is only triggered by _update_structure(). Is that what you meant? Please let me know if I'm missing something.

I'm somewhat busy both this week and next, but I should be able to put together a separate PR soon for the changes if it's just a case of moving things around.

[edan-bainglass]

Hi @PNOGillespie 👋

Hi @edan-bainglass. I can move the logic for updating the pseudopotentials (which is what lines 67 - 112 in settings do on starting the plugin) to be under _update_element_select_panel(). This should mean that the logic is only triggered by _update_structure(). Is that what you meant? Please let me know if I'm missing something.

Yes, this sounds right. As stated, @superstar54's approach in the XPS plugin is likely the way to go, for reference 🙂 Once the PR is ready, I test against my lazy-loading work and we see more clearly if it's sufficient 👍

I'm somewhat busy both this week and next, but I should be able to put together a separate PR soon for the changes if it's just a case of moving things around.

No worries. The lazy-loading work will take a few pass (possibly incremental PRs), so the XAS part can be addressed once your PR is in.

Thanks 🙏

[edan-bainglass]

@PNOGillespie @superstar54 just wondering, why were the XPS and XAS plugins included in the core app? Would it be better to maintain them as external plugins, say aiidalab-qe-xps and aiidalab-qe-xas, to be installed by those interested? What do you think?