Handika: Create a People Report solution for when people have more than 20 tasks. - #5405
Handika: Create a People Report solution for when people have more than 20 tasks.#5405handikaharianto wants to merge 74 commits into
Conversation
…-report-solution-for-large-tasks
✅ Deploy Preview for highestgoodnetwork-dev ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
…eport details page
…er in larger screen
…-report-solution-for-large-tasks
There was a problem hiding this comment.
The row limiting and empty states look good, but a few things need sorting before this merges.
The PeopleReport.jsx rewrite no longer syncs isRehireable from the loaded profile, so a non-rehireable person appears rehireable. Its new catch/finally path also renders with incomplete data after a failed request instead of retaining a safe loading or error state.
In the new chart, visibleCount starts at the full task count, so the entire table paints before it is trimmed. The CSS-module conversion in PeopleTableDetails is incomplete: several table classes are still plain strings, so the updated grid, padding, and dark-row rules cannot match. The resource-count badge also references a missing module class, and the project empty state misses the zero-hours case.
On scope, package.json is unchanged but yarn.lock has 3,982 changed lines, including registry rewrites and dependency-version changes. ApplicationTimeChart/data.js also appears unrelated and unused. The description should note that PeopleReport.jsx is a class-to-hooks rewrite and include test steps for the rewritten behavior, including the rehireable state and a failed data request.
| // render every row regardless of this number. The renderer slices in half: the | ||
| // measurement effect owns the cap, the JSX owns the slice. | ||
| const tbodyRef = useRef(null); | ||
| const [visibleCount, setVisibleCount] = useState(tasks.length); |
There was a problem hiding this comment.
visibleCount starts at tasks.length, so the first paint renders every row and the effect trims it only afterwards. With a long list, the full table can flash before it snaps down, which defeats the point of this large-list change. Starting with a small count and measuring before paint would avoid that.
| // setShowAllTasks(prev => !prev); | ||
| // } | ||
|
|
||
| const hasProjectData = hoursLoggedToProjectsOnly.length > 0; |
There was a problem hiding this comment.
This only checks whether project entries exist, not whether they have logged hours. A project entry with totalTime 0 renders this section while ProjectPieChart returns no chart, so the new empty state is skipped. The selector already exposes showProjectsPieChart using totalTime > 0; could this use that value?
Hi, thanks for the review. Your screenshot doesn't reflect the latest updates of this branch. Please make sure to always pull the latest changes from the branch. I've included a video of how it looks like. Also, the section below the |
…yed when it fails
…-report-solution-for-large-tasks
|







Description
Related PRS (if any):
This frontend PR is related to the #4635 and #3670
Main changes explained:
CompletedTasksPieChart.How to test:
handika/people-report-solution-for-large-tasksnpm installandnpm run start:localto run this PR locallyTasks With Completed Hourssection properly handles large number of completed tasks.Tasks With Completed Hourssection displays an empty state when there is no data to display.Time Logged to Projects/Non-taskssection displays an empty state when there is no data to display.Tasks With Completed HoursandTime Logged to Projects/Non-tasks.Screen.Recording.2026-08-04.at.8.49.36.PM.mov
Note:
None