Skip to content

fix: add renderOrder to AxisRotator #2504

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

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

romankoho
Copy link
Contributor

@romankoho romankoho commented Aug 1, 2025

Why

this PR closes ticket #2503

What

Checklist

  • Documentation updated (example)
  • Storybook entry added (example)
  • Ready to be merged

I need this urgently ;) would be nice if it can be merged soon

Copy link

vercel bot commented Aug 1, 2025

Someone is attempting to deploy a commit to the Poimandres Team on Vercel.

A member of the Team first needs to authorize it.

Copy link

codesandbox-ci bot commented Aug 1, 2025

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

@romankoho romankoho changed the title add renderOrder to AxisRotator fix: add renderOrder to AxisRotator Aug 1, 2025
@FarazzShaikh
Copy link
Member

I’d suggest making it a prop rather than hard coding the renderOrder. Also to preserve backwards compatibility, making the prop optional would be good

@romankoho
Copy link
Contributor Author

@FarazzShaikh I agree on that. But in this case I also replaced the hard coded value from ScalingSphere and AxisArrow with the property.

@@ -115,6 +116,7 @@ export const PivotControls: ForwardRefComponent<PivotControlsProps, THREE.Group>
rotationLimits,
scaleLimits,
depthTest = true,
renderOrder = 500,
Copy link
Member

Choose a reason for hiding this comment

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

Let’s default it to undefined please. As that was the original behavior (backwards compatibility). Unless 500 is absolutely necessary for it to 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.

you are right in regards to the AxisRotator. But if you look at the current code of AxisArrow and ScalingSphere you can see that there the value is hard coded to 500.

So either backwards-compatibility for AxisArrow andScalingSphere is broken or for AxisRotator. I plead for setting the default to 500 as this rather fixes AxisRotator than breaking it. Setting default to undefined could potentially break AxisArrows and ScalingSpheres which were working until now.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@FarazzShaikh if this is a show stopper I'm fine with setting it to undefined.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@FarazzShaikh any opinion on my reply? I'd love to see this being merged.

Copy link
Member

Choose a reason for hiding this comment

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

I’ll merge it tonight. Just need to verify it works as expected with the 500 render order

Copy link
Contributor Author

Choose a reason for hiding this comment

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

amazing, thank you!

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.

2 participants