`Workouts`: implement active session

[Seerden]

See #5.

Changes

• [x] implement session model in the database (#18)
  • think about extensibility once we redo 'workouts' to be more like standalone progressive 'programs'
• [x] implement client-side view for active workout sessions -- uses suggested working weights and allows user to track performed reps and sets

  Miscellaneous:

• [x] populate individual workouts in query cache from useQueryWorkoutsByUser() onSuccess
• [x] implement a placeholder Home component linking to a few frequently used in-app pages
• [x] add a jestConfig file that imports whatwg-fetch so that render tests don't break in the jsdom testing environment
• [x] add framer motion as a dependency
  • [x] add an AnimatedRoutes wrapper function that wraps our routes with AnimatePresence
• ... (there's more)

[Seerden]

Intermediate partial to-do:

• [x] add created_at field to SessionEntry because we have to be able to sort them by date
• [x] set up types and functionality client-side for activeWorkoutState
  • keep types client-side until we add an endpoint route that suggests initial workout state
• [ ] implement useWorkoutState hook that manages
  • initial state (from backend eventually, but start out with a hardcoded default for now
  • state updates
  • add warmup scheme
  • update scheme fields
  • POST input validation
  • POST mutation

[Seerden]

Current thoughts on state for sessions:

• workout comes from query cache

• suggested weight comes from backend in separate request. Use the form {exercise_ID, weight, reps, sets}, using exercise.reps and exercise.sets for now. Once we implement support for e g. 5/3/1, we won't have to change this data shape.

• use an atom to store session entries. Use a minimal keyless (hashmap-like) object like

  '2': { '60kg': [{ reps: 12, timestamp: 274648383629 }] } 

  Using a hash map like this makes accessing and updating values in state a lot more readable.

• don't use timestamps for reps completed. Just assume the highest weight is the working weight for now when submitting, and mark everything else as a warmup set. Another option is to set a timestamp the first time a value is added but not when it's updated.

• idea: to track warmup sets, use two buttons: add warmup set, add working set

  • it's crucial that we identify the working weight

• include an isActive field in session state, this determines the ActiveExercise we display.

  • handlers need to set isActive to true for an exercise, and set it to false for the previously active exercise
  • needs to be a cycling function that selects the next exercise in session state (by index) automatically on completion of all of the current ActiveExercise's working sets.

[Seerden]

Another progress update:

• implemented happy path for workout exercise suggestions: use starting weight/deload/progressively overload depending on how the user fared on the exercise the last time they performed it.

• I'm doubting the way I've set up the sessionEntries state client-side. It works, but I feel like there should be a cleaner way to go about it.

More tasks:

• [ ] properly handle warm-up exercises.
• suggestWorkout:
  • [ ] make sure we never use warmup sets in our computation
  • [ ] make sure the latest set is used to determine success or fail
  • [ ] include a set_index property or something similarly named in workout_session_entries, this ensures we always have a deterministic way to find the final set performed
• [x] use suggested workout as activeWorkoutState (we were mocking this, before)

[Seerden]

Another feature:

• [ ] include working weight sets performed in SessionLog
  • distinguish failed sets and successful sets by color -- maybe use round icons

[Seerden]

• [ ] style ExerciseRow differently for warmup sets and working weight sets.
• [ ] don't memoize allCompleted, but set state on blur. Currently, allCompleted is set right when the final set changes at all, so a user can never enter '10' as the last set's rep count, because allCompleted becomes 'true' as soon as they type '1'.

[Seerden]

I'm happy with this right now as a first implementation. Been at this for a while already, so I'm creating some spin-off issues to work out some optimizations tweaks, and also tests.