Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

chore(site): remove xstate#10659

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged
BrunoQuaresma merged 33 commits intomainfrombq/refactor-workspace-xservice
Nov 14, 2023
Merged

Conversation

BrunoQuaresma
Copy link
Collaborator

@BrunoQuaresmaBrunoQuaresma commentedNov 13, 2023
edited
Loading

Recommendation for the reviewers: Focus on thequeries andWorkspacePage folders.

Close#9943
Close#9598

@Parkreiner
Copy link
Member

Started going through this, but I'm not close to done yet. I'm probably just going to spend a few hours going through this first thing tomorrow morning

@aslilac
Copy link
Member

I gave it a relatively thorough scrub and think it looks great!

Copy link
Member

@ParkreinerParkreiner left a comment
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Echoing what Kayla said – this looks really good, and it's so much easier for me to understand what the retry builds function is doing now. That should help me wrap up my other feature really quickly

I did catch one likely bug with theuseEffect call where it might close out earlier than expected. Beyond that, though, just minor nits/questions

export const workspaceByOwnerAndName = (
owner: string,
name: string,
): QueryOptions<Workspace> => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Is there a reason why the return type was removed? If nothing else, I feel that some kind of type hint can be worth it , just because it helps with auto-complete

Copy link
CollaboratorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

It was because when using thequeryKey value from theQueryOptions it was returning a type error because it can be undefined:

Example:

queryClient.setQueryData(workspaceQueryOptions.queryKey,newWorkspaceData,);

Error:

Argument of type 'QueryKey | undefined' is not assignable to parameter of type 'QueryKey'

I could try to better type it but for this case, I just think it is too much. At some point, we may create a utility type to help us with typing the query results.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Yeah, RQ v5's newqueryOptions function might also help with this


export const cancelBuild = (workspace: Workspace) => {
return {
mutationFn: () => {
Copy link
Member

@ParkreinerParkreinerNov 14, 2023
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Just making sure: does anything need to happen in response to a build being canceled? No query invalidation or cache updates?

Copy link
CollaboratorAuthor

@BrunoQuaresmaBrunoQuaresmaNov 14, 2023
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Good catch! I left this to think in a different moment, and I forgot. For some reason, for this endpoint, we return a defaultResponse object, and in the previous machine, we didn't make anything, but I think the best would be to invalidate the builds query. Should we invalidate any other data?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Yeah, I think that's the most important part. Maybe also the general workspace query, just because it also has a property with theWorkspaceBuilds type?

},
action: "read",
},
}) as const;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Do you think it would help to have a separate type defined that lists what each value of the workspace checks object is allowed to be?

It looks like the type is based on theAuthorizationCheck type fromtypesGenerated.ts?

Copy link
CollaboratorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

I don't think so 🤔

const buildLogs = useWorkspaceBuildLogs(workspace.latest_build.id);
const shouldDisplayBuildLogs =
hasJobError(workspace) ||
["canceling", "deleting", "pending", "starting", "stopping"].includes(
workspace.latest_build.status,
);

// Restart
const [confirmingRestart, setConfirmingRestart] = useState<{
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Wondering if the state type could be defined as a discriminated union, so that you're guaranteed to havebuildParameters be defined wheneveropen is true

Though I guess that would also require updating the type definitions further down the tree

Copy link
CollaboratorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

I usually think discriminated unions are always a good idea but for this case, I would just let it as it is since there is not too much value and to avoid more changes.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Yeah, that's fair

@Kira-Pilot
Copy link
Member

Kira-Pilot commentedNov 14, 2023
edited
Loading

I notice that if I stop/start a build and then cancel the action halfway through, I'm getting an API error every time:
Screenshot 2023-11-14 at 11 58 28 AM

This isn't happening onmain so I'm just wondering if maybe we're not timing something properly on the FE - do we have to wait for the build to finish before we cancel it, perhaps?

BrunoQuaresma reacted with thumbs up emoji

@BrunoQuaresma
Copy link
CollaboratorAuthor

@Kira-Pilot good catch! I was passing the workspace id instead of the build id 🤦 I also noted here to create a test for it.

Copy link
Member

@ParkreinerParkreiner left a comment
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

If Kira's issues are resolved, no other concerns jump out at me. Just had a comment about one other type of query invalidation that could be added

BrunoQuaresma reacted with heart emoji

export const cancelBuild = (workspace: Workspace) => {
return {
mutationFn: () => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Yeah, I think that's the most important part. Maybe also the general workspace query, just because it also has a property with theWorkspaceBuilds type?

const buildLogs = useWorkspaceBuildLogs(workspace.latest_build.id);
const shouldDisplayBuildLogs =
hasJobError(workspace) ||
["canceling", "deleting", "pending", "starting", "stopping"].includes(
workspace.latest_build.status,
);

// Restart
const [confirmingRestart, setConfirmingRestart] = useState<{
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Yeah, that's fair

@BrunoQuaresma
Copy link
CollaboratorAuthor

BrunoQuaresma commentedNov 14, 2023
edited
Loading

Yeah, I think that's the most important part. Maybe also the general workspace query, just because it also has a property with the WorkspaceBuilds type?

The workspace is going to be automatically updated because of the SSE connection so I would avoid having two events updating the same source.

Copy link
Member

@Kira-PilotKira-Pilot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

This looks great, Bruno! Thanks so much for taking it on.

@BrunoQuaresmaBrunoQuaresmaenabled auto-merge (squash)November 14, 2023 18:33
@BrunoQuaresmaBrunoQuaresma merged commit90b6e86 intomainNov 14, 2023
@BrunoQuaresmaBrunoQuaresma deleted the bq/refactor-workspace-xservice branchNovember 14, 2023 18:34
ericpaulsen pushed a commit to lbi22/coder that referenced this pull requestNov 27, 2023
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers

@aslilacaslilacaslilac left review comments

@Kira-PilotKira-PilotKira-Pilot approved these changes

@ParkreinerParkreinerParkreiner approved these changes

Assignees

@BrunoQuaresmaBrunoQuaresma

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

Additional Batch #4 - Replace XState by react-query Replace XState services by react-query for simple fetching and mutations
4 participants
@BrunoQuaresma@Parkreiner@aslilac@Kira-Pilot

[8]ページ先頭

©2009-2025 Movatter.jp