feature/drag-and-drop schedules

[jotalis]

Summary

Drag-And-Drop

• Implemented vertically-locked drag-and-drop functionality in the schedule select dropdown, allowing users to reorder schedules
• Added support for desktop, mobile, and also keyboard accessibility (users can also reorder schedules using tabbing and arrow keys)
• Reordering schedules is now treated as an "unsaved" action and cached in local storage. This allows users to retain and reload their unsaved schedule reordering changes even after refreshing the page

Bug Fixes

• Resolved an issue where duplicating a schedule that was not currently selected would incorrectly create a new schedule containing the events of the currently selected schedule, instead of duplicating the intended schedule

Misc

• Added a disabled cursor for the schedule note text input when in skeleton mode
• Made schedule name tooltip offset consistent with toolbar button tooltip offset

Note
Previously, a list of scheduleNames was passed down as a prop to the SelectSchedulePopover component. For implementing reordering via a sortable dnd list, each scheduleName must be mapped to a unique ID because we can't assume all scheduleNames are unique yet.
To address this:

1. A schedule mapping is created, which is really an array of objects where each object contains a scheduleName and its unique id (in this case, its original index in the list).
2. Upon reordering schedules:
   • This local mapping is updated by swapping elements within the array using the schedules' unique IDs
   • The updated schedule order is also reflected in the AppStore.ts saved schedule array
   • The currentScheduleIndex in AppStore is recalculated accordingly.

Important: The local mapping is not fully recreated after every reordering action. Instead, only the swapped elements are updated. The local mapping is only recreated during a complete component re-render. If we were to fully recreate the mapping on every reorder, it would disrupt:

• The DND animations / transitions
• The index selector mapping for each toolbar button, causing inconsistencies

Test Plan

• Ensure toolbar buttons correctly map to the reordered schedules after swapping
  • Swap around schedules and just ensure that the button popups display the correct text and perform the actions (Copy, Delete, Rename) correctly
• Ensure all schedule actions are saved as "unsaved" actions and can be reloaded correctly
  • Create 2-3 schedules with some events, Save to any username with Remember Me checked, Try various combinations of schedule actions (create new schedules, delete some, reorder some, rename some, etc), reload the page, load unsaved changes and make sure the schedule state is the same
• Ensure schedule reordering is disabled in skeleton mode
  • Force skeleton mode by blocking network requests to https://dev.api.antalmanac.com/trpc/websoc
• Ensure schedule swapping works on or via different interfaces (mobile, desktop, tabbing)
• Ensure styling looks fine for hover tooltips
• Ensure styling looks fine for skeleton mode schedule note input

Issues

Closes #1054

[MinhxNguyen7]

For implementing reordering via a sortable dnd list, each scheduleName must be mapped to a unique ID because we can't assume all scheduleNames are unique yet.

That is the case now because of the RDS migration. All duplicate schedule names have been mangled.

Looks pretty good, and well-detailed PR description as well. I'll try to look at this soon.

[MinhxNguyen7]

Drag icon is not visible in light mode

[MinhxNguyen7]

@adcockdalton remember to review this. It's marked changes requested because I requested changes, but that has been addressed.

[adcockdalton]

Firstly I must apologize for the incredible delay on reviewing this. It's a useful PR and very well done and written up; it was disrespectful of me to lose track of it.

As for the PR itself, it looks great for the most part, but I had a couple issues. I'll explain how to repro:

1. On reload with unsaved changes, deleted classes are only remembered to have been deleted for what seems to be the "root" schedule.

• Add 2-3 schedules
• Add classes to each
• Save
• Delete one class from each (don't save)
• Reload and check yes to load unsaved changes

You will be redirected to the "root" schedule, for which the class will be deleted (expected behavior in agreement with the main branch). The other schedules will not have their class deleted.

To follow-up with this, it also seems appropriate (if easily implementable from where we are now, since I'd like to merge this in soon) to also remember which schedule was being viewed on reload (without saving).

2. I couldn't get mobile reordering via touch-scroll to work on my end. This could just be a chrome devtools issue though--is it currently working for you?

--

I also wanted to ask about your reasoning behind the tooltips:

I'm pretty sure tooltips have to encode additional information in order to be useful for accessibility: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/tooltip_role , but I could be wrong on that--I'm not very familiar with screen readers and the like.

--

LGTM: all other unsaved changes features, tabbing, light mode

[jotalis]

The saving issue seems to be a problem on prod as well. I'll look into why and get it fixed.

The main point of the tooltip is to provide the full length of the schedule name if it exceeds the display limit and is omitted with ellipses. Currently, its behavior renders a tooltip for every schedule name regardless of whether the schedule name length exceeds the display length. This behavior is consistent with prod and can be reworked, if needed, in another PR. This PR just improves the styling of the tooltip offsets.