chore(site): refactor deployment values service to react-query #9669
Conversation
|
|
||
| export const deploymentConfig = () => { | ||
| return { | ||
| queryKey: ["deployment", "config"], |
There was a problem hiding this comment.
Could the query keys be declared as 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
There was a problem hiding this comment.
I don't know if this would cause the compiler to flag anything, though. I'd mainly be worried about type mismatches between readonly arrays with normal arrays
There was a problem hiding this comment.
I think they could be but I don't see to much value on doing that honestly, what use case you are thinking of?
There was a problem hiding this comment.
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.
const key1 = ["workspaces", 23, { running: true }];
const key2 = ["workspaces", 23, { running: true }] as const;
// Inferred as type (string | number | { running: boolean }), because array is arbitrary-length
const userId1 = key1[1];
// Inferred as type number, because key2 is a fixed-length, immutable tuple
const userId2 = key2[1];It's more friendly to the noUncheckedIndexedAccess compiler setting, too
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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 the as 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
|
|
||
| export const deploymentConfig = () => { | ||
| return { | ||
| queryKey: ["deployment", "config"], |
There was a problem hiding this comment.
I don't know if this would cause the compiler to flag anything, though. I'd mainly be worried about type mismatches between readonly arrays with normal arrays
| @@ -34,14 +34,9 @@ export const useDeploySettings = (): DeploySettingsContextValue => { | |||
| }; | |||
|
|
|||
| export const DeploySettingsLayout: FC = () => { | |||
| const [state] = useMachine(deploymentConfigMachine); | |||
There was a problem hiding this comment.
Still need to learn XState, but I'm guessing that this line was meant to expose the machine as a read-only value?
There was a problem hiding this comment.
it is to instantiate a machine
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Yes, it is bound to the component, in this case to the DashboardLayout
site/src/components/DeploySettingsLayout/DeploySettingsLayout.tsx
Outdated
Show resolved
Hide resolved
…r-deployment-values-service
|
|
||
| export const deploymentConfig = () => { | ||
| return { | ||
| queryKey: ["deployment", "config"], |
There was a problem hiding this comment.
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 the as 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
|
Related to #9598 |
No description provided.