Fixing "next match" feature

[varCepheid]

closes #1493
At the top of the event and event-team pages, instead of one "next match," the page shows the three most relevant upcoming matches.

[calebeby]

Hey @varCepheid, usually the scheduled match time and the predicted match time are wrong by 5-10 minutes. Do you think that instead of this solution we could show "upcoming matches" as 2-3 matches?

[ev118]

I think the problem has been solved, though a bit of tweaking may be useful so that it looks neat (the Upcoming Matches header is off-center, even though it says justify-self: center; and the search bar sits right on top of Qual 1).

[calebeby]

Hey @ev118, thanks for updating this! I think there are several opportunities to simplify the approach here, would you be open to scheduling a meeting this weekend to work through that with me?

[calebeby]

@varCepheid can you delete commented-out code from this PR? Generally it is good practice to try to avoid committing commented-out code to dev/main branches.

[varCepheid]

Can you delete commented-out code from this PR? Generally it is good practice to try to avoid committing commented-out code to dev/main branches.
@calebeby Done.

[calebeby]

@varCepheid I also noticed that the issue #1493 is kind of vague and doesn't mention whether it is talking about the next match feature on the team@event page or on the event page. This PR only fixes the team@event page, so maybe we should leave that issue open when this is merged and open another PR for the event page.

[varCepheid]

I agree that the issue is vague. I added a description on the PR, which is hopefully more clear. And the changes here do affect the event page; if it wasn't doing anything different, we should definitely fix that here.

[varCepheid]

When I merged from dev, it brought a bunch of changes to package-lock.json. I tried to deal with all of them, but the file is so large that it was lagging a lot, and I think I made a mistake somewhere. Should I try to revert the commit?

[calebeby]

@varCepheid sorry for not getting back to you sooner. You shouldn't ever need to manually merge a package-lock.json file. You can always just checkout the package-lock.json from either side of the merge, and then run npm i to make npm fix any issues or discrepancies from the package.json file. In this case, there are no changes to package.json so we don't even need to do that. Since the changes to package-lock.json aren't relevant to this PR, I went ahead and reverted them. (git checkout origin/dev -- package-lock.json is the easiest way to do this for a single file without necessarily reverting an entire commit, it just means "set this file to as it was on _ branch").

[varCepheid]

Is there anything else that you need to review, or is this ready to push?