[Closes #515] Export trial data to PDF

[MarianaES]

Button in the view page

PDF Generated

1/2

2/2

[gemini-code-assist]

Summary of Changes

Hello @MarianaES, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces a significant new capability: the ability to export student trial data into a well-formatted PDF report. This feature enhances data accessibility and provides a convenient way to share progress reports, improving record-keeping and communication for student benchmarks.

Highlights

• PDF Export Functionality: Implemented a new feature allowing users to export comprehensive trial data reports to PDF format.
• Backend PDF Generation: Introduced a new backend utility (pdf-generator.ts) that leverages Puppeteer to render dynamic HTML content into a printable PDF document.
• New API Endpoint: Added a iep.exportReport mutation to the backend, responsible for fetching relevant student, goal, benchmark, and trial data, calculating success rates, and orchestrating the PDF generation.
• Frontend Integration: A "Data Report" button has been added to the benchmark view page, enabling users to trigger the PDF export directly from the UI and download the generated report.
• Detailed Report Content: The generated PDF report includes an overview of trials, success rates, staff members involved, benchmark details, success rate progress over time, and a detailed breakdown of individual trial data.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in issue comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request adds a valuable feature for exporting trial data to a PDF. The implementation using Puppeteer on the backend is solid. My review focuses on improving correctness, maintainability, and performance. The most critical issue is the use of timezone-sensitive date functions, which can lead to incorrect data grouping on both the backend and frontend. I've also identified opportunities to refactor duplicated code, improve performance in the PDF generation process, and clean up the client-side code.

[gemini-code-assist]

There are two issues in this section:

1. Timezone-dependent logic (High Severity): Using new Date(trial.created_at).toDateString() to group trials by date is unreliable because it depends on the server's local timezone. This can lead to incorrect success rate calculations, especially for data logged around midnight. Please use a timezone-independent method, like trial.created_at.toISOString().split('T')[0], to group by UTC date. The use of new Date(date).toLocaleDateString() is also problematic for the same reason.

2. Code Duplication (Medium Severity): The logic for calculating daily success rates is duplicated from the frontend file view.tsx. This makes the code harder to maintain. Consider extracting this logic into a shared utility function.

      // Calculate success rates by date (similar to the frontend logic)
      const datePoints: { [date: string]: typeof trials } = {};

      trials.forEach((trial) => {
        const createdAtDateString = new Date(trial.created_at).toISOString().split('T')[0];

        if (datePoints[createdAtDateString]) {
          datePoints[createdAtDateString].push(trial);
        } else {
          datePoints[createdAtDateString] = [trial];
        }
      });

      const successRates = Object.entries(datePoints).map(([date, trials]) => {
        const totalSuccess = trials.reduce((sum, t) => sum + t.success, 0);
        const totalUnsuccess = trials.reduce((sum, t) => sum + t.unsuccess, 0);
        const successRate =
          totalSuccess + totalUnsuccess > 0
            ? (totalSuccess / (totalSuccess + totalUnsuccess)) * 100
            : 0;

        const staffNames = Array.from(
          new Set(trials.map((t) => `${t.first_name} ${t.last_name}`))
        );

        return {
          date: new Date(date).toLocaleDateString("en-US", { timeZone: 'UTC', month: 'short', day: 'numeric', year: 'numeric' }),
          rate: successRate,
          staffNames,
          numberOfTrials: trials.length,
        };
      });

[gemini-code-assist]

The page.setContent call uses waitUntil: ["networkidle0", "domcontentloaded"]. Since the HTML content is generated locally and passed as a string, there are no external network requests to wait for. Using networkidle0 is unnecessary and could slow down PDF generation or even lead to timeouts in some environments. Using just domcontentloaded is more appropriate and efficient here.

Suggested change

	await page.setContent(htmlContent, {
	waitUntil: ["networkidle0", "domcontentloaded"],
	timeout: 30000,
	});
	await page.setContent(htmlContent, {
	waitUntil: "domcontentloaded",
	timeout: 30000,
	});

[gemini-code-assist]

The logic for converting the base64 PDF string to a Blob can be significantly simplified by using the fetch API with a data URI. This makes the code more concise, readable, and modern.

Suggested change

	const byteCharacters = atob(result.pdfBuffer);
	const byteNumbers = new Array(byteCharacters.length);
	for (let i = 0; i < byteCharacters.length; i++) {
	byteNumbers[i] = byteCharacters.charCodeAt(i);
	}
	const byteArray = new Uint8Array(byteNumbers);
	const blob = new Blob([byteArray], { type: "application/pdf" });
	const blob = await (await fetch(`data:application/pdf;base64,${result.pdfBuffer}`)).blob();