// running/src/whatIfView.jsx โ the Simulate tab.
//
// "What happens to my race if I train differently?" Move the sliders, watch
// the fitness curve and the injury-risk band respond.
//
// The panel is organised around lib/whatIf.js's three tiers of claim and it
// renders them differently ON PURPOSE, because a reader who cannot tell them
// apart will believe the weakest one as hard as the strongest:
//
// - the load projection (CTL / form / acute:chronic) is arithmetic on the
// plan and is always shown;
// - the race-fitness projection is fitted from this athlete's own history
// and always carries its rยฒ, its sample count and its clamp;
// - when the fit doesn't hold, the projection is ABSENT and the reason is
// printed where the number would have been. An empty space with an
// explanation is the honest rendering; a greyed-out number is not.
//
// Nothing here writes anything. It is a calculator over data the app already
// holds, so a scenario can be as reckless as the athlete wants to imagine.
const { C, Card, Stat, EmptyState, ChartTooltip } = window.SharedUI;
const useData = () => (window.__appUseData ? window.__appUseData() : null);
const { useState, useMemo } = React;
const {
Line, Area, ComposedChart, XAxis, YAxis, CartesianGrid, Tooltip,
ResponsiveContainer, ReferenceLine,
} = Recharts;
const WI = window.WhatIf;
// A slider that reads as a number you set, not a control you drag.
function Knob({ label, value, min, max, step, unit, onChange, hint }) {
return (
);
}
function WhatIfView({ activities }) {
const { athleteProfile, activePlan, trainingSnapshot } = useData() || {};
const runs = useMemo(
() => (activities || []).filter(a => window.RaceMath && window.RaceMath.isTrainingRun(a)),
[activities]);
// Seed from the athlete's actual state so the panel opens on "carry on
// as you are" โ the baseline every scenario is read against.
const currentMiles = useMemo(() => {
const snap = trainingSnapshot?.volume?.weeklyMilesAvg4w;
if (Number.isFinite(snap) && snap > 0) return Math.round(snap);
const t = window.RaceMath && window.RaceMath.trailingWeeklyMiles(runs);
return t ? Math.round(t) : null;
}, [trainingSnapshot, runs]);
// Weeks to the next race, from the active plan if there is one.
const planWeeks = useMemo(() => {
const d = activePlan && (activePlan.raceDate || activePlan.goalRaceDate);
if (!d) return null;
const ms = Date.parse(d);
if (!Number.isFinite(ms)) return null;
const w = Math.round((ms - Date.now()) / (7 * 86400000));
return w >= 2 && w <= 52 ? w : null;
}, [activePlan]);
const [weeksOut, setWeeksOut] = useState(() => planWeeks || 12);
const [targetMiles, setTargetMiles] = useState(() => currentMiles || 40);
const [qualityDays, setQualityDays] = useState(2);
const [taperWeeks, setTaperWeeks] = useState(3);
const [seeded, setSeeded] = useState(false);
// Seed once the athlete's own numbers arrive, then leave the athlete's
// edits alone โ re-seeding on every data tick would yank the sliders
// back mid-thought.
if (!seeded && currentMiles) {
setTargetMiles(currentMiles);
if (planWeeks) setWeeksOut(planWeeks);
setSeeded(true);
}
const hr = { maxHR: athleteProfile?.maxHR, restHR: athleteProfile?.restingHR };
// Both scenarios in one pass: the one being edited, and the do-nothing
// baseline it is being compared with. A projection with no baseline is
// a number without a question.
const sim = useMemo(() => {
if (!WI || !runs.length || !currentMiles) return null;
const common = { activities: runs, ...hr, weeksOut, currentWeeklyMiles: currentMiles };
return {
scenario: WI.simulate({ ...common, scenario: { targetWeeklyMiles: targetMiles, qualityDaysPerWeek: qualityDays, taperWeeks } }),
baseline: WI.simulate({ ...common, scenario: { targetWeeklyMiles: currentMiles, qualityDaysPerWeek: qualityDays, taperWeeks } }),
};
}, [runs, currentMiles, weeksOut, targetMiles, qualityDays, taperWeeks, hr.maxHR, hr.restHR]);
if (!WI) return null;
if (!runs.length || !currentMiles) {
return (
);
}
const s = sim && sim.scenario;
if (!s || !s.available) {
return (
);
}
const base = sim.baseline && sim.baseline.available ? sim.baseline : null;
const chart = s.weeks.map((w, i) => ({
name: `W${w.weekNum}`,
ctl: w.ctl, tsb: w.tsb, acwr: w.acwr, miles: w.miles,
baseCtl: base && base.weeks[i] ? base.weeks[i].ctl : null,
}));
const deltaCtl = base && base.raceDay ? Math.round((s.raceDay.ctl - base.raceDay.ctl) * 10) / 10 : null;
const risky = s.risk.weeksAboveAcwr.length > 0;
// The fitted tier, or the reason there isn't one.
const f = s.fitness;
// The slope came with a particular mix of training. Adding easy volume
// and expecting the gain that arrived alongside two workouts a week is
// the specific mistake worth interrupting.
const mixDrift = f && f.historicalQualityShare != null &&
(qualityDays / 6) < f.historicalQualityShare * 0.6;
// The implied time goes through predictRaceTimes, the same path the
// Races page uses โ not danielsPredict directly. Raw Daniels has no
// endurance adjustment, so it would quote a marathon this athlete's
// volume doesn't support and disagree with the projection they already
// have. The scenario's own BUILD volume is what feeds that adjustment:
// in a simulation the relevant mileage is the one being simulated, and
// more volume legitimately helps the marathon twice โ through fitness
// and through the endurance exponent.
// Plain computation, not useMemo: this sits after the early returns
// above, and a hook that only runs on some renders desynchronises React's
// hook order for the whole component.
const buildWeeksOnly = s.weeks.filter(w => w.phase !== "taper");
const buildMiles = buildWeeksOnly.length
? buildWeeksOnly.reduce((sum, w) => sum + w.miles, 0) / buildWeeksOnly.length : null;
const RACE_METERS = { "5K": 5000, "10K": 10000, "Half Marathon": 21097, "Marathon": 42195 };
const raceName = (activePlan && RACE_METERS[activePlan.raceDistance]) ? activePlan.raceDistance : "Marathon";
const impliedTime = (vo2) => {
const RM = window.RaceMath;
if (!RM || !RM.predictRaceTimes || !vo2) return null;
const rows = RM.predictRaceTimes(vo2, runs, null, {
maxHR: hr.maxHR, avgWeeklyMiles: buildMiles || undefined,
});
const row = (rows || []).find(r => r.name === raceName);
if (!row || !row.seconds) return null;
const sec = Math.round(row.seconds);
const h = Math.floor(sec / 3600), m = Math.round((sec % 3600) / 60);
return h > 0 ? `${h}:${String(m).padStart(2, "0")}` : `${m} min`;
};
return (
Simulate
Change the block and see where it lands โ against carrying on exactly as you are.
The block ramps at no more than {Math.round(WI.MAX_RAMP_PCT * 100)}% a week with a cutback every fourth,
and costs your own {s.rates.easyPerMile} TRIMP per easy mile and {s.rates.qualityPerMile} per quality mile โ
measured from {s.rates.easyRuns + s.rates.qualityRuns} of your runs, not from a table.
{s.rates.inferredQualityRate && " You have no logged workouts, so the quality rate is your easy rate โ treat any change in quality days as unmodelled."}
Fitness, form and acute:chronic ratio are the load model evaluated forward through this plan. Not a prediction โ arithmetic on the training you'd do.
0 ? `+${deltaCtl}` : String(deltaCtl))} unit="CTL"
color={deltaCtl == null ? C.textDim : deltaCtl > 0 ? C.green : C.textDim} />
{/* Form has a ceiling as well as a floor. Arriving at +35 is not
twice as good as +18 โ it means the taper ran long enough to
start giving back the fitness the block bought, which reads
as "extra fresh" and races as flat. */}
30 ? C.amber : s.raceDay.tsb >= 5 ? C.green : s.raceDay.tsb >= -5 ? C.amber : C.red} />
1.3 ? C.amber : C.green} />
0.15 ? C.amber : C.textDim} />
โ fitness (CTL)โ if you hold steadyโ form (TSB)
} />
{s.raceDay.tsb > 30 && (
Over-tapered
You arrive at {Math.round(s.raceDay.tsb)} form, well past the +15 to +25 a race taper is aiming for.
Past that the taper is handing back fitness rather than fatigue โ shorten it, or keep more volume in it.
Acute load runs more than 1.5ร chronic there โ the band where injury rates rise sharply (Williams 2017).
Lower the target, add weeks, or accept the risk knowingly.
Turning fitness into a race time needs a loadโspeed relationship, and there is no general one โ only yours.
No race-time projection
{s.timeProjectionReason}. The load projection above still holds โ it doesn't depend on this.
) : (
<>
Fitted from {f.samples} points across your own history, rยฒ {f.r2.toFixed(2)}. An association between your training load and your
measured fitness โ not a law, and not a promise. Read off the block's peak load
({Math.round(f.fromCtl)} CTL), not race day: a taper lowers CTL deliberately and does not lower fitness.
This block projects {f.beyondBy} CTL past the highest training load you have ever held, so the
projection is held at that ceiling rather than carried up a straight line. Training beyond your
history may well work โ this has no evidence about it either way, and would rather show you nothing
than an extrapolated time.
)}
{mixDrift && (
Different training to the fit
The gain above came alongside {Math.round(f.historicalQualityShare * 100)}% of your miles run as quality.
This scenario runs {qualityDays} workout{qualityDays === 1 ? "" : "s"} a week, which is a lot less.
Extra easy volume is not the training that produced this relationship.
)}
)}
Nothing here is saved and nothing here changes your plan. Load, form and the acute:chronic ratio use the same
models as the Status page, so a number moved here means the same thing it means there.