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

Editor: Move commands to ES6. #21235

Merged
merged 1 commit into from
Feb 9, 2021
Merged

Editor: Move commands to ES6. #21235

merged 1 commit into from
Feb 9, 2021

Conversation

Mugen87
Copy link
Collaborator

@Mugen87 Mugen87 commented Feb 9, 2021

Related issue: #21229

Description

Converted all command classes to ES6 code.

Also fixed an issue with SetMaterialColorCommand which produces a runtime error when persistent history was enabled.

@mrdoob
Copy link
Owner

mrdoob commented Feb 9, 2021

Sweet!

@mrdoob mrdoob added this to the r126 milestone Feb 9, 2021
@mrdoob mrdoob merged commit 536d729 into mrdoob:dev Feb 9, 2021
@mrdoob
Copy link
Owner

mrdoob commented Feb 9, 2021

Thanks!

@Mugen87
Copy link
Collaborator Author

Mugen87 commented Feb 10, 2021

@mrdoob Consider a file like Config.js from the editor.

Do you also want to convert such files to classes? Currently they define their public API by the ctor's return object. Similar files also exist in src/renderers. When I've started developing WebGPURenderer, I've used the class approach. However, I had the impression you were not 100% happy with it because it requires that certain properties and/or methods are available via this. For comparison:

https://github.com/mrdoob/three.js/blob/dev/examples/jsm/renderers/webgpu/WebGPUObjects.js
https://github.com/mrdoob/three.js/blob/dev/src/renderers/webgl/WebGLObjects.js

What style should we choose for the editor, WebGLRenderer and potentially other source files?

@mrdoob
Copy link
Owner

mrdoob commented Feb 11, 2021

The approach of returning an object had interesting properties but it was yet another workarounds for the fact that JS didn't have proper classes. Nowadays I think it's probably better to unify to standard class usage.

I would avoid making properties public whenever possible though. We know how users end up abusing those.

@Mugen87
Copy link
Collaborator Author

Mugen87 commented Feb 11, 2021

I would avoid making properties public whenever possible though.

Let's say there is no way around to add an internal property to this so it is accessible by all methods. Do you think we should use the _ prefix to mark such properties as private?

@mrdoob
Copy link
Owner

mrdoob commented Feb 11, 2021

For the time being... yes.

@DefinitelyMaybe
Copy link
Contributor

ok, I will add a note of this to the dev contribution guide

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.

3 participants