Centralize weight use cases in DI container

[marcuscastelo]

Refactor weight use cases to be centralized in the DI container, removing backward-compatible shims and breaking circular dependencies. Migrate all consumers to utilize the new structure, ensuring type safety and preparing for future enhancements. Document progress and remaining tasks in the migration plan.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
macroflows	Ready	Preview, Comment	Mar 23, 2026 6:33pm

[Copilot]

Pull request overview

This PR centralizes weight and weight-chart use-cases in the DI container to eliminate circular dependencies and remove backward-compatible shims. The refactoring introduces granular dependency interfaces (WeightUseCasesDeps, WeightChartDeps) that accept only the minimal required dependencies instead of the full useCases object, breaking circular import chains. All consumers (8 files) are migrated to access these use-cases through useCases.weightUseCases() and useCases.weightChartUseCases().

Key changes:

• Removed circular useCases import from weightUseCases.ts by making authDeps a required parameter
• Centralized both weightUseCases and weightChartUseCases in the DI container
• Removed backward-compatible shims from both factories

Reviewed changes

Copilot reviewed 13 out of 13 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
src/di/useCases.ts	Added weightUseCases and weightChartUseCases to centralized container, wired with granular dependencies to avoid circular imports
src/di/container.tsx	Extended Container type with WeightUseCases, created default weight use-cases with auth dependencies
src/modules/weight/application/weight/usecases/weightUseCases.ts	Made authDeps required parameter, removed circular useCases import, removed backward-compatible shim
src/modules/weight/application/chart/weightChartUseCases.ts	Introduced WeightChartDeps interface, made dependencies required, removed shim
src/sections/weight/components/WeightView.tsx	Migrated to use useCases.weightUseCases() for update/delete operations
src/sections/weight/components/WeightEvolution.tsx	Migrated to use useCases.weightUseCases() and useCases.weightChartUseCases() - has critical accessor wrapping bug
src/sections/weight/components/WeightChartTooltip.tsx	Migrated to use useCases.weightChartUseCases() for progress calculation
src/sections/profile/measure/components/BodyMeasureChart.tsx	Migrated to use useCases.weightUseCases().weights() in measure processing
src/sections/profile/components/MacroProfile.tsx	Migrated to use useCases.weightUseCases().latest() for weight check
src/sections/profile/components/MacroEvolution.tsx	Migrated all chart components to use useCases.weightUseCases() - has critical accessor wrapping bug
src/modules/diet/macro-profile/ui/RestoreProfileModal.tsx	Migrated to use useCases.weightUseCases() for weight lookups
src/modules/diet/macro-target/application/macroTargetUseCases.ts	Updated default to use centralized useCases.weightUseCases(), but maintains shim pattern that may cause circular dependency
DI-migration-plan.md	Updated with Batch 7 progress, documents completed migrations and remaining work

[sentry]

Bug: A memory leak occurs because getMacroOverflow(), which creates a memo, is called inside another createMemo, leading to an accumulation of undisposed nested memos on re-evaluation.
_{Severity: MEDIUM}

Suggested Fix

Refactor the getMacroOverflow factory function to avoid creating a new createMemo on every call. Instead, wrap the call to getMacroOverflow() itself in a createMemo at the component level. This ensures the inner reactive computations are created only once per component instance, preventing the memory leak.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.

Location: src/sections/item/components/ItemView/ItemViewMacros.tsx#L14-L23

Potential issue: In `ItemViewMacros.tsx`, the function `getMacroOverflow()` is called
within a `createMemo` that re-evaluates whenever its dependencies, such as `item` or
`originalItem`, change. The `getMacroOverflow()` function itself creates a new, nested
`createMemo` each time it is invoked. This pattern results in a memory leak, as a new
nested memo is created on every re-evaluation of the parent memo, while the previously
created nested memos are not disposed of, leading to an accumulation of orphaned
reactive computations.