Contact Edit Service - Likepersonsapp | Generated by Eircodex v1.0.0

Description

Handles the complete edit flow for contact records: collecting validated form data, submitting updates to the repository, and reporting success or error states back to the edit screen.

Feature: Contact Detail & Edit Screen

contact-edit-service

Summaries

The Contact Edit Service enables coordinators to maintain accurate, up-to-date contact records without leaving the mobile application — reducing reliance on desktop workflows and cutting the time cost of administrative data maintenance. By handling partial updates (only changed fields are submitted), it minimizes bandwidth usage and reduces backend processing load, which is particularly valuable in low-connectivity field environments. The built-in error surfacing with user-readable messages reduces support burden and improves coordinator confidence when editing sensitive member data for Blindeforbundet.

This medium-complexity service sits at the junction of UI form data and backend persistence, making it a critical path item for the contact editing feature. It depends on both `contact-detail-repository` for the persistence write path and `contact-form-validator` for pre-submission validation, so both must be ready before full integration testing can proceed. The partial-update logic (diffing changed fields before submission) adds moderate implementation complexity and deserves dedicated test coverage with multiple field-change scenarios. A key delivery risk is schema misalignment between the `ContactEditPayload` structure and backend API expectations — an early API contract review is strongly recommended.

This service implements the full edit lifecycle: `saveContactEdits(String contactId, ContactEditPayload payload) -> Result`, `updateChapterAffiliations(String contactId, List chapterIds) -> Result`, `handleSaveError(Object error) -> String`, and `refreshContactState(String contactId)`. The partial-update pattern requires the service to diff the incoming payload against the current contact state before submission — this diff logic should be encapsulated in a utility method for testability. `handleSaveError` must map backend error codes to human-readable strings and should be driven by a configuration map rather than hardcoded switch statements. After a successful save, `refreshContactState` should trigger a re-fetch via `contact-detail-service` to keep the UI consistent.

Consumes `contact` and `chapter` data models.

Responsibilities

Accept validated contact form data and submit to repository
Handle partial update of fields (only changed fields sent to backend)
Surface save errors with user-readable messages
Refresh contact detail state after successful save

Interfaces

saveContactEdits(String contactId, ContactEditPayload payload) -> Result

updateChapterAffiliations(String contactId, List<String> chapterIds) -> Result

handleSaveError(Object error) -> String

refreshContactState(String contactId)

Relationships

Dependencies (2)

Components this component depends on

infrastructure Contact Form Validator Shared data Contact Detail Repository Shared

Dependents (1)

Components that depend on this component

ui Edit Contact Screen

Related Data Entities (2)

Data entities managed by this component

Contact 20 fields core Contact Chapter Membership 10 fields core

API Contract

View full contract →

REST /api/v1/contacts 7 endpoints

GET /api/v1/contacts List contacts (edit-context view)

GET /api/v1/contacts/:id Get contact for editing

POST /api/v1/contacts Create contact via edit form

PUT /api/v1/contacts/:id Save contact edits (saveContactEdits)

DELETE /api/v1/contacts/:id Delete contact

PUT /api/v1/contacts/:id/chapter-affiliations Update chapter affiliations for a contact

+1 more