feat(perps): persist Pro positions sort and side filter prefs

[michalconsensys]

Explanation

In Pro mode, mobile needs Positions/Orders panel sort and side-filter preferences to persist across markets and app restarts. Today those values live in local React state and reset on remount (e.g. market navigation via stack push).

This extends the existing network-independent flat proLayoutPreferences bag (already used for chartExpanded) with:

• positionsSideFilter — default 'all'
• positionsSortField — default 'positionValue'
• positionsSortDirection — default 'desc'

Sort is stored as two top-level scalars (same shape as marketFilterPreferences), so getter/setter/selector stay on shallow spread with no custom merge helper. Callers continue to use getProLayoutPreferences() / setProLayoutPreferences(patch).

TypeScript breaking: consumers that construct a full ProLayoutPreferences object must include the new required fields. Runtime persisted state is forward-compatible via merge-over-defaults.

Mobile consumer PR: MetaMask/metamask-mobile#34667 (TAT-3644).

References

• Fixes https://consensyssoftware.atlassian.net/browse/TAT-3644
• Related: feat(perps): persist Pro positions sort and side filter prefs metamask-mobile#34667

Checklist

• I've updated the test suite for new or updated code as appropriate
• I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate
• I've communicated my changes to consumers by updating changelogs for packages I've changed
• I've introduced breaking changes in this PR and have prepared draft pull requests for clients and consumer packages to resolve them

---

Note

Low Risk
UI preference persistence only; runtime remains forward-compatible via merge-over-defaults, with a TypeScript-only break for full-object constructors.

Overview
Extends the flat ProLayoutPreferences bag so Pro Positions/Orders side filter and sort survive market navigation and app restarts via the existing getProLayoutPreferences() / setProLayoutPreferences(patch) API.

Adds three required fields with defaults: positionsSideFilter ('all'), positionsSortField ('positionValue'), and positionsSortDirection ('desc'), plus exported types ProPositionsSideFilter, ProPositionsSortField, and ProPositionsSortDirection.

Breaking for TypeScript: callers that construct a full ProLayoutPreferences object must include the new fields. Older persisted state stays valid at runtime because the getter and selectProLayoutPreferences still merge over DEFAULT_PRO_LAYOUT_PREFERENCES.

^{Reviewed by Cursor Bugbot for commit 6ec9a8f. Bugbot is set up for automated code reviews on this repo. Configure here.}

[aganglada]

Focused on the merge helper and whether existing perps patterns apply. No approval/block — inline notes on specific lines.

[aganglada]

Nesting positionsSortConfig is the only reason we need a custom merge helper — the original proLayoutPreferences bag from #9550 was intentionally flat.

Closest in-package precedent is marketFilterPreferences, which stores sort as two top-level scalars (optionId + direction) with a simple pref ?? defaults getter and an atomic setter. Consider flattening to positionsSortField + positionsSortDirection here so getter/setter/selector can stay on shallow spread and you can drop mergeProLayoutPreferences entirely.

If Mobile's UI state is nested, mapping at the boundary is a small cost for a much simpler persisted shape.

[aganglada]

If you keep the nested object, this helper only deep-merges positionsSortConfig over defaults, not over successive layers (persisted state → patch). That forces the setter to re-implement nested merge before calling in.

Consider a variadic signature that folds layers in one place:

exportconstmergeProLayoutPreferences=(
...layers: Array<ProLayoutPreferencesPatch|null|undefined>): ProLayoutPreferences=>{/* merge top-level + accumulate positionsSortConfig across layers */};

Then:

• getter: mergeProLayoutPreferences(this.state.proLayoutPreferences)
• setter: mergeProLayoutPreferences(state.proLayoutPreferences, patch)

No need for deepmerge (devDependency only here) — a ~15-line loop is enough for one nested key.

[aganglada]

This manual positionsSortConfig spread exists because { ...state, ...patch } clobbers the nested object when the patch only supplies field or direction. The logic belongs inside mergeProLayoutPreferences (see comment on the helper) so the setter can be:

state.proLayoutPreferences=mergeProLayoutPreferences(state.proLayoutPreferences,patch,);

Alternative if you want to avoid deep merge altogether: keep nested shape but add an atomic setPositionsSortConfig(config) (like saveMarketFilterPreferences(optionId, direction)) and restrict setProLayoutPreferences to shallow top-level patches.

[aganglada]

Do consumers need mergeProLayoutPreferences on the public surface? Getter/setter/selector already wrap it. Exporting adds API surface for an internal persistence detail — I'd keep it module-private unless Mobile has a concrete out-of-controller hydration path that needs it.