fix: schedule html parser not parsing all courses

[limwa]

This PR fixes an issue with the schedule HTML parser where the parser would only parse the classes from the first course of each student.

Review checklist

• Terms and conditions reflect the current change
• Contains enough appropriate tests
• If aimed at production, writes a new summary in whatsnew/whatsnew-pt-PT
• Properly adds an entry in changelog.md with the change
• If PR includes UI updates/additions, its description has screenshots
• Behavior is as expected
• Clean, well-structured code

[limwa]

@bdmendes @LuisDuarte1 this one is ready as well, after I format the code 😎

[bdmendes]

I'm not really seeing what is changed. Shouldn't this be equivalent to zipping?

[limwa]

By the way, even with this PR, the parser is not parsing the HTML perfectly. However, this PR makes it parse stuff at least.

[limwa]

I'm not really seeing what is changed. Shouldn't this be equivalent to zipping?

That's why I changed the code to make it a bit clearer.

With IterableZip: IterableZip([1, 2, 3], [4]) -> [[1, 4]]
Without IterableZip: [1, 2, 3].map((e) => [e, 4]) -> [[1, 4], [2, 4], [3, 4]]

[codecov]

Codecov Report

Merging #982 (4699efb) into master (7558258) will decrease coverage by 0%.
Report is 1 commits behind head on master.
The diff coverage is 100%.

Additional details and impacted files

@@          Coverage Diff          @@
##           master   #982   +/-   ##
=====================================
- Coverage      23%    23%   -0%     
=====================================
  Files         143    143           
  Lines        4349   4348    -1     
=====================================
- Hits          964    959    -5     
- Misses       3385   3389    +4     

[limwa]

The idea is that IterableZip stops when it reaches the end of one of the iterables. When a user has 5 courses, but the network router only returns 1 URL (my case), only the first course is parsed (because IterableZip reached the end of the URLs list)

[LuisDuarte1]

While I didn't think about the iterablezip bug at the time, I think that this won't work on a session with multiple faculties and different courses between them? The logic seems too hacky as you described in a comment

[limwa]

While I didn't think about the iterablezip bug at the time, I think that this won't work on a session with multiple faculties and different courses between them? The logic seems too hacky as you described in a comment

Indeed it won't. For instance, if a student has 2 faculties, should I create one element with the first faculty and another with the second faculty? That way, I think it'll work. I'm busy right now but I can implement it in a bit!

[limwa]

While I didn't think about the iterablezip bug at the time, I think that this won't work on a session with multiple faculties and different courses between them? The logic seems too hacky as you described in a comment

Indeed it won't. For instance, if a student has 2 faculties, should I create one element with the first faculty and another with the second faculty? That way, I think it'll work. I'm busy right now but I can implement it in a bit!

@LuisDuarte1 I noticed that the solution I outlined wouldn't work. Mainly because I think that the method that parses the HTML only needs the baseUrl used for the request that fetched the schedule. Therefore, I decided to rework the method a bit.

I am not very happy with the way it is currently, but I can't think of another way to match the baseUrl with the request...

[bdmendes]

This seems correct to me now, as it's getting the classes from all courses in all facilities. This is very hard to test, though.
#797 will guarantee that the chosen faculties are correct.

[LuisDuarte1]

Good work!