Not an issue, but something I've been wondering about: does the server have sanitization for the data we're sending it from the client? With TS being structurally-typed, the object we serialize for the request could have extra properties on it, and TypeScript wouldn't necessarily complain, because the overall "shape" would be what it's looking for. I'm worried that could cause two issues at some point:

1. Our request sends extra properties that the server doesn't care about. Not a big deal if the server is defensive about this
2. RQ hashes objects deterministically, but if extra properties are on the object that we don't know about, that would affect the hash result, and could cause queries to run more often than we expect

I don't think 2 is worth worrying about too much, but the server is definitely a worry for me

Good one, the server is doing some parsing on the params so we don't need to worry about it for now.

Would this need to be wrapped in an arrow function, for mocking purposes?

I think this is okay for now since it is using MSW on the related tests... this is something we should talk about and get some "consensus" about what to use to mock API requests.

I'm wondering if some of the connected properties on the type (isSignedOut, isSigningOut, isSignedIn, isSigningIn) can be combined into a single status. Something like this:

status: "signingIn" | "signedIn" | "signingOut" | "signedOut"

Logically, it shouldn't be possible for a user to be be in multiple of these states at once, but it's still possible at the type level right now

Hm.... I think this is a good one.

Just because this is such a long object, I feel like it could help to add two type-checking helpers. Something like:

type PermissionConfig = {
  object: {
    resource_type: string; // Or something more specific, if it's already a type
   },
  action: "read" | "create" | "update" | "delete"
}

export const permissionsToCheck = {
  // Same content
} as const satisfies Record<keyof typeof checks, PermissionConfig>;

I'm just worried that if somebody has a typo when updating the object, it might take a while for them to catch it otherwise

Similarly, I'm wondering if we could get rid of the checks object, in favor of making permissionsToCheck the main source of truth. From what I can tell, the object is being used in this file to define the keys, but the only other place is in is the updateCheckXService file, to make sure the correct key is being used with the permissions object

I liked both suggestions.

Not sure if this is overkill, but I'm wondering if

userQuery.isSuccess && permissionsQuery.isLoading

could be swapped out for

permissionsQuery.isFetching && permissionsQuery.isLoading

just to help insulate permissionsQuery from any state changes in userQuery

Hm... not sure, for me the way it is now it is better to understand than the one you proposed, and permissionsQuery should not be changed.

Yeah, that's fair. This might be partly misunderstanding the API on my part – I need to review what happens if a query succeeds on an initial fetch, but errors out on a refetch