-
Notifications
You must be signed in to change notification settings - Fork 11
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
Remove as2 #618
Merged
Merged
Remove as2 #618
Changes from 8 commits
Commits
Show all changes
10 commits
Select commit
Hold shift + click to select a range
e476b18
Implemented year inference
zachary-kent a1fd6d1
Fixed issue with as needing to be clicked twice
zachary-kent b06281d
Fixed linter errors
zachary-kent 347c63d
Merge branch 'master' into remove-as2
willespencer c0124bb
Fix bug where A&S disappears from college choice
willespencer ad239dc
Factor out setting AS function
willespencer b37b494
Merge branch 'master' into remove-as2
willespencer 32637e6
Update AS check to be dependent on season
willespencer af71832
Remove pre/post 2020 text in reqs bar
willespencer b6be5c3
Move AS check to utilities to return in all locations
willespencer File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we be doing a special case here instead of changing the JSON directly?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This question is totally fair, and it's due to an inconsistency with the frontend and "backend" (how we represent requirements data).
A&S before and after 2020 have different requirements. They are represented as
AS1
andAS2
in our requirements data. That is, they are considered separate colleges (because we assume one college = one set of requirements). On the frontend, we want the user to see it as a merged college, i.e.AS
. So, Zak decided to implement this as a frontend-only change by writing conversions between these two representations. An upside of this is that the backend format can stay the same. A downside of this is that A&S needs to be special-cased in few different places.An alternative implementation would have been something along the lines of adding variants to the requirements data format. So, the backend would look something like
AS:Version1
andAS:Version2
, whereAS
refers to a single college andVersion1
andVersion2
refer to different sets of requirements (we now assume one college = one or more sets of requirements). An upside would be that it would be more extensible -- that is, other colleges can have multiple versions as well (which is great if requirements are changed relatively frequently). A downside would be that every other college would have to support this added complexity (for example,EN
would need to turn intoEN:Version1
orEN:Default
, both in the requirements data and in our user database). There are probably ways to avoid this downside by making the new format backwards-compatible, but that also comes with its pros and cons (see how we implementedadditionalRequirements
).I personally think a single special case like this is fine. But if there are more special cases to be added in the future, or if we somehow manage to reach the backlog, I think there should be a refactoring effort.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for explaining that Ben! If we ever have a chance to refactor this to use the alternate implementation you mentioned, that could allow us to handle more specific cases of requirements changing over time (such as the Probability and Stats requirement for ECE). It's definitely down the line, but it could be useful for our users and help to reduce some confusion.