Add Curator Viewer dashboard starter UI#5
Conversation
Summary of ChangesHello @FallingZYJ, I'm Gemini Code Assist1! 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 establishes the foundational user interface for the Curator Viewer, leveraging Next.js and TypeScript to create a lightweight, interactive dashboard. The primary goal is to provide a centralized view for monitoring Curator runs, cost projections, and dataset health, laying the groundwork for future enhancements like real-time data streaming. Highlights
Using Gemini Code AssistThe 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 by creating a comment using either
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 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
|
FallingZYJ
deleted the
codex/2026-01-27create-file-organization-program
branch
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request adds a solid foundation for the Curator Viewer dashboard using Next.js and TypeScript. The code is clean, well-structured, and follows modern practices. My review includes a critical note on addressing a reported security vulnerability in the dependencies, and a couple of medium-severity suggestions for the Dashboard component to improve the data loading scaffold and optimize rendering performance. Once these points are addressed, this will be a great addition.
| const refreshedData: DashboardData = { | ||
| metrics: DEFAULT_DASHBOARD_DATA.metrics, | ||
| activities: DEFAULT_DASHBOARD_DATA.activities | ||
| }; |
There was a problem hiding this comment.
This useEffect is intended as a scaffold for asynchronous data loading, but its current implementation is a bit confusing. It creates a new refreshedData object but reuses the same metrics and activities arrays from DEFAULT_DASHBOARD_DATA. Since the component state is already initialized with this data, this effect only triggers an unnecessary re-render without actually changing the data content.
To make this a more realistic and useful scaffold for fetching new data, I suggest creating a deep copy of the default data. This better simulates receiving a completely new data object from an API. The JSON.parse(JSON.stringify(...)) approach is a concise way to do this for serializable data.
const refreshedData: DashboardData = JSON.parse(JSON.stringify(DEFAULT_DASHBOARD_DATA));
| {dashboardData.activities.map((activity) => ( | ||
| <div key={activity.title} className={styles.activityItem}> | ||
| <div className={styles.activityText}> | ||
| <p className={styles.activityTitle}>{activity.title}</p> | ||
| <p className={styles.activityDescription}>{activity.description}</p> | ||
| </div> | ||
| <span className={styles.activityTimestamp}>{activity.timestamp}</span> | ||
| </div> | ||
| ))} |
There was a problem hiding this comment.
For performance optimization and consistency with how metricCards is handled, I recommend memoizing this list of activity items using the useMemo hook. This will prevent the .map() function from running on every render of the Dashboard component, recalculating the list only when dashboardData.activities actually changes.
When mapping over arrays to create elements, it's important to use a stable and unique key. Here activity.title is used. This is acceptable if titles are guaranteed to be unique within the list. If the backend data provides a unique ID for each activity, using that would be more robust.
You can add this before the return statement:
const activityItems = useMemo(
() =>
dashboardData.activities.map((activity) => (
<div key={activity.title} className={styles.activityItem}>
<div className={styles.activityText}>
<p className={styles.activityTitle}>{activity.title}</p>
<p className={styles.activityDescription}>{activity.description}</p>
</div>
<span className={styles.activityTimestamp}>{activity.timestamp}</span>
</div>
)),
[dashboardData.activities]
);And then replace the current mapping with {activityItems}.
1 participant
Motivation
Description
src/bespokelabs/curator/viewer/staticincludingpackage.json,tsconfig.json,next.config.js, andnext-env.d.tsto define the viewer project configuration.pages/_app.tsxandpages/index.tsxand two React components:components/Dashboard.tsx(metrics grid, operational overview, recent activity, and async data-load scaffold) andcomponents/ErrorBoundary.tsx(React error boundary for the viewer).styles/*to style the dashboard and error UI.Testing
npm installinviewer/static, which completed but emitted warnings and reported one critical vulnerability from the pinned dependencies.npm run dev -- --hostname 0.0.0.0 --port 3000and the Next dev server compiled and served the dashboard successfully.http://127.0.0.1:3000and saved a screenshot toartifacts/curator-dashboard.pngto validate the page renders.Codex Task