Skip to content
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

OrbitControls: Derive from Controls. #29142

Merged
merged 3 commits into from
Aug 15, 2024
Merged

OrbitControls: Derive from Controls. #29142

merged 3 commits into from
Aug 15, 2024

Conversation

Mugen87
Copy link
Collaborator

@Mugen87 Mugen87 commented Aug 15, 2024

Related issue: #29085

Description

Same as #29085.

To clarify, this PR does not change any parts of the public API or behavior of OrbitControls. The class is now derived from Controls and implemented in a ES6 style like all other controls. The constructor can be side-effect free if no domElement is assigned to the ctor. When domElement is assigned after construction time, the app has to call controls.connect() once.

@Mugen87 Mugen87 added this to the r168 milestone Aug 15, 2024
@Mugen87 Mugen87 merged commit 63a88e9 into mrdoob:dev Aug 15, 2024
11 checks passed
@hybridherbst
Copy link
Contributor

Just a note, these kinds of changes (every line of the file has changed) unfortunately make it really hard to rebase changes in a fork to the latest three.js version...

@Mugen87
Copy link
Collaborator Author

Mugen87 commented Aug 17, 2024

Unfortunately, there is no way around the refactoring which was long overdue. We must make the files more ES6 conform if we want to use ESNext features (like private fields and methods) in the future. Besides, code consistency is important as well. It's easier to maintain the controls if they follow the same principles (similar to loaders).

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