The course editor is four steps that depend on each other: Basic Info → Advanced Info → Curriculum → Publish. Each step hydrates from a Zustand store, edits through its own React Hook Form instance, and writes back on submit.

The interesting problem was structural changes inside the Curriculum step. Adding a section or a lecture needs to persist to the server immediately — otherwise the user closes the tab, comes back, and finds their outline gone. But a section that exists only in the browser has no ID yet, and the file upload inside a lecture needs a lecture ID to attach to.

I solved it with temp IDs. Every new section gets temp-section-{uuid}, every new lecture gets temp-lecture-{uuid}. When the server responds with the real IDs, the store swaps them in and RHF resets. The UI never waits on the network for a structural change; it rolls back on failure instead.

// src/components/dashboard/instructor/create-course/curriculum-step/CurriculumCourseFormWrapper.tsx (excerpt)
const dataForBackend = {
  sections: form.getValues().sections.map((section) => ({
    ...section,
    id: section.id?.startsWith("temp-") ? "" : section.id,
    lectures: section.lectures.map((lecture) => ({
      ...lecture,
      id: lecture.id?.startsWith("temp-") ? "" : lecture.id,
    })),
  })),
};

const updatedSections = await handleAutoSaveCurriculum(dataForBackend);

// Swap temp IDs for real ones
if (updatedSections) {
  form.setValue(`sections.${newIndex}`, updatedSections[newIndex], {
    shouldValidate: true,
  });
}

• Uploads queue when the parent lecture ID doesn't exist yet, and fire automatically once the ID arrives. The user sees a spinner, not an error.
• A local draft system lives in localStorage under course_draft::{id}, with a 24-hour TTL. On page load, the local draft's timestamp is compared against the server's. Local newer → show a modal. Server newer → silently sync.
• Every step has its own RHF instance and hydration key. Adding a new step is adding a new file, not editing a shared wizard.

Certificates needed to be downloadable as PDFs, shareable as images on mobile, and verifiable through a public URL. The backend wasn't set up for image rendering, and I wanted the certificate to be a React component so designers could iterate on it in JSX.

The approach: render the certificate in an off-screen container, wait for every image inside to load and for the browser to paint, capture the DOM with html-to-image, then ship it through jsPDF for PDF export and the Web Share API for mobile sharing.

The hard parts were all timing. Safari captures before fonts and images have rendered unless you wait — I use a double requestAnimationFrame plus a 50ms buffer to guarantee the paint is done. html-to-image doesn't wait for <img> elements, so I query every image inside the container and await their load or error events before capturing. The QR code is generated asynchronously as a data URL, which means the whole capture path is stateful — the image isn't ready until the QR is.

// src/hooks/useCertificate.ts (excerpt)
await new Promise<void>((resolve) => {
  requestAnimationFrame(() => {
    requestAnimationFrame(() => {
      setTimeout(resolve, 50); // extra buffer for Safari
    });
  });
});

const dataUrl = await toPng(containerRef.current, {
  cacheBust: true,
  backgroundColor: "#ffffff",
  pixelRatio: 2,
  skipFonts: true,
});

• One hook — useCertificate — powers the download button, the share sheet, and the public verification page. The abstraction held across all three consumers.
• The certificate is a React component a designer can edit. No backend rendering service, no server round-trip, no format drift between PDF and PNG.
• Every capture path (PNG, PDF, share, preview) goes through the same wait-then-capture pipeline, so behaviour is identical no matter which button the user clicks.