fix: setting list background in store #1616
No reviewers
Labels
No Label
area/internal-code
changes requested
confirmed
dependencies
duplicate
good first issue
help wanted
hosting
invalid
kind/bug
kind/feature
question
wontfix
No Milestone
No project
No Assignees
3 Participants
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: vikunja/frontend#1616
Loading…
Reference in New Issue
No description provided.
Delete Branch "fix/list-background-store"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This PR fixes two bugs when changing list settings, including the background (the background was where it was notable).
Currently, when creating a new list, setting a background and then navigating to the home page, the list background would not be shown in the list card. That was an easy fix.
The second bug: After fixing the first bug 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 tothis.$store.commit(CURRENT_LIST, null)
because everything is async. I tracked the problem down to the call towatchEffect
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.Hi konrad!
Thank you for creating a PR!
I've deployed the changes of this PR on a preview environment under this URL: https://1616-fix-list-background-store--vikunja-frontend-preview.netlify.app
You can use this url to view the changes live and test them out.
You will need to manually connect this to an api running somehwere. The easiest to use is https://try.vikunja.io/.
Have a nice day!
b3ad100db3
todb2005658c
@ -91,2 +104,4 @@
)
// call the method again if the listId changes
watchEffect(() => loadList(props.listId))
@konrad: reading the comment: shouldn't this be removed?
Probably, yes. Not sure why this works with this line still present.
Made a pull request #1795