refactor: support PATCH and dynamic paths in useApiMutation

[Mothball7205]

Database Migration

NO

Description

add PATCH to the allowed methods and allow path to be a function of the mutation data, so dynamic routes like /history/failed/{id} can go through the standard client.
backwards compatible, string paths are unchanged

Fixes Unrelated Issues

• mutationOptions leaked into fetchJson — the old spread { ...options } included mutationOptions in requestOptions, which then ended up in ...otherOptions and was passed directly to fetchJson. The new explicit destructure correctly excludes it.
• queryParams leaked the same way — same issue, same fix.

Todos

• Tests

[plz12345]

This is already standardized in useApiQuery.ts , unless I'm missing your point. Your code should be reusing that client unless not possible, and if not, let's figure out why.

[Mothball7205]

This is already standardized in useApiQuery.ts , unless I'm missing your point. Your code should be reusing that client unless not possible, and if not, let's figure out why.

@plz12345 thanks. you're right. i looked at it and i could remove the apiRequest.ts and use useApiMutation.ts/useApiQuery.ts.

the only problem is that useApiMutation binds the path once at the hook creation, which means when we have dynamic paths like /history/failed/${historyId} its basically not possible to use it.

i could add a function path path: string | ((data: TData) => string) to the useApiMutation to allow variables in the path at mutation time. i think that should be pretty clean

const markFailed = useApiMutation<void, number>({
  method: 'POST',
  path: (historyId) => `/history/failed/${historyId}`,
  mutationOptions: {...

[plz12345]

Can we...not refactor half the front end just to do the one API call you had on the other PR? At most, stick to object boundaries, (movie/scene, performer, studio), and don't start with the heaviest ones. It's too much risk without any unit testing on the changes (yes, I realize that's pot/kettle/black based on existing source).

[Mothball7205]

yeah you're right... for some reason i was thinking "this is just one fix, it makes sense to be this size."

i will keep the PRs smaller. i know it can be tiring reviewing PRs and i dont wanna add to that.

for this one would just the useApiMutation change be ok? PATCH support + allowing dynamic paths (so stuff like /history/failed/{id} can use it). that would make the existing // TODO: Move to useApiMutation parts doable, but i'd leave those for now

[plz12345]

Yeah, if it's a new function, no real risk, and other stuff can consume it, like your other PR, History (later) etc.

[sonarqubecloud]

Quality Gate failed

Failed conditions
0.0% Coverage on New Code (required ≥ 80%)

See analysis details on SonarQube Cloud