Create admin schedule review table

[7tint]

Ticket link

Closes #156
Closes #158

Implementation description

• Implemented the schedule review table and its table rows, which display all volunteer shifts of a certain week.
• Note that this table implementation is only for displaying the shifts in one week (passed in via props), and does not include the date navigation header.

Steps to test

1. Add the following code to Default.tsx, importing components/variables when necessary:

<Container maxW="container.xl">
  <AdminScheduleTable schedule={TableTestData} />
</Container>

2. Check http://localhost:3000/ to see that TableTestData is rendered correctly. The test data includes three types of table rows, as specified in Schedule review table row #156.

What should reviewers focus on?

• Clean React code, correct separation of concern for the props & states.
• Stay hydrated 💧

Checklist

• My PR name is descriptive and in imperative tense
• My commit messages are descriptive and in imperative tense. My commits are atomic and trivial commits are squashed or fixup'd into non-trivial commits
• I have run the appropriate linter(s)
• I have requested a review from the PL, as well as other devs who have background knowledge on this PR or who will be building on top of this PR

[github-actions]

Visit the preview URL for this PR (updated for commit 47eafa0):

https://sistering-dev--pr206-lambert-schedule-rev-gzcm6kx1.web.app

_{(expires Thu, 07 Apr 2022 23:00:34 GMT)}

_{🔥 via Firebase Hosting GitHub Action 🌎}

[LenaNguyen]

padding for the rows is a little off

I'm pretty sure the horizontal padding should be equal so let's use 47px.
Since the Td elements have their own padding and it would be annoying to remove their padding each time, just add some extra padding to tr. i.e. px="20px", py="2.5px"

[LenaNguyen]

Also for UI changes can you pls add a demo on the default page or something next time 🙏 my docker takes a million years to start so sometimes it's much faster to use the firebase preview. The downside is you'd have to remove it after get another approval tho.

[LenaNguyen]

padding for the rows is a little off

I'm pretty sure the horizontal padding should be equal so let's use 47px. Since the Td elements have their own padding and it would be annoying to remove their padding each time, just add some extra padding to tr. i.e. px="20px", py="2.5px"

Actually idk if this is that important @sherryhli . If we change the theme to accommodate for this padding then other places where we use a Tr but isn't formatted like this will need to be changed. The default spacing from Chakra also looks fine.

[sherryhli]

Nice! 🔥 Some small code improvement suggestions and a minor UI deviation, LGTM otherwise!

[sherryhli]

padding for the rows is a little off
I'm pretty sure the horizontal padding should be equal so let's use 47px. Since the Td elements have their own padding and it would be annoying to remove their padding each time, just add some extra padding to tr. i.e. px="20px", py="2.5px"

Actually idk if this is that important @sherryhli . If we change the theme to accommodate for this padding then other places where we use a Tr but isn't formatted like this will need to be changed. The default spacing from Chakra also looks fine.

@LenaNguyen Yeah I'm for staying consistent to a single theme variant if possible, could we check with design to see if this small deviation is okay?

[sherryhli]

Just realized something: with the way we plan on fetching data for the schedule creation frontend (running a query on the signups table rather than shifts), we wouldn't know about any shifts without signups. That means the row type below would not be seen, and the shift would also not be shown as a dot in the calendar.

cc @JoshuaYe @LenaNguyen Do you have any input on the necessity and priority of this feature? How useful is it to view shifts that do not have any signups in schedule creation?

(@lambo-liu no change needed for now, please keep this row type in the code)

[LenaNguyen]

Just realized something: with the way we plan on fetching data for the schedule creation frontend (running a query on the signups table rather than shifts), we wouldn't know about any shifts without signups. That means the row type below would not be seen, and the shift would also not be shown as a dot in the calendar.

cc @JoshuaYe @LenaNguyen Do you have any input on the necessity and priority of this feature? How useful is it to view shifts that do not have any signups in schedule creation?

(@lambo-liu no change needed for now, please keep this row type in the code)

It seems useful to know that there are some shifts that no one is registered for in the overview

[LenaNguyen]

LGTM!