Fix DropDown on page load

[daviddavo]

This issue could be related to #96, but improving the dropdown loading time is more important than adding caching to the rest of the application, so it will be done first.

[daviddavo]

In old versions, before adding the filters, the dropdown was generated directly in the layout.

Perhaps we could generate the DropDown again in the layout, and prevent the first call to the callback. That way, the page will take a bit more to load, but the dropdown will be already there (better UX).

[daviddavo]

The main purpose of this issue is to make the initial call to org_filters not necessary, and do everything inside dashboard_view.__generate_header.

To do this, we will have to:

• Create a new function that encapsulates common logic
• Add prevent_initial_call=True to the org_filters callback
• If the filter is unmarked, update the search URL if necessary, how? Perhaps this item can't be done when generating the layout, but we can do the other ones and then PreventCallbacks for everything except the url.

[daviddavo]

I'm also having problems to use prevent_initial_call, because of this:

However, the above behavior only applies if both the callback output and input are present in the app layout upon initial load of the application.

It is important to note that prevent_initial_call will not prevent a callback from firing in the case where the callback's input is inserted into the layout as the result of another callback after the app initially loads unless the output is inserted alongside that input!

In other words, if the output of the callback is already present in the app layout before its input is inserted into the layout, prevent_initial_call will not prevent its execution when the input is first inserted into the layout.

Because of our multipage layout, which loads the components after loading the application (using the change_subpage callback), we can't prevent the initial call on org_filters, because it has url as an input.

Perhaps using dash.no_update will prevent the Dropdown from reloading (and unfocusing it if the user had it focused).

[daviddavo]

I've added the Dropdown to the __generate_header function.

I don't think there's much improvement. dash.no_update won't do because we need to "trigger" the following callbacks (the platform info and graphs). So it will be recalculated nevertheless.

After giving up on trying to improve it, I think we have the following options:

1. Loading the dropdown with just the value that is currently selected (only one option). But it will be populated by the callback. This way, it will appear on screen and the user can navigate the rest of the page. But it won't be really usable. A quick user could click on the dropdown before it's really loaded.
2. Covering the dropdown behind the "loading square". The dropdown will still take time, but the user won't notice.
3. Create a curated selection of DAOs #99

[daviddavo]

About the first option, there are some callbacks that read information from the dropdown. This is because they generate an OrganizationList from the filtered options available in the dropdown. In that case, we'd need to save that filtered organization list somewhere else, or to recalculate it again when needed using the original organization list and the filters.

[daviddavo]

If we want to create a custom component, we'll need to use:

• https://dash.plotly.com/react-for-python-developers
• https://github.com/plotly/dash-component-boilerplate
• https://dash.plotly.com/plugins

Some community made components are:

• https://community.plotly.com/t/community-components-index/60098

The main problem with our current dropdown is rendering thousands of items. We need a system in which the dropdown only has a couple of hundred items at most, and if the user scrolls to the end, we could either load more items or tell the user that he needs to write text to search.

We should take the Table Component (which has server-side pagination) as a reference.

[daviddavo]

Waiting for plotly/dash#2251 to be fixed