Expanded the existing work packages get all endpoint to support optional filtering by status and/or timeline status, not via Prisma implementation. Expanded get all work packages hook to support this filtering. Use this filtering to add a "Work Packages by Timeline Status" component to the home page which not only displays all "VERY_BEHIND" work packages by default, but also allows users to select to see work packages with a different timeline status. Uses the same horizontal scroll card format as the upcoming deadlines component.
Notes
Okay so this one was interestingly tough. I first filtered client-side until I realized that messes up the loading and isn't so proper, then considered a whole new endpoint, but decided not to. I experiment and researched and built out a flexible addition to the get all work packages endpoint that filters by status or timeline status or both. Considered doing a Prisma AND NOT implementation as suggested by their example, but decided that such an implementation would be way more lines of code and would probably only provide slight performance benefits and so I stuck with js .filter().
Then when trying to get the select dropdown to work properly, I discovered that setState() is async but doesn't provide a callback parameter like the React docs seem to indicate. Weird. Instead I had to use a useEffect with suppressing exhaustive dependencies to have the component re-fetch data and re-render consistently when the dropdown is changed. Seems strange that this is what's required for that to work but I guess the optimizations avoid re-render so this is what's needed.
I kinda randomly decided to remove duplication by switching the get single work package endpoint to use findFirst instead of findUnique, allowing us to search via the work package model instead of the wbsElement model while achieving the exact same results.
Not for this PR but considering also doing:
move WP count into the page block title as ... (6) for upcoming deadlines
add WP count into the page block title for this new component
make upcoming deadlines more flexible and able to support variable "days until deadline" instead of fixed at 14 days
Test Cases
pretty basic, just tried to maintain test coverage.
Screenshots (if applicable)
Checklist
It can be helpful to check the Checks and Files changed tabs.
Please review the contributor guide and reach out to your squad if anything is unclear.
Please request reviewers and ping on slack only after you've gone through this whole checklist.
[x] All commits are tagged with the ticket number
[x] No linting errors
[x] No newline at end of file warnings
[x] All code follows repository-configured prettier formatting
[x] No merge conflicts
[x] All checks passing
[x] Screenshots of UI changes (if applicable)
[x] Remove any not-applicable sections
[x] Assign the PR to yourself
[x] PR is linked to the ticket
[x] No package-lock.json changes (unless dependencies have changed)
Changes
Expanded the existing work packages get all endpoint to support optional filtering by status and/or timeline status, not via Prisma implementation. Expanded get all work packages hook to support this filtering. Use this filtering to add a "Work Packages by Timeline Status" component to the home page which not only displays all "VERY_BEHIND" work packages by default, but also allows users to select to see work packages with a different timeline status. Uses the same horizontal scroll card format as the upcoming deadlines component.
Notes
Okay so this one was interestingly tough. I first filtered client-side until I realized that messes up the loading and isn't so proper, then considered a whole new endpoint, but decided not to. I experiment and researched and built out a flexible addition to the get all work packages endpoint that filters by status or timeline status or both. Considered doing a Prisma AND NOT implementation as suggested by their example, but decided that such an implementation would be way more lines of code and would probably only provide slight performance benefits and so I stuck with js
.filter().Then when trying to get the select dropdown to work properly, I discovered that
setState()is async but doesn't provide a callback parameter like the React docs seem to indicate. Weird. Instead I had to use auseEffectwith suppressing exhaustive dependencies to have the component re-fetch data and re-render consistently when the dropdown is changed. Seems strange that this is what's required for that to work but I guess the optimizations avoid re-render so this is what's needed.I kinda randomly decided to remove duplication by switching the get single work package endpoint to use
findFirstinstead offindUnique, allowing us to search via the work package model instead of the wbsElement model while achieving the exact same results.Not for this PR but considering also doing:
... (6)for upcoming deadlinesTest Cases
pretty basic, just tried to maintain test coverage.
Screenshots (if applicable)
Checklist
It can be helpful to check the
ChecksandFiles changedtabs. Please review the contributor guide and reach out to your squad if anything is unclear. Please request reviewers and ping on slack only after you've gone through this whole checklist.package-lock.jsonchanges (unless dependencies have changed)Closes #729