Nothing world changing. I realised recently that I prefer explicitly calling methods of stores and do the same with their states.
Similar to how one would do that with classes.
Since I might make more changes like this in the future (maybe also part of other PRs) I though I'd explain my reasoning here in a bit more detail:
__Benefits__
- saves local mappings, like the `const updateConfig = () => configStore.update()`
- there is no need to look up what exactly is updated, since the function is provide by the store.
__Disadvantages__
- a little bit more verbose (but not thaaat big difference)
---
TLDR: When reading the code this saves the step to check what was mapped.
Reviewed-on: https://kolaente.dev/vikunja/vikunja/pulls/2945
Reviewed-by: konrad <k@knt.li>
Co-authored-by: Dominik Pschenitschni <mail@celement.de>
Co-committed-by: Dominik Pschenitschni <mail@celement.de>
This fixes a race condition and should potential fix some flaky Cypress tests:
<img width="630" alt="Screenshot 2024-12-12 at 10.53.56.png" src="attachments/21dce132-7f1a-4e19-b14c-b0a868daa20e">
-----
Before `selectedView` was filled with an initial value that depended on the the related project being loaded before the shared links, since the assignment happened directly after the views have been loaded.
This fix ensures that the correct project has been loaded before it's accessed to look up the id of the first view.
-----
@konrad: Now that I finished this PR I'm a bit unsure if it's the "correct" way to solve this.
Because for existing share links it might be better if the links save the selected view as a property. Currently a change of the view only changes the created link in the frontend. When you change the view and reload the link stays the same.
I'm unsure if editing the selected view is something that we want (or is even possible depending on what the hash represents).
So maybe we should only support the following: The user selects a view when creating a linkShare and and different from before it will be saved.
Even with those additional changes we still need something similar to the changes of this PR, since we would still need to load the available view ids for the creation of a new link share.
Reviewed-on: https://kolaente.dev/vikunja/vikunja/pulls/2932
Co-authored-by: Dominik Pschenitschni <mail@celement.de>
Co-committed-by: Dominik Pschenitschni <mail@celement.de>
This fixes a bug where the "import your tasks from other platforms" would be shown even if the user had already imported tasks. The bug was caused by the heuristic "there are tasks" was not evaluated when tasks were loaded through a filter
Resolves https://github.com/go-vikunja/vikunja/issues/372
Quote:
> Vite's default browser support baseline is Native ESM, native ESM dynamic import, and import.meta. This plugin provides support for legacy browsers that do not support those features when building for production.
Since all three feature now have more than 97% market share it seems fine to remove them.
Reviewed-on: https://kolaente.dev/vikunja/vikunja/pulls/2921
Co-authored-by: Dominik Pschenitschni <mail@celement.de>
Co-committed-by: Dominik Pschenitschni <mail@celement.de>
Because the tasks were emitted as the relation was created, when a task had multiple subtasks the parent was emitted multiple times and thus, shown multiple times in the list view. This change fixes that behaviour by emitting all tasks at the end, when all relations are created.
This fixes an issue where the default date for a new reminder was
1970-01-01 (unix timestamp 0). It was caused by a new date object being
created but since the reminder that was creatd was new, this was created
as null date, which equals a 0 unix timestamp.
Resolves https://github.com/go-vikunja/vikunja/issues/359
renovate
Frederick [Bot]
kolaente
Dominik Pschenitschni