Add SubsemesterScheduler, component reorganization, Prettier code style, add jsdocs

[123joshuawu]

TODO:

• review ICS calendar changes, idk if it works @CoreyBuckley
• more thoroughly test subsemester functionality
• documentation generation for sfc using jsdoc annotations

Two main aspects of the changes below are

1. Added SubSemesterScheduler for toggling schedules based on subsemester
2. Splitting CourseList and SelectedCourses into separate components

Additional noteworthy changes:

• Added proxy to Vue devServer so CORS no longer required in backend
• Added prettier for enforcing code style
• Added jsconfig.json for vscode intellisense import of '@/' webpack alias
• Added jsdoc.config.json for jsdoc documentation generation

Overview of SubSemesterScheduler
SubSemeseterScheduler holds a list of Schedules each associated with a SubSemester. When adding courseSections the SubSemesterScheduler determines which SubSemester the course affects using withinCourseDuration and then adds the courseSection to the affected Schedule. For removal, atm every Schedule attempts to remove the courseSection. Since the number of comparisons are relatively low and each operation is cheap, the approach should work fine. Additionally, SubSemesterScheduler also adds the affected subsemester to the ScheduleConflict error.

Part of this PR was to ensure the Schedule had no concept of subsemesters, keep it such that a Schedule only operates with courseSections. My thinking is for Schedule to only be concerned with ScheduleConflict between courseSections. Other concepts like courses or subsemesters or semesters should be handled outside of Schedule.

Overview of Front-end Components:
The basic design is Main contains various components that each have their own function. Any state that involves more than one child component is hoisted to Main and children components make changes through events. This can be seen in selectedCourses which is affected by/affects CourseList, SelectedCourses, Schedules. The management of Schedules could be moved to a separate module along with the scheduler, but for now that functionality resides in Main.

Additionally, an attempt was made to move common functionality into reusable modules. ColorService was made into a singleton. Mixins were created for TimeDateMixin and Notifications, however after further research, it is probably better to move away from mixins.
Honestly im rambling im tired lol

[CoreyBuckley]

Sort by start date

[CoreyBuckley]

Honestly, very impressive. Nice job.

Yes, export to ICS still works.

I have one maybe controversial thought:

If I have one 12-week course and one 6-week course, then there's bound to be overlap. However, if I look at that 12-week subsemester, I will not see the 6-week course.

E.g.

12-week view

6-week view

COMM-2520 doesn't show up in the 12-week view. Should it? IMO, feel like it makes logical sense for it to appear, but I can see why you don't show it.

I'm starting to feel like a date range / configurable timeline makes most sense from a user perspective. Similar to one of these:

Date range

Configurable timeline (forgive my quick CSS art, couldn't find a good pic)

(Would have built in 'ticks' on the slider for each possible course start / end date)

Future feature? 😅

[123joshuawu]

Yeah I like the idea of being able to see stuff on one schedule.
One of the designs during the brainstorms that I really liked was something like this

Hopefully just by looking at it it should be pretty clear which subsemester each course belongs to.
The left and right halves are two variations on the spacing/border placements. But the main idea was to show all the courses in one schedule and have half blocks for each subsemester.
But we eventually went with the toggle.

[CoreyBuckley]

I like the idea, I just think there's still a possibility to misinterpret it. A user misinterpreting the distinction of subsemester possibly means they attend a non-going class. 😅

I think if you included the start date on the schedule event for those courses in that later 6-week half it'd be much more obvious.

Example: (pay no attention to the real course start dates)

Other than that, I think I prefer it TBH.

[123joshuawu]

Yeah the only thing is if the day came and RPI decided to do three subsemesters instead of two, then we'd have to redesign again lol.

[jshom]

This, is, so, cool!
Just one thing, seems when I click a course the event is not filling in with any info. Can you add class.title and class.section. thx!

[jshom]

Also, the whole semester (05/25-08/20) should not be an option in the dropdown. There are in practice two parts of the semester. We can defer this to a solution where in the admin panel we select which date ranges map to which "semester parts" then we can show semester part.

So example:
date range (05/25-08/20) belongs to part1 and part 2
date range (07/12-08/20) belong only to part 2

Then we would show in dropdown part 1, part 2 instead of unnamed date ranges

What you think? No need to build now, after cal event change we should be good for merge.

[123joshuawu]

@jshom Yeah I like the use of 'semester parts' over date ranges, that's a really good idea.

As for the event not showing info, I had the issue a little back but it should be fixed by now, make sure you have all the recent commits.
Displaying the course information is going to be a little problematic right now just because the Schedule and its child ScheduleEvent only have access to the CourseSession. I'm planning on moving Course, CourseSection, and CourseSession to centralized store some time soon which will fix this issue, but for now, it just shows crn and section number.