Skip to content

Comments

Add edit flow for point-and-click Chamfer and Fillet#5946

Merged
pierremtb merged 40 commits intomainfrom
pierremtb/issue5521-Add-edit-flow-for-Fillet
Mar 26, 2025
Merged

Add edit flow for point-and-click Chamfer and Fillet#5946
pierremtb merged 40 commits intomainfrom
pierremtb/issue5521-Add-edit-flow-for-Fillet

Conversation

@pierremtb
Copy link
Contributor

@pierremtb pierremtb commented Mar 21, 2025

Fixes #5521 and #5950, using a common prepareToEdit function for both chamfer and fillet.

Cases:

  • segment
  • sweepEdge
  • edgeCutEdge (out of scope)

Video of the new e2e test step for each at play:

Screen.Recording.2025-03-23.at.6.26.29.AM.mov

@qa-wolf
Copy link

qa-wolf bot commented Mar 21, 2025

QA Wolf here! As you write new code it's important that your test coverage is keeping up.
Click here to request test coverage for this PR!

@vercel
Copy link

vercel bot commented Mar 21, 2025

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Updated (UTC)
modeling-app ✅ Ready (Inspect) Visit Preview Mar 26, 2025 9:57am

@codecov
Copy link

codecov bot commented Mar 21, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 85.82%. Comparing base (c53fa42) to head (458c557).
Report is 1 commits behind head on main.

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #5946   +/-   ##
=======================================
  Coverage   85.82%   85.82%           
=======================================
  Files         113      113           
  Lines       44484    44484           
=======================================
  Hits        38177    38177           
  Misses       6307     6307           
Flag Coverage Δ
rust 85.82% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@pierremtb pierremtb marked this pull request as ready for review March 22, 2025 11:45
@pierremtb pierremtb requested review from a team, franknoirot and max-mrgrsk March 22, 2025 11:45
@pierremtb pierremtb changed the title WIP: Add edit flow for Fillet Add edit flow for Fillet Mar 22, 2025
@pierremtb pierremtb changed the title Add edit flow for Fillet Add edit flow for point-and-click Fillet Mar 22, 2025
@pierremtb pierremtb changed the title Add edit flow for point-and-click Fillet Add edit flow for point-and-click Fillet and Chamfer Mar 23, 2025
@pierremtb pierremtb changed the title Add edit flow for point-and-click Fillet and Chamfer Add edit flow for point-and-click Chamfer and Fillet Mar 23, 2025
Copy link
Contributor

@Irev-Dev Irev-Dev left a comment

Choose a reason for hiding this comment

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

I think it would be good to have these work for chamfers/fillets not in pipes.

I don't think it would be too much extra work?

Comment on lines 155 to 157
if (err(edgeArtifact)) {
return baseCommand
}
Copy link
Contributor

Choose a reason for hiding this comment

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

What happens here exactly when there's an error and it returns the baseCommand?

Does the edit still work?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good call, the command bar gets opened up but is missing all the prefilled data which is confusing. I believe @franknoirot intended for us to use

type PrepareToEditFailurePayload = { reason: string }
, so I changed to returning that here. And that works well with the non-pipe catch I added, see other comment.

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah you're right @pierremtb there are probably places in operations.ts that you took from that are also not using that pattern yet, apologies it was a pattern added while we've been building the system but we should report a failure reason everywhere instead of returning baseCommand silently.

Comment on lines 2320 to 2334
const { nodeToEdit, selection, radius } = input

// If this is an edit flow, first we're going to remove the old one
const pipeIndex = 5
if (
nodeToEdit &&
nodeToEdit[pipeIndex][0] &&
typeof nodeToEdit[pipeIndex][0] === 'number'
) {
const r = locateExtrudeDeclarator(ast, nodeToEdit)
if (!err(r) && r.extrudeDeclarator.init.type === 'PipeExpression') {
r.extrudeDeclarator.init.body.splice(nodeToEdit[pipeIndex][0], 1)
}
}

Copy link
Contributor

Choose a reason for hiding this comment

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

Okay so I'm guessing that this only works for editing fillets/chamfers that are in a pipeExpression?
Is that easy to fix for ones that are not in a pipe?, because while our code-mods might put them in a pipe, it would be good if the edit still worked without the pipe because either the user or AI might not put it in a pipe.

With that said this magic 5 makes me nervous, I'm guessing 5 is how deep in the editNode the pipeExpression is on the most common cases. I know we're trying to get the basic cases working because editing stuff within function definitions or in if statements is whole can of worms we don't the band width for right now, but maybe using
const pipeIndex = nodeToEdit.findIndex(([_, type]) => type === 'PipeExpression') would make this a little more robust?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, only PipeExpression is supported as this is what the point-and-click addition adds. As discussed on Slack I'll try to see how much of a lift it would be to add support for standard calls that would have been ai or user typed. But for now I added a specific catch for it that will get toasted and prevent edition. That was related to your other comment about erroring too and I think now it's more in line with how @franknoirot had things set up. Some of the changes here with return { reason: ... will have to be done on other edit flows as well.

Good point, I didn't like it either which is why I made it explicit in its own variable as a starter haha. Changed it to a findIndex call, much better.

Comment on lines 188 to 195
const isPipeExpression = nodeToEdit.some(
([_, type]) => type === 'PipeExpression'
)
if (!isPipeExpression) {
return {
reason: 'Only chamfer in pipe expressions are supported for edits',
}
}
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is our new guard for now @Irev-Dev. I'm honestly thinking we should merge as is, and try to expand later. Got too many branches at once for these flows and I'm afraid I'll get lost haha.

@pierremtb pierremtb enabled auto-merge (squash) March 26, 2025 09:45
@pierremtb pierremtb merged commit b6fe660 into main Mar 26, 2025
37 checks passed
@pierremtb pierremtb deleted the pierremtb/issue5521-Add-edit-flow-for-Fillet branch March 26, 2025 11:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add edit flow for Fillet

4 participants