Add course uuids as query parameter on schedules page

[Bad-Science]

We have received a request to be able to link to the schedule ui by providing a list of course uuids (and optionally a term uuid). The schedule view page should detect if these parameters have been provided, and if so, use those params to request schedules, rather than the user's stored selections.

Additionally, there should be some indication in the ui that the scheduler is using the params in the link the user clicked on, rather than their stored selections. There should be a button the user can click to clear the url params, and return to using their stored selections.

It would also be really nice if the user had the ability to save these courses to their selections automatically and/or interact with them in the sidebar, but I don't think this is entirely necessary.

Any additional comments @NeverBehave?

[NeverBehave]

I come up with this idea when I dig into the XHRs made by YACS. e.g. https://yacs.cs.rpi.edu/api/v5/schedules.json?section_ids=13298,13369,13371,13373&show_periods=true&

And I have just realized that YACS may have a stored plan. What I have done in organizer is that I make a state to store all plans so that user could choose to load different plans, and when importing the plan from the link, it just add a new one. e.g.

Page: https://plan.v2grad.org/profile Import Example: https://tinyurl.com/y7e3qynh

But I think it is OK just set up a page and that accept some parameters and generate the schedules without storing into the user localstorage. So it is a read-only version and once leave this page it disappears.

And I think it is also OK to make it a separate modules (serve under a sub domain as plan preview only.) as it may require lots of work to implement the whole storage/import/export function.

[Bad-Science]

So we actually have being able to store different "plans" on our roadmap, but right now I'm not sure where it is in terms of priority. We have a login/auth service that we can use to persistently store these things, but we haven't started using it yet. It is actually a separate service/module like you suggested, but will eventually be tightly integrated into the rest of Yacs. It wouldn't be particularly hard to do, and there is a lot I want to do with stored plans/schedules once they are implemented.

So for the short term, I think like you said just having a page that accepts parameters solves the problem, and I think that makes the most sense to do right now.

But we should explore the possibility for a deeper integration with stored plans in Yacs in the future, and I'd love to get your input on how we should implement this in Yacs since you have done something very similar in Organizer.

[NeverBehave]

What I actually do for the store is that I have a separate state object for a plan and I just replace it when I need to switch. I have not yet dig into how yacs build but I think this is the easiest way to accomplish the goal.

For the export and import, I just simply turn the whole object into JSON, use deflate to compress the string, and base64 url safe mode to turn the binary to a url safe string. Example can be found here: https://runkit.com/neverbehave/deflate-test