-
Notifications
You must be signed in to change notification settings - Fork 891
chore(site): refactor deployment values service to react-query #9669
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
8276805
cd90ead
84979c2
dd5cfbf
d640c9c
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,15 @@ | ||
import * as API from "api/api"; | ||
|
||
export const deploymentConfig = () => { | ||
return { | ||
queryKey: ["deployment", "config"], | ||
queryFn: API.getDeploymentConfig, | ||
}; | ||
}; | ||
|
||
export const deploymentDAUs = () => { | ||
return { | ||
queryKey: ["deployment", "daus"], | ||
queryFn: () => API.getDeploymentDAUs(), | ||
}; | ||
}; |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -3,20 +3,16 @@ import { Margins } from "components/Margins/Margins"; | |
import { Stack } from "components/Stack/Stack"; | ||
import { Sidebar } from "./Sidebar"; | ||
import { createContext, Suspense, useContext, FC } from "react"; | ||
import { useMachine } from "@xstate/react"; | ||
import { Loader } from "components/Loader/Loader"; | ||
import { DAUsResponse } from "api/typesGenerated"; | ||
import { deploymentConfigMachine } from "xServices/deploymentConfig/deploymentConfigMachine"; | ||
import { RequirePermission } from "components/RequirePermission/RequirePermission"; | ||
import { usePermissions } from "hooks/usePermissions"; | ||
import { Outlet } from "react-router-dom"; | ||
import { DeploymentConfig } from "api/api"; | ||
import { useQuery } from "@tanstack/react-query"; | ||
import { deploymentConfig } from "api/queries/deployment"; | ||
|
||
type DeploySettingsContextValue = { | ||
deploymentValues: DeploymentConfig; | ||
getDeploymentValuesError: unknown; | ||
deploymentDAUs?: DAUsResponse; | ||
getDeploymentDAUsError: unknown; | ||
}; | ||
|
||
const DeploySettingsContext = createContext< | ||
|
@@ -34,14 +30,8 @@ export const useDeploySettings = (): DeploySettingsContextValue => { | |
}; | ||
|
||
export const DeploySettingsLayout: FC = () => { | ||
const [state] = useMachine(deploymentConfigMachine); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. it is to instantiate a machine There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, it is bound to the component, in this case to the DashboardLayout |
||
const deploymentConfigQuery = useQuery(deploymentConfig()); | ||
const styles = useStyles(); | ||
const { | ||
deploymentValues, | ||
deploymentDAUs, | ||
getDeploymentValuesError, | ||
getDeploymentDAUsError, | ||
} = state.context; | ||
const permissions = usePermissions(); | ||
|
||
return ( | ||
|
@@ -50,13 +40,10 @@ export const DeploySettingsLayout: FC = () => { | |
<Stack className={styles.wrapper} direction="row" spacing={6}> | ||
<Sidebar /> | ||
<main className={styles.content}> | ||
{deploymentValues ? ( | ||
{deploymentConfigQuery.data ? ( | ||
<DeploySettingsContext.Provider | ||
value={{ | ||
deploymentValues, | ||
getDeploymentValuesError, | ||
deploymentDAUs, | ||
getDeploymentDAUsError, | ||
deploymentValues: deploymentConfigQuery.data, | ||
}} | ||
> | ||
<Suspense fallback={<Loader />}> | ||
|
This file was deleted.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 indicesUh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 arraysThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think they could be but I don't see to much value on doing that honestly, what use case you are thinking of?
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
It's more friendly to the
noUncheckedIndexedAccess
compiler setting, tooThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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