Use a single mutable location, event, slot, etc, for each unique
resource that keeps track of the local editable client copy and
the server copy of the data contained in it.
This makes it much simpler to update these data structures as I can take
advantage of the v-model bindings in Vue.js and work with the system
instead of against it.
Use the ClientSchedule data structure for deserialising and tracking
edit state on the client instead of trying to directly deal with the
ApiSchedule type which is not build for ease of edits or rendering.
Implement tracking of time slots along with editing and restoration of
singularly edited time slots. This provides a simpler interface to work
with when rendering tables of time slots that can be edited than
directly manipulating events and shifts containing an array of slots.
To determine if the entity received from the server is the same as the
entity the client has the equals method is use. To avoid problems with
clients that have incorrect clocks the timestamp is overriden with the
server's time when the entities are saved on the server.
This means that the entities received back from the server when the
client saves will have different timestamps than what the client set.
Ignore the updatedAt timestamp when comparing entities for equality so
that the update logic correctly replaces entities that only differ by
the update timestamp.
If the event/shift that a location/role was referencing had been marked
for deletion the sanity check would incorrectly refuse to delete the
event/role. Fix by ignoring deleted events/shifts.
Add utility methods to more easily edit the fields of a single entity in
the schedule, along with a modification flag and is modified utility to
check for changes having been made.
The Vue Ref system and assiated proxies does not work with the native
EcmaScript private fields, replace them with the TypeScript access
modifiers which are regular fields under the hood.
Write the logic of keeping track of location modifications and applying
updates from the server into the ClientSchedule class. This should
serve as the foundation for replacing the prototype in-component update
logic which have turned into an unmaintainable spagetti.
