Probably caused by the blur hash feature, switching between lists would not work if the list background was set via unsplash. I've refactored the whole decision tree which checks if a background should be loaded or not. It actually does not matter where the background is from (unsplash or upload) or if we had one in the last list - we only need to know if the current list has a background or if we just changed it and need to update right away.
To make sure the tasks of a list are only loaded after the list itself is fetched from the server, we hide the list view until the list is fully loaded. When switching between different views of the same list, this would cause the list view to not be loaded at all because the list was already loaded at that point.
closes#1732
The new list background was set on the home page when navigating to the list. This was because the `CURRENT_LIST` was set to the last visited list, even after the call to `this.$store.commit(CURRENT_LIST, null)` because everything is async. I tracked the problem down to the call to `watchEffect` in the ListWrapper component. Apparently, `watchEffect` is called every time _the watched variable is assigned to_ and not only when it changes. When navigating away from the list, that watcher is getting called with the list id, the one already loaded, and sets it in store which in turn overrides the call from the contentAuth component.
Currently, when opening a list sometimes the tasks are shown before the list itself is loaded. Because the list contains the rights, this means no edit buttons etc are available at that point which is pretty confusing.
This PR ensures the list-specific view is loaded only after the list itself is loaded.
Co-authored-by: kolaente <k@knt.li>
Reviewed-on: #1251
