-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Persist dashboard filters in query params #3406
Persist dashboard filters in query params #3406
Conversation
Filter values Could be something like:
Period |
added Helper as Mixin (frontend/src/mixins/formatHalHelperMixin.js) to convert uri to id
I used the Vue-router default implementation, its similar so i hope that's fine
Did that I added a Test for the functionality I added, doesn't test the entire class tho. |
No need for this to be a mixin. You can implement this has a simple helper class and then just export the 2 functions (see frontend/src/helpers/vCalendarDragAndDrop.js for example). Mixin is only needed, if you need access to the Vue component context. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally, looks good to me.
- Refactor mixin to helper would be nice (see my other comment)
- Any chance we can improve the error handling in
beforeMount
, when invalid/outdated data is presented (e.g. an ID is presented that was deleted in the meantime)? In my opinion we could silently ignore such data. At the moment, the console spits out some errors and the Select is not shown due to the errors.
validate query params before writing them to used filter values update unittests add jsdoc typing
update feature branch
⛔ Feature branch deployment currently inactive.If the PR is still open, you can add the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice, looks good to me. From my side good to merge.
Don't know why the end-to-end tests fail though. I have triggered a re-run to see if it was just a glitch.
]) | ||
|
||
this.loggedInUser = loggedInUser | ||
// Once camp data is loaded validate and map values from url param to filter | ||
await Promise.all([ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a specific reason we need 2 separate calls for Promise.all
? Or could we put all the loading promises into one Promise.all
and await this one?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nope, that's leftover code from when I tried some performance optimisation.
I found the reason for the failing check and could reproduce locally (see screen recording incl. console output). When I open the dashboard and immediately navigate to a different page (e.g. Print as in the e2e-tests), this triggers a In parallel, Dashboard is loading data and eventually calls Don't have an immediate good solution how to resolve this. Ideas very welcome. Screen.Recording.2023-06-11.at.09.57.29.mov |
Sorry i didnt update sooner, i figured it out too but I kinda have some trouble running the project localy. I was working on a way to fix that for some time but I had various problems locally. |
* Is True until the Component gets unmounted or there is a Navigation to another page | ||
*/ | ||
syncUrlQuerActive() { | ||
return this.isActive && this.$router.currentRoute.name === 'camp/dashboard' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This didn't work for me. this.$router.currentRoute
still equals to the camp/dashboard
route, even after the Print button was clicked. It seems that currentRoute
is only updated, once the navigation is completely finished.
What we probably would need is to query for a pending navigation route. In vue-router there's no built-in capability to do this. It seems to be implementable with Navigation Guards, however, might not be trivial to catch all the edge cases (see vuejs/vue-router#2012 (comment)).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see your point and used window.history.replaceState - this doesn't overwrite pending navigations.
This could cause problems with mobile devices tho.
# Conflicts: # frontend/src/views/camp/Dashboard.vue
integrate progress labels
It's all done and tested The failing check is an API Lint - I have no idea why it's failing but it's optional so I should be good? A Review would be appreciated @carlobeltrame or @pmattmann |
Yes, the psalm linter fails since a little more than a week. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice, looks good to me. Thanks for the good test coverage 👍
persistRouterState() { | ||
const query = transformValuesToHalId(this.filter) | ||
if (filterAndQueryAreEqual(query, this.$route.query)) return | ||
this.$router.replace({ query }).catch((err) => console.warn(err)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So you got it running in the end with $router.replace
without the need to use window.history
?
Cool. What was the secret trick to make it work?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the fix is on line 394, I implemented an equals check that doesn't trigger as easily. The issue is that the filter contains values such as null
or []
which should be equal to undefined
in the route.query
but the check before did not take that into account. Also the route.query
doesn't provide an array if there is only one value. The window.history
fix just doesn't refresh navigation. But now it may refresh navigation because it's only called when there is a real value change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah I see. Thanks for clarifying
The task of Dashboard improvements #3155
"Persist the filters in the URL, for sharing filtered lists and so that when navigating to an activity and back, the same filters are restored"
Dashboard component stores
Category
andResponsible
in Url params.Open Questions:
The filter values are stored in the
/categories/330a052f5d2d
- format, is that okay or is there a better Key?What is the filter value
period
and how is it written read? I found no way to set that in the UI.