Could the query keys be declaredas const? That would not only make sure that they're kept immutable, but also give more precise type information when accessing elements of the key at specific indices

I don't know if this would cause the compiler to flag anything, though. I'd mainly be worried about type mismatches betweenreadonly arrays with normal arrays

I think they could be but I don't see to much value on doing that honestly, what use case you are thinking of?

Yeah, I'm looking at the code again, and I think it has limited value here, just because all the values are strings. I think I generally default to this approach, but it's most useful when you have a key array that mixes different types.

constkey1=["workspaces",23,{running:true}];constkey2=["workspaces",23,{running:true}]asconst;// Inferred as type (string | number | { running: boolean }), because array is arbitrary-lengthconstuserId1=key1[1];// Inferred as type number, because key2 is a fixed-length, immutable tupleconstuserId2=key2[1];

It's more friendly to thenoUncheckedIndexedAccess compiler setting, too

I see, but I don't see we using something similar like this - accessing the keys directly - so I think we could wait until it becomes an issue or provide more value. Wdyt? But if you feel strong about that, we can do it for all the query keys, I just would do in a diff PR (since it is going to change non related queries as well).

No, I'm okay with keeping things as-is. There have been cases where I've passed the query key into the function to construct which API endpoint and which parameters to use, and theas const declarations would help with that, but if there hasn't been a need for that pattern, then I agree with you – it's going to have limited use

I don't know if this would cause the compiler to flag anything, though. I'd mainly be worried about type mismatches betweenreadonly arrays with normal arrays

Still need to learn XState, but I'm guessing that this line was meant to expose the machine as a read-only value?

it is to instantiate a machine

Okay, so it creates the new machine instance, but it's bound as local state for that given component, right? it's not quite a Redux setup where there's only ever one store, and the components selectively subscribe to it?

Yes, it is bound to the component, in this case to the DashboardLayout

No, I'm okay with keeping things as-is. There have been cases where I've passed the query key into the function to construct which API endpoint and which parameters to use, and theas const declarations would help with that, but if there hasn't been a need for that pattern, then I agree with you – it's going to have limited use