Event | Day | Date | Time |
---|---|---|---|
Release | Thu | Nov 13 | 09:00 AM ET |
Due | Fri | Nov 22 | 05:00 PM ET |
In this assignment, you will combine your Flashcards API (HW5) with your React frontend (HW4) to create a fullstack Flashcards application. You will enhance both the API and the web application with new features, improved error handling, and a more robust user interface.
Your task is to integrate the Flashcards API with the React frontend to create a fullstack Flashcards application. You will implement new features and improvements in both the API and the web application. The API should support sorting, search, and pagination for decks and cards, while the web application should display a paginated list of decks on the home page and a paginated list of cards for each deck. The web application should also include features for editing and deleting cards, adding new cards, and handling empty and error states gracefully.
Currently, the api
folder contains a .keep
file. Delete this file! Next, copy the contents of the api
folder from your submission for HW5 into the api
folder. Your API server application should adhere to all the specifications in HW5. Additionally, you must implement the following new features:
GET /decks
and GET /decks/:deckId/cards
endpoints to support sorting along with search and pagination.
title
field for decks should be required and have a maximum length of 100 characters.title
filed shall only contain alphanumeric characters and spaces.front
and back
fields for cards should be required and have a maximum length of 500 and 1000 characters, respectively.success
(boolean) to indicate if the request was successful,message
(string) to provide a descriptive message,data
(an array of results or a single result object, depending on the endpoint),meta
an optional object containing additional metadata such as pagination information.You must adhere to the provided structure even when returning errors. For example:
GET {{BASE_URL}}/decks?page=1&limit=1
should return a response like this:
GET {{BASE_URL}}/decks/1
should return a response like this:
GET {{BASE_URL}}/decks/400
should return a response like this:
GET {{BASE_URL}}/decks/two
should return a response like this:
Notice that the error message includes detailed information about the validation error.
Currently, the web
folder contains a .keep
file. Deletethis file! Next, copy the contents of the web
folder from your submission for HW4 into the web
folder. Your web application should adhere to all the specifications in HW4. Additionally, you must implement the following new features:
decks/:deckId
that displays the list of cards in the selected deck.Please see the demo on Panopto.
Begin by logging into your GitHub account at https://github.com/. Then, accept the invitation by clicking on this link. This action will create a private GitHub repository with the starter code.
Please keep the repository private. Do not change its visibility or add collaborators. Clone this repository to your local machine to start your work.
Clone the repository to your local machine and follow the instructions in the README file to set up the project. Develop the app according to the provided description, demo, and specifications.
You don’t need to deploy this application. However, don’t forget to update the info.json
file with links to your GitHub repository:
Make sure to commit and push the updated info.json
file to your GitHub repository. After doing so, submit your work on Gradescope.
If you need to resubmit, push the changes to your repository first, then re-submit on Gradescope.
Teaching assistants will evaluate your submission using the following criteria:
Spec 1: The API server should be implemented using Hono.js and should provide all endpoints for managing decks and cards as specified in HW5. The server should start without errors using the pnpm dev
command and should not crash under any circumstances, including erroneous requests.
Spec 2: The API server should have CORS enabled for all routes, allowing requests from any origin.
Spec 3: The GET /decks
and GET /decks/:deckId/cards
endpoints should support sorting by date in ascending or descending order, in addition to the existing search and pagination functionality.
Spec 4: The API’s seed script should be updated to include sample data suitable for testing the search, sort, and pagination functionality.
Spec 5: The API’s input validation schemas should be updated to include the new constraints for deck titles (required, max 100 characters, alphanumeric and spaces only) and card content (front: required, max 500 characters; back: required, max 1000 characters).
Spec 6: All API endpoints should return responses adhering to the new structure, including success
, message
, data
, and meta
fields. This structure should be consistently used for both successful responses and error responses.
Spec 7: The web application should display a paginated list of decks on the home page, with each deck showing its title, number of cards, and creation date. The list should be paginated with a default page size of 10 decks per page.
Spec 8: The deck list header should display the total number of decks and the range of decks being displayed. The footer should include pagination controls for navigating between pages.
Spec 9: Clicking on a deck in the list should navigate to a new page (decks/:deckId
) that displays a paginated list of cards in the selected deck.
Spec 10: Each card in the list should display the front content and have buttons for edit and delete actions. Clicking on the card should flip it to display the back content.
Spec 11: Clicking the edit button for a card should open a modal dialog with a form to edit the card’s front and back content. The modal should have a close button to dismiss the dialog.
Spec 12: Clicking the delete button for a card or deck should display a confirmation dialog. The dialog should include buttons to confirm or cancel the deletion.
Spec 13: The card list header should display the total number of cards and the range of cards being displayed. The footer should include pagination controls for navigating between pages.
Spec 14: The “add” button on the sidebar should change to red when on the cards page. Clicking this button should open a modal dialog with a form to add a new card to the current deck.
Spec 15: The home button in the sidebar should navigate back to the home page with the list of decks.
Spec 16: Appropriate messages should be displayed for empty states (no decks or no cards) and error states (deck or page not found).
Spec 17: The application should display appropriate messages when the user performs actions such as adding, editing, or deleting decks and cards. These messages should include the response from the API server, including validation error messages.
Spec 18: The web application should handle API errors gracefully, displaying error messages to the user in a user-friendly manner.
Spec 19: The web application should display a 404 page when the user navigates to a deck that does not exist or a page that does not exist. The 404 page should include a button to navigate back to the home page.
Spec 20: The code should be well-organized, following best practices for both the API (Hono.js) and the web application (React). This includes proper use of components, hooks, and state management in React, and appropriate use of middleware and error handling in Hono.js.