marketplaces/docs/FUTURE_FEATURES.md

Future Features

Nice-to-have, non-blocking work — no client decision needed, just not worth doing now. Verified against current repo state 2026-07-26.

Cart payment modal → app-dialog migration

.payment-modal/.bank-payment-modal on the cart page are custom overlays with their own focus-trap (added during the WCAG audit) rather than the shared app-dialog primitive. Functionally and accessibly complete as-is. Attempted 2026-08-06 and deliberately stopped, not just deferred — real conflicts found, not reluctance:

• Cart's modals have no backdrop-click-to-close today (intentional — an in-flight QR/bank payment shouldn't cancel on a stray click); app-dialog always closes on backdrop click, no opt-out existed.
• The QR/status modal and the bank-iframe modal can be open simultaneously (nested), with Escape closing only the top one and falling back to the QR view underneath, payment polling untouched. app-dialog has no stacking/priority concept — two instances would both react to one Escape.
• The bank iframe needs a full-bleed min(960px,92vw)×min(760px,86vh) panel with zero padding; app-dialog's largest preset caps at 800px with fixed 1.5rem padding.

app-dialog was extended with closeOnEscape/closeOnBackdropClick inputs (default true, backward-compatible with its other 13 call sites) to close the first two gaps, but the actual cart-template migration was reverted before landing — a same-session follow-up attempt deleted the hand-rolled focus-trap/Escape-key code from cart.component.ts without finishing the cart.component.html swap to app-dialog, which would have shipped live checkout code with no keyboard focus-trap at all. Caught before commit, fully reverted (dialog.component.ts, cart.component.ts, cart.component.html all back to original — the closeOnEscape/closeOnBackdropClick API extension did not ship either, since it had no consumer left).

Next attempt should land the DialogComponent API extension as its own small, independently-reviewed change first, then do the cart template migration as a second, separate, carefully-tested change — not both in one pass.

Angular 22 upgrade

Researched, not executed. Estimated ~2–3.5 days, needs the barry-cache dependency fix and a Node version bump first. Explicitly out of scope for the Backend Finalization Sprint. Plan: docs/ANGULAR22_PLAN.md.

Bundle splitting

Initial (eagerly-loaded) bundle carries an ~11 MB chunk that is the entire @lucide/angular icon set, confirmed 2026-08-05 by inspecting build output — app-icon/IconComponent only ever needs the ~85 icons named in icon-registry.ts, but esbuild is not eliminating the other ~1500+ unused icon classes from @lucide/angular's single-file fesm2022/lucide-angular.mjs bundle, despite the package declaring sideEffects: false and every usage in this codebase being clean named imports (no wildcard imports found). Root cause not fully diagnosed — likely each icon's Angular component metadata assignment isn't PURE-annotated in that build, so esbuild can't drop unreferenced classes within the single shared module even though it can drop unreferenced exports. The package ships no per-icon deep-import path as a workaround (single fesm file only). Real fix options, neither attempted here (touches a dependency, needs sign-off): (a) check for a newer @lucide/angular release with better tree-shaking, (b) drop the dependency and hand-roll inline SVG path data for just the ~85 used icons (removes a dependency, matches this repo's minimal-deps convention, but is real work — extracting/verifying 85 icon paths). This alone is roughly 6x the size of the two lazy chunks below combined and, unlike them, ships to every visitor on first load.

Two lazy chunks are also large: project-editor (~1.0 MB), catalog-container (~330–375 kB, varies by build). No mechanical split found yet for either — needs a dedicated profiling task, ideally under real backend latency per docs/NEXT_PHASE.md Phase 3.

Homepage hero-to-categories spacing investigation

A dead-space gap between the hero and categories section on the storefront home page traces to bootstrap mock config (widget/section padding values in the dev fixture), not a confirmed code defect. Needs reproduction with real tenant data before it's worth investigating further — not a bug until it's confirmed to happen outside the mock fixture.