agama-project / agama / 24779535910

push

github

refactor(web): infer pattern state from proposal (#3408)

After a talk with @imobachgs about
[NOTE](https://github.com/agama-project/agama/blob/173881212/web/src/components/software/SoftwarePatternsSelection.tsx#L143-L149)
introduced in https://github.com/agama-project/agama/pull/3396, he
explained to me the rationale and importance of PatternsArray type
there: users can provide a profile with the exact patterns they wanna
use to avoid both, auto and pre selections.

> // NOTE: patterns is typed as PatternsArray | PatternsObject, but a
flat array
> // makes little sense here. It may be a design issue in the openapi
spec worth
> // revisiting. In any case, cast is safe: accessing .add/.remove on an
array
>  // returns undefined, handled by ?? []

Wrongly assuming it was a design issue lead the implementation of
SoftwarePatternsSelection to read the extended config to decide which
patterns to preserve across different scope submissions. That required
casting patterns: PatternsArray | PatternsObject to PatternsObject,
which **silently discards user choices when a profile supplies the array
form.**

@imobachgs encourages to the usage of proposal instead, since it already
carries the same intent through the SelectedBy value: USER means the
user explicitly added the pattern, REMOVED means they explicitly removed
it.

In fact, using it removes the cast, drops the useExtendedConfig
dependency, and simplifies resolvePatternAction by two parameters.

> [!WARNING]
> However, there is a problem with this approach since looks like the
backend does not reliably persist REMOVED in `proposal.patterns` once no
auto-selection is pulling the pattern. In other words, REMOVED silently
flipping to NONE after the pattern creating the auto-dependency is
removed.
>
> That's mean user can: Select Gnome from desktops page, then remove Multimedia on the patterns page, later unselect Gnome and ultimately re-select it once more: Multimedia is auto-se... (continued)

3754 of 6058 branches covered (61.97%)

Branch coverage included in aggregate %.

2 of 2 new or added lines in 1 file covered. (100.0%)

13802 of 18304 relevant lines covered (75.4%)

81.83 hits per line