[Sprint 7c]: Database Column Editor Component ✍️ - Anne & Hansini

[danglorioso]

💻 Summary

In this sprint, you will make the data stored in our database directly editable by users. This will prevent them from having to delete data for a given year and then re-upload due to changes in the input data or small errors in individual cells or columns.

Goals of this sprint:

• Learn how to interact with and manipulate the data on the frontend and push the changes that are made to the backend to be stored in the database.
• Visualize the database in an editable spreadsheet/table format.

⚙️ Setup

Before starting:

1. PLEASE: Pull the latest changes from main: git pull
2. Create a new branch for this sprint.
3. Install dependencies: npm i
4. Run the dev server and verify the site builds: npm run dev
5. Confirm everything runs.
   If you experience problems, check your .env is up to date!

🧭 Implementation

Step 1: Study the Figma

• This ticket is pretty heavily reliant on the designs that TIka provides for the editor component.
• Look at the places in the app where the user can edit the database. These locations are where you should paste your component.
• Also ensure that interacting with the component is implemented in the same way that it is defined in the designs.
• Also consider: We have multiple different tables in our database that may need to be shown/joined. How should each one be visualized? You may have to toggle between different ones to edit different data.

Step 2: Implement the Component

• Using the Figma as your source of truth for design, begin implementing the component.
• The component should take as input the data to display.
• Consider loading states for the table. You are fetching a decent amount of data from the database, so it is likely that there will be a bit of a delay. Ensure that your loading state is clean and matches the rest of the flow of the app.
• Create backend API routes that handle data edit in the database. Note that you will have to uniquely identify different entries/rows when updating their data so you know which one to modify. You should probably identify entries using the id column in each table (different id from schoolID, teacherID, etc.). These routes should ideally be passed only the data being updated to avoid excess data slowing the write times. Thus, you will have to devise a way to determine which data has been changed.

Step 3: Test

• You’ll definitely want to test that the edits that you make to the data are actually being written to the database. Spend some time ensuring that this is the case.
• Consider that you will have to write the new data to the database, but you will also want to display that new data once it's updated, even if the changes have not been committed.

🙌 Acceptance Criteria

• All necessary data is editable from the frontend (in the specified places)
• Updated data is shown in the table once the user changes it.
• UI matches Figma exactly
• Code runs locally without errors and builds successfully
• Merge via PR

⁉️ Questions

If you get stuck or have questions:

• DM Dan or Shayne on Slack
• Come to office hours or ask during a hack night
• Ask questions during team meetings – we’re here to help!

📝 Resources

• Figma - Tailwind CSS
• shadcn/ui
• npm package manager