Data Layer medium complexity Shared Component mobile
0
Dependencies
2
Dependents
3
Entities
0
Integrations

Description

Data access layer for retrieving and updating full contact profiles, including extended attributes like chapter affiliations, encrypted field metadata, and assignment status. Wraps Supabase queries with typed response models.

Feature: Contact Detail & Edit Screen

contact-detail-repository

Summaries

The Contact Detail Repository is the backbone of the organization's ability to maintain accurate, complete member records across every interaction. By centralizing access to full contact profiles — including chapter affiliations, assignment statuses, and sensitive encrypted fields — this component ensures coordinators always work with authoritative data rather than stale or partial records. The result is fewer errors, faster decision-making, and a measurably better experience for both staff and the members they serve. As a shared component used across multiple features, it also reduces duplication and lowers long-term maintenance costs, protecting the organization's investment in this platform.

As a shared, medium-complexity data component, the Contact Detail Repository sits at the center of several delivery streams — any feature touching contact profiles, chapter affiliations, assignment workflows, or encrypted fields depends on it being stable and well-tested before those features can ship. Plan for integration testing against a real Supabase instance early in the sprint cycle to catch schema mismatches before they cascade. Because it is marked shared and consumed across multiple features, changes to its interface carry a high blast radius: coordinate updates carefully and communicate breaking changes to all consuming teams. Allocate buffer time for encrypted field scenarios which add non-trivial testing complexity.

Contact Detail Repository wraps Supabase queries behind a typed interface, exposing six methods covering full profile fetch, field updates, chapter affiliation reads and writes, assignment status retrieval, and encrypted field metadata queries. All responses are mapped to strongly-typed Dart models (Contact, Chapter, AssignmentStatus, EncryptedField), isolating the rest of the mobile codebase from raw Supabase response shapes. Because it is marked shared, changes to its public API surface must be backward-compatible or coordinated across all consuming BLoCs. Pay attention to Supabase RLS policies when writing tests — row-level security can silently return empty results rather than errors, making coverage of unauthorized-access scenarios essential for reliability.

Responsibilities

  • Query Supabase for complete contact profile by ID
  • Update contact record fields on edit
  • Fetch chapter affiliation records for a contact
  • Query and update assignment status for Blindeforbundet contacts

Interfaces

fetchContactById(String id) -> Contact
updateContact(String id, Map<String, dynamic> fields) -> Contact
fetchChapterAffiliations(String contactId) -> List<Chapter>
updateChapterAffiliations(String contactId, List<String> chapterIds) -> void
fetchAssignmentStatus(String contactId) -> AssignmentStatus
fetchEncryptedFieldMetadata(String contactId) -> List<EncryptedField>

Relationships

Dependents (2)

Components that depend on this component

Related Data Entities (3)

Data entities managed by this component

API Contract

View full contract →
REST /api/v1/contacts 7 endpoints
GET /api/v1/contacts List contacts from repository
GET /api/v1/contacts/:id Fetch contact by ID from repository (fetchContactById)
POST /api/v1/contacts Create contact record in repository
PUT /api/v1/contacts/:id Update contact fields in repository (updateContact)
DELETE /api/v1/contacts/:id Delete contact record from repository
GET /api/v1/contacts/:id/chapter-affiliations Fetch chapter affiliations from repository (fetchChapterAffiliations)
+1 more