refactor: Events and events.json

[KevinWu098]

Summary

1. Refactored the events page and cleaned up the HTML for consistency and edge cases
2. Simplified / converted manual updating of events from current to past with filtering
3. Times should now be provided as an ISO time string (ex: 2023-10-13)
4. ISO Strings are first compared (for past/upcoming), then converted with toLocaleDateString() for the UI

Page Preview

Test Plan

1. New events, of the correct ISO time format, should properly display under upcoming events.
2. Past events, of either correct time format or not, should properly display under past events.
3. The modals and all related details (look, content, show/hide) should still work as intended

Issues

Closes #87

Future Followup

1. Handle multi-day events feat: Add support for multi-day events #89
2. Handle events without images fix: Handle events without Images #94

[ryanmohta]

Just popping by since this seemed like an interesting PR; I like the idea behind it but have a couple suggestions for the execution. Instead of storing event dates in events.json as formatted strings like Friday, June 23rd, 2023, I would suggest storing them as ISO date strings like 2023-06-23 and formatting them how you want in the front-end using the toLocaleString method and an options object. This would make it super easy to compare event dates with each other and today’s date, and would remove the complexity of creating your own way to obtain the date object from a formatted string.

I also noticed, while looking at events.json, that neither of our methods work for multi-day events like WebJam, so I’m thinking we could get around this by splitting up the time property in each event object into separate startTime and endTime properties, and figure out a good way to represent it in the front-end depending on whether it’s a single or multi-day event. Might be something for a future PR though, since it’s a bit more complex

[KevinWu098]

Just popping by since this seemed like an interesting PR; I like the idea behind it but have a couple suggestions for the execution. Instead of storing event dates in events.json as formatted strings like Friday, June 23rd, 2023, I would suggest storing them as ISO date strings like 2023-06-23 and formatting them how you want in the front-end using the toLocaleString method and an options object. This would make it super easy to compare event dates with each other and today’s date, and would remove the complexity of creating your own way to obtain the date object from a formatted string.

I also noticed, while looking at events.json, that neither of our methods work for multi-day events like WebJam, so I’m thinking we could get around this by splitting up the time property in each event object into separate startTime and endTime properties, and figure out a good way to represent it in the front-end depending on whether it’s a single or multi-day event. Might be something for a future PR though, since it’s a bit more complex

:)) Thanks for the input! Simplifying the event date storage is definitely a smarter implementation, and I'll have that pushed ASAP!

Do agree on the multi-day point (and the scope), so I'll kick that down the road to another Issue/PR!

[sirAvent]

Just a small change on the Next Image tags!

[sirAvent]

Looks good! Great work on simplifying the data handling!