Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

States refactor #181

Closed
3 of 4 tasks
diogotvf7 opened this issue Jan 26, 2024 · 1 comment · Fixed by #198
Closed
3 of 4 tasks

States refactor #181

diogotvf7 opened this issue Jan 26, 2024 · 1 comment · Fixed by #198
Assignees

Comments

@diogotvf7
Copy link
Contributor

diogotvf7 commented Jan 26, 2024

Problem

The current structure of TTS makes development harder due to the big amount of redundant states. This issue intends to simplify the entire structure of states and code in general.
This issue intends to minimize the data stored in local storage and, therefore make the development process easier.

New Structure

State Explanation
major Stores every major infomation
selected_major Index of the currently selected major - the course unit picker modal will suffer a refactor as well, in the new update this state will only be relevant during the edition of the selected course_units instead of being global (i.e. existing a main major). Learn more about this refactor
course_info[] Stores information of every course unit of the currently selected major
picked_courses : course[] Stores the information of each picked course_unit
option[] { id, icon, name, course_option[] } - this is the new multipleOptions
course_option { class_id (references a course element), locked, filtered_teachers, hide : Array<lesson_type> }
course { id, class[], ... }
class { class_name, slot[] }
slot { day, start_time, duration, room }

Obs:

  • enum lesson_type = { T, TP, P, PL, etc. }
  • Classes now have a set of slots. This will fix the problem having multiple options for the same class on the ScheduleListbox.

A note on the most important structure multiple options

Before the MultipleOptions structure looked like this:

image

The meaning of the old structure is the following:

  • The selected field is the array of the currently selected option (which square with the emojis we pressed)

  • The options field is where each entry represents the options of each emoji.

Now, the MultipleOptions is just an array of Option

export type MultipleOptions = Array<Option> 

export type Option = {
    id: number, // The id goes from 1 to 10, since we have 10 options
    icon: string, // This is the image link for the emoji
    name: string, // This is the name (the default names are Horário <id>
    course_options: Array<CourseOption> // This is an array with the courses selected on the course picker
}

The CourseOption has a field course_options that is an array where every entry represents each course.

In each course, in order to assign an option, we just change the value of picked_class_id from null to the correct one.

For example, if we chose the course with the course_id = 10 and a class with the id 50, the CourseOption would look like this:

 {
    course_id: 10,
    picked_class_id: 50,
    locked: /*either true or false*/,
    filteredTeachers: [/* either empty or with the selected filtered teachers*/],
    hide: [/* either empty or with the lesson types */],
}

And this object would be an entry in the array course_options of the MultipleOptions structure.

Current subtasks

@diogotvf7
Copy link
Contributor Author

Pay attention to this issue #155

@diogotvf7 diogotvf7 linked a pull request Mar 5, 2024 that will close this issue
9 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants