---
# System prepended metadata

title: Design Documentation for UWPath Front End

---

# 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

