the ugly organization - lifts front-end

export function UserConfigProvider({ children }: { children: React.ReactNode }) {
  const exercises = new Map<ExerciseType, [number, Dispatch<SetStateAction<number>>]>();
  exercises.set(ExerciseType.BENCH_PRESS, useState<number>(103));
  exercises.set(ExerciseType.BACK_SQUAT, useState<number>(110));
  exercises.set(ExerciseType.WEIGHTED_PULLUPS, useState<number>(116));
  exercises.set(ExerciseType.DL, useState<number>(120));
  exercises.set(ExerciseType.OHP, useState<number>(70));

  const lastExercises = new Map<ExerciseType, [number, Dispatch<SetStateAction<number>>]>();
  lastExercises.set(ExerciseType.BENCH_PRESS, useState<number>(0));
  lastExercises.set(ExerciseType.BACK_SQUAT, useState<number>(0));
  lastExercises.set(ExerciseType.WEIGHTED_PULLUPS, useState<number>(0));
  lastExercises.set(ExerciseType.DL, useState<number>(0));
  lastExercises.set(ExerciseType.OHP, useState<number>(0));

  const use90tm = useState<boolean>(false);

  const userConfig: UserConfig = {
    exercises,
    use90tm,
    lastExercises,
  };

  return (
    <UserConfigContext.Provider value={userConfig}>
      {children}
    </UserConfigContext.Provider>
  );
}

Me sorprende que esto funcione, ¿no estas usando linters? Esos hooks deberían estar en el top level del componente y ser inicializados ahi antes de meterlo en el Map. Also, xq usas un Map, un simple objeto no te vale?

React nunca se penso para ser mas alla de una libreria que proporcionase updates eficientes de UI via one-way data bindings y VDOM. Este approach era radicalmente más eficiente y proporcionaba una mejor DX (y ademas era muchisimo más fácil de aprender) que lo que se usaba por entonces, básicamente Angular y su monstruosa strong opinions en todo (servicios, controladores, etc), lo que le hacia tremendamente inapropiado para dos cosas fundamentales en aquellos años de dinero gratis: iterar rápido y que cualquier pelagatos que ficharas fuera "eficiente" montando una UI. En este sentido fue todo un exito. El "problema" es que no te proporcionaba nada a nivel de arquitectura, data handling, etc, de ahi que se iterara cn movidas cn Flux y luego Redux. Ademas, el paradigma de reducers en UI es super facil de entender y prototipar con el, de ahi su exito. Y precisamente ser TAN EXPLICITO proporcionaba una clara vision de la app solo viendo la store.

useState y useReducer no deberian ser usados para estados globales, no se pensaron para eso. useReducer es sugar syntax alrededor de useState para hacerlo más eficiente y cercano al paradigma imperante, Redux, y ni siquiera eso, ya q React tiene cierta capacidad de batching cuando se encuentra con varios useState seguidos.

Para estados globales, incluso para estado de componente, hoy en dia se usa Jotai o Zustand, que no requieren Providers.

Se ha pretendido convertir a React en algo que NO es, de ahi el monton de mierda que se sta comiendo ultimanete. Hasta que salga 19, si es hoy en dia un pifostio importante que obliga al dev a pensar constamente en microoptimizaciones (useCallback y useMemo) y hacer cosas mierders, xq su paradigma ya esta mas q agotado, de ahi que Facebook pase ya de el y se lo haya "cedido" a Vercel practicamente.

Paralelamente hay cosas radicalmente diferentes como Svelte o SolidJS, especialmente Svelte que es sexo duro, que deprecan la DX de React.

Also en

https://github.com/vrnvu/lifts/blob/master/src/components/Benchmark.tsx,

podrias hacer un custom hook para get/set sin necesidad de escribir tanto codigo, incluso si atomizaras eso cn Jotai por ejemplo, te quedaria mejor. Sin olvidar que toda esa computacion se va a repetir una y otra vez en cada render, quizas si seria adecuado meter useCallback y useMemo