Serializing custom classes should use a known type

(title originally “[suggestion] Examples should extend this.name, not this.type”)

Description of the problem

The example components generally override the type property of custom objects/materials/etc., like Water or the PMREM Materials with types of ‘EquirectangularToCubeUV’ and ‘SphericalGaussianBlur’.

As these are still Mesh and ShaderMaterial classes respectively, the original type after serialization is lost, e.g. serializing Water shows is type as Water, and there’s no longer a reference to this object being a Mesh, other than inference. This also fails with ObjectLoader because of this, with the resulting objects being Object3Ds. While not all ‘custom classes’ can be deserialized understandably, it should be possible for simple Mesh classes that just generate geometry and material.

I think for the most part, this.type should not be overwritten, and instead this.name should be used, or perhaps another property (e.g. coreType). Happy to make the changes, but want to be sure I understand how type and name are to be used and that this change is agreeable.

[donmccurdy]

The problem is that .type is not a good indicator of the traits of an object, even within “core” classes… You point out a fair problem with custom classes, but consider .type = "DodecahedronBufferGeometry", in core. There’s probably no code that really needs to know it’s anything but a BufferGeometry, On the other hand, the difference between Geometry and BufferGeometry is much more important. I don’t see an easy rule for when .type should be inherited, so I think it’s simpler to consider it a minification-safe alias of constructor.name, and to pretty much ignore it as much as possible, except perhaps as a human-readable label.

That said, I believe all existing uses of .type could be implemented nicely by other means. For toJSON, like your example above, that is pretty easy:

class Object3D {
  toJSON ( meta ) {
    // ...
    meta.object.type = 'Object3D';
    // ...
  }
}

class Mesh extends Object3D {
  toJSON ( meta ) {
    meta = super.toJSON( meta );
    meta.object.type = 'Mesh';
    // ...
  }
}

This does mean every subclass would need to override toJSON, which isn’t true now, but is certainly not out of the question. Arguably subclasses should have fromJSON methods as well, so that ObjectLoader can be given a type mapping to deserialize things it doesn’t know about yet, but that’s harder and maybe not urgent.

Also — I’m not sure why object instanceof Mesh isn’t a pattern we use… are there some prototype shenanigans that make it unreliable now? Maybe that will be fixed with ES6 classes?

[donmccurdy]

Rephrasing slightly, as two parts of that are my opinion rather than fact:

this.type is should be only used for serialization, since isFoo (and instanceof maybe in the future?) is should be used internally to determine typeness, subclasses (e.g. examples/jsm/objects/Fire.js) should not set this.type unless there’s some corresponding way for ObjectLoader to handle it (which there isn’t currently).

EDIT: That said, the uses of .type in the core library do look pretty minimal already.