3.4 KiB
Context
The current device exchange popup stores recipient name, phone, and address in three flat fields, with recipient_address being a single string. The shipping submit API currently accepts only recipient_name, recipient_phone, and recipient_address, so the frontend must remain compatible unless the backend contract changes later.
The homepage already loads /api/c/v1/asset/info through assetApi.getInfo(identifier). The UI shows package name and expiry date in the top summary card, but the request now also returns data.iccid, which should be exposed without adding a second asset query.
Goals / Non-Goals
-
Goals:
-
Add a structured province/city/district selector using
element-china-area-data -
Keep a separate detailed-address field for device exchange shipping info
-
Allow users to paste one shipping-info string and prefill recipient name, phone, and address fields
-
Preserve compatibility with the existing exchange shipping submit endpoint
-
Show
ICCIDabove the package name in the homepage top summary card -
Non-Goals:
-
Redesign the backend exchange shipping API
-
Add OCR or image-based recognition for shipping labels
-
Normalize all historical address data outside the device exchange popup
Decisions
-
Decision: Use
element-china-area-dataas the source for province/city/district options. Why: The request explicitly requires that dataset, and a static local area dataset avoids introducing extra network dependencies. -
Decision: Keep
/api/c/v1/exchange/{id}/shipping-infounchanged and composerecipient_addresson the client. Why: The existing API already accepts one address string, so the frontend can implement the new UX without blocking on backend changes. -
Decision: Recognize pasted shipping text with best-effort client-side parsing for mainland China phone numbers and common copied-address formats. Why: Users often copy a single line or multi-line string from chat or e-commerce apps, and partial automation reduces manual entry while still allowing correction.
-
Decision: When reopening existing saved shipping info, prefill split fields with best-effort parsing and preserve the original address content if a full region split cannot be derived. Why: Existing records are already stored as a combined string, so the UI needs a no-data-loss compatibility path during the transition.
-
Decision: Use
data.iccidfrom the existing asset info response as the homepage summary source of truth. Why: The user explicitly named that field and endpoint, and it avoids mixing multiple ICCID sources in the header card.
Risks / Trade-offs
- Pasted shipping strings vary in format, so recognition must remain best-effort and allow manual correction before submission.
- Some previously saved combined addresses may not map cleanly back to province/city/district selections, so fallback behavior must preserve the original text.
- Adding a new area dataset dependency increases bundle size slightly, but it keeps address selection deterministic and local.
Migration Plan
- Add the
element-china-area-datadependency and wire it into the device exchange popup. - Introduce split address state, pasted-text parsing, and composed submit payload handling.
- Update homepage asset state to read
data.iccidand render it above package name. - Verify that existing exchange records remain editable without losing previously saved address content.