# Design Documentation for UWPath Front End

## Components
### Current Component Diagram

### 1. CourseInfo
#### Parameters
* antireqs
* coreqs
* prereqs
* course_abbr
* course_code
* course_id
* course_name
* course_number
* credit
* info
* offering
* online
* selected
* link
* course_code
* year

### 2. CourseRequirements
#### Parameters
* number_of_courses
* course_choices
* course_codes
* course_codes_raw
* selected_course
* major
* minor
* specialization
* id
* inRequirementBar
* prereqs_met
* additional_requirements
* number_of_prereqs_met
* user_selected
* year

### 3. ProgramInfo
#### Parameters
*

### 4. ProgramRequirements/OtherRequirements
#### Parameters
* TODO

## Proposed Features
### Requirement Bar State Management
- At all times, cards in the requirement bar should be in 1 of the 3 follow states:
1. Selected and only has 1 choice (for a singular course)
2. Unselected and have `select X` where `X > 1` and more than 1 choice
3. Selected and have `select X` where `X = 1` and more than 1 choice
- At all times, the requirement bar should be have the following properties:
- All cards are sorted in its appropriate section
- Within the same section, cards are sorted first by the `number_of_courses` then alphabetically by the course code of the course code of the first `courseInfo` in its list
- This guarantees that further down the road, functions that manipulate these cards can have the correct assumptions
- At any point, the requirement bar can have the following state changes
1. User selects a course from a `select X` card where `X > 1` (card splits)
2. User selects a course from a `select X` card where `X = 1` (card changes to display course code/title)
3. A card gets moved back from the table to a section
4. A card is moved from 1 section of a program to another (e.g. "100s courses" -> "others")
5. A card is moved around within the same section

### Handling how cards are transfered from requirement bar to table
- Cloning and moving cards makes the code hard to read/maintain
- A better way is to always clone a card and never move them
- Whenever a card is cloned and added to table decrement `number_of_courses` of the original card by 1 (this is already done)
- If the original card has `number_of_courses` equal to zero, don't display it in the requirement bar

### Handling `CourseInfo` and `CourseRequirement` instances
- There should only be 1 instance of a "unique" `CourseInfo` existing in the frontend
- There should only be 1 instance of a "unique" `CourseRequirement` existing in the frontend
- The uniqueness of a `CourseInfo` should be determined by its `course_code`
- The uniqueness of a `CourseRequirement` should be determined by its `raw_course_code` (currently we determine if a requirement is the same by the `id`)
- There should exist a cache to search for `courseInfo`s and `requirementInfo`s
- Problems we need to figure out:
- Figuring out a way to removing courseInfos when they are not part of a requirement info or an elective
- How to deal with requirements such as NON-MATH that points to > 1000 courses

### Updating models
- Add a `RequirementCardInfo` model
- `RequirementCardInfo` models represent 1 choice of a `CourseRequirement`
- For example if we have a select 5 card, we would create 5 `RequirementCardInfo` add it to the associated `CourseRequirement`
- Instead of moving `courseRequirements` between table/req bar, we move `RequirementCardInfo`s
- Rationale:
- Gives a nice property where `CourseRequirements` which of its instances are in the table and which of the instances are not
- Less tedious alternative than managing things such as `number_of_courses` where it would need to be set/reset over a bunch of states (such as when a requirement is satisfied by another requirement)

#### RequirementCardInfo
-

### Combining the models of Checklist Model and Requirement bar/table Model
TBD