Frontend: Unnecessary GET requests after attribute create/edit operations

[stanleykc]

Summary

After creating or editing service definition attributes, the frontend makes unnecessary GET requests to fetch data that's already returned in the POST/PATCH response.

Background

This issue was discovered while fixing a related bug where service request priority wasn't displaying after updates (the GET endpoint wasn't returning the priority field, but the PATCH response was).

Current Behavior

Both createAttribute and editAttribute API methods return the full updated attributes list:

// Response schema for both create and edit
{
  service_code: number,
  attributes: ServiceDefinitionAttribute[]  // Full updated list
}

However, after calling these methods, the code calls updateAttributeMap() which triggers getServiceDefinition() - making another GET request to fetch data that was already returned.

Affected Files

1. frontend/src/routes/groups/[group_id]/services/[service_id]/+page.svelte (lines 186-195)

   • After createAttribute, calls updateAttributeMap(serviceCode) instead of using the response

2. frontend/src/lib/components/ServiceDefinitionEditor/EditAttributeItem/EditAttributeItem.svelte (lines 131-134, 166-169)

   • After editAttribute, calls updateAttributeMap(serviceCode) then navigates away
   • Note: The navigation might reload data anyway, so this might be partially redundant

Suggested Fix

Use the response from the create/edit operations directly to update the local state, similar to how updateAttributesOrder already does:

// Current pattern (makes extra GET)
await libre311.createAttribute(body);
updateAttributeMap(serviceCode);  // Triggers GET

// Better pattern (uses response directly)
const res = await libre311.createAttribute(body);
asyncAttributeInputMap = asAsyncSuccess(createAttributeInputMap(res, {}));

Priority

Low - These are admin-only operations and the data displays correctly. The issue is just an unnecessary network call, not a functional bug.

Related

This was discovered while fixing a service request priority display bug where the same pattern was causing issues (the GET endpoint wasn't returning all fields that the PATCH response included).