Get the class name of ES6 class instance
Asked Answered
G

5

197

Are there any 'harmonious' ways to get the class name from ES6 class instance? Other than

someClassInstance.constructor.name

Currently I'm counting on Traceur implementation. And it seems that Babel has a polyfill for Function.name while Traceur doesn't.

To sum it all up: there was no other way in ES6/ES2015/Harmony, and nothing is expected ATM in ES.Next.

It may provide useful patterns for unminified server-side applications but is unwanted in applications meant for browser/desktop/mobile.

Babel uses core-js to polyfill Function.name, it should be loaded manually for Traceur and TypeScript applications as appropriate.

Gnome answered 27/3, 2015 at 21:31 Comment(5)
I came across the same issue; for Traceur the only solution was to parse the actual class code itself to extract the name, which I don't think qualifies as harmonious. I just swallowed the pill and switched to Babel; Traceur's development seems to be somewhat stagnant, and many ES6 features are poorly implemented. As you mentioned, instance.constructor.name and class.name return the class name in proper ES6.Catalonia
Seems to be the only way.Ieshaieso
Is this in the ES6 standard?Rima
It's worth mentioning that someClassInstance.constructor.name will get mangled if you uglify your code.Pithos
#2648793 Might want to look at this, should work w/ .constructor.Intake
T
252

someClassInstance.constructor.name is exactly the correct way to do this. Transpilers may not support this, but it is the standard way per the specification. (The name property of functions declared via ClassDeclaration productions is set in 14.5.15, step 6.)

Trinidadtrinitarian answered 31/5, 2015 at 17:43 Comment(8)
That's what I was afraid of. Are you aware of any reasonable polyfill for that? I've tried to figure out how Babel does that but had very little success.Gnome
I don't really know what you mean by a polyfill for a language feature (classes).Trinidadtrinitarian
I mean the polyfill for constructor.name. It seems that Babel has it implemented, but I did not succeed in understanding how it does that.Gnome
I tried on Firefox Nightly (which supports basic classes) and it returned the string "constructor" instead of my class name "Hello" :(Mayor
There's a reason it's not in Firefox release yetTrinidadtrinitarian
@estus someClassInstance.constructor is a Function. All Functions have a name property that's set to its name. That's why babel doesn't need to do anything. Please see developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/…Animated
@Animated It appears that Babel persistently promotes core-js polyfills (including a polyfill for Function.name), that's why some Babel builds may work out of the box in all browsers.Gnome
@estus constructor.name is the name of the function/class, this is generally set on the function's prototype. So if you have function/class like function MyClass(){} then, to make sure instances of MyClass always have a .constructor property, you would set it via MyClass.prototype.constructor = MyClass, so now you have let myInst = new MyClass(); console.log( myInst.constructor.name ) // MyClassIsoline
C
66

As @Domenic says, use someClassInstance.constructor.name. @Esteban mentions in the comments that

someClassInstance.constructor is a Function. All Functions have a name property...

Thus, to access the class name statically, do the following (this works with my Babel version BTW. According to the comments on @Domenic your mileage may vary).

class SomeClass {
  constructor() {}
}

var someClassInstance = new SomeClass();
someClassInstance.constructor.name;      // === 'SomeClass'
SomeClass.name                           // === 'SomeClass'

Update

Babel was fine, but uglify/minification did end up causing me problems. I am making a game, and am creating a hash of pooled Sprite resources (where the key is the function name). After minification, every function/class was named t. This kills the hash. I am using Gulp in this project, and after reading the gulp-uglify docs I discovered there is a parameter to prevent this local variable/function name mangling from happening. So, in my gulpfile I changed

.pipe($.uglify()) to .pipe($.uglify({ mangle: false }))

There is a trade-off of performance vs readability here. Not mangling the names will result in a (slightly) larger build file (more network resources) and potentially slower code execution (citation needed - may be BS). On the other hand, if I kept it the same I would have to manually define getClassName on every ES6 class - at a static and instance level. No thanks!

Update

After the discussion in the comments, it seems like avoiding the .name convention in favor of defining those functions is a good paradigm. It only takes a few lines of code, and will allow full minification and generality of your code (if used in a library). So I guess I change my mind and will manually define getClassName on my classes. Thanks @estus!. Getter/Setters are usually a good idea compared to direct variable access anyways, especially in a client based application.

class SomeClass {
  constructor() {}
  static getClassName(){ return 'SomeClass'; }
  getClassName(){ return SomeClass.getClassName(); }
}
var someClassInstance = new SomeClass();
someClassInstance.constructor.getClassName();      // === 'SomeClass' (static fn)
someClassInstance.getClassName();                  // === 'SomeClass' (instance fn)
SomeClass.getClassName()                           // === 'SomeClass' (static fn)
Camilacamile answered 16/9, 2016 at 1:1 Comment(5)
Disabling mangling completely is not a very good idea because mangling contributes to minification a lot. It isn't very good idea either to use the subject in client-side code in the first place, but the classes can be protected from mangling with reserved Uglify option (a list of classes can be obtained with regexp or whatever).Gnome
Very true. There's a trade-off of having a larger file size. Looks like this is how you can use RegEx to prevent mangling for only select items. What do you mean it "isn't a very good idea either to use the subject in client-side code"? Would it present a security risk in some scenarios?Camilacamile
Nope, just what was already said. It is normal for client-side JS to be minified, so it is already known that this pattern will cause problems for the app. Extra one line of code for class string identifier instead of neat name pattern may just be a win-win. The same thing may be applied to Node, but to a lesser extent (e.g. obfuscated Electron app). As a rule of thumb, I would rely on name in server code, but not in browser code and not in common library.Gnome
OK so you're recommending manually defining 2 getClassName functions (static & instance) to get around mangling hell & to allow full minification (without an annoying RegEx). That point about the library makes a lot of sense. Makes a lot of sense. For me, my project is a self-made small Cordova app, so those aren't really problems. Anything beyond that I can see these issues rising up. Thanks for the discussion! If you can think of any improvements to the post, feel free to edit it.Camilacamile
Yes, I've initially used name for DRYer code to extract the name of the entity that uses class (service, plugin, etc) from class name, but in the end I've found that it duplicating it explicitly with static prop (id, _name) is just most solid approach. A good alternative is to not care about class name, use a class itself (function object) as an identifier for an entity that is mapped to this class and import it wherever needed (an approach that was used by Angular 2 DI).Gnome
T
17

Getting class name directly from class

Previous answers explained that someClassInstance.constructor.name works just fine, but if you need to programmatically convert class name into a string and don't want to create an instance just for that, remember that:

typeof YourClass === "function"

And, since every function has a name property, another nice way to get a string with your class name is to just do:

YourClass.name

What follows is a good example of why this is useful.

Loading web components

As the MDN documentation teaches us, this is how you load a web component:

customElements.define("your-component", YourComponent);

Where YourComponent is a class extending from HTMLElement. Since it is considered good practice to name your component's class after the component tag itself, it would be nice to write a helper function that all your components could use to register themselves. So here's is that function:

function registerComponent(componentClass) {
    const componentName = upperCamelCaseToSnakeCase(componentClass.name);
    customElements.define(componentName, componentClass);
}

So all you need to do is:

registerComponent(YourComponent);

Which is nice because it's less error-prone than writing the component tag yourself. To wrap it up, this is the upperCamelCaseToSnakeCase() function:

// converts `YourString` into `your-string`
function upperCamelCaseToSnakeCase(value) {
    return value
        // first char to lower case
        .replace(/^([A-Z])/, $1 => $1.toLowerCase())
        // following upper chars get preceded with a dash
        .replace(/([A-Z])/g, $1 => "-" + $1.toLowerCase());
}
Trilateration answered 15/9, 2018 at 22:35 Comment(2)
Thanks. The example is client-side. As it was already mentioned, there are some problems with using function names in browsers. Almost every browser piece of code is expected to be minified but this will ruin the code that relies on function name.Gnome
Yes, you're totally right. The minifier would have to be configured not to touch class names for this approach to work.Trilateration
L
2

For babel transpilation (before minification)

If you are using Babel with @babel/preset-env, it is possible to keep classes definitions without converting them to functions (which removes the constructor property)

You can drop some old browser compatibility with this configuration in your babel.config / babelrc:

{
  "presets": [
    ["@babel/preset-env", {"targets": {"browsers": ["> 2%"]}}]
  ]
}

More informations about targets : https://babeljs.io/docs/en/babel-preset-env#targets

For babel minification (after transpilation)

It looks there is no easy solution right now ... We need to look at mangling exclusions.

Ladoga answered 26/5, 2020 at 16:6 Comment(4)
Can you explain further how this is supposed to help with minification? class Foo {} will be minified to something like class a{} with any target. There will be no Foo word in minified source code.Gnome
Honestly I did not dig more than the documentations and the fact it helped me using this configuration ... I am using ECSY into babel transpiled project and it require this param for getting valid class names : github.com/MozillaReality/ecsy/issues/119Ladoga
I see. This is very specific to the code you dealt with. E.g. names may be preserved for ES modules and ES6 because export class Foo{} cannot be efficiently uglified further but this may be different in other places, we cannot know how exactly without having a good idea what happens with specific code pieces at build time. Any way, this hasn't changed since 2015. It was always possible for some compilation configs and code. And I'd say this possibility is still too fragile to use class names for app logic. Class name you rely on may become garbage after one accidental change in source codeGnome
Ok I found what is hapenning by looking at the code. My solution fixes the transpilation of classes to functions. So it helps before the minification. But not with the minification problem. I have to continue digging because, I could not understand how all my code using constructor.name still works in the minified version ... illogical :/Ladoga
K
1

If you have control of the implementation of the class

I'm adding this here as it was the top of google when I was trying to figure out how to do it.

This seems to be working for me in node.

./SuperClass.js

'use strict';

/**
 * A super class
 *
 * To show that it works with inheritance too
 *
 * In my usage, I'm also extending the Error class
 */
module.exports = class SuperClass extends Error {
    constructor(message, options = {}) {
        super(message);
        this.name = this.constructor.name;
        // ...other shared construction functionality
    }
};

./SubClass.js

'use strict';

const SuperClass = require('./SuperClass');
/**
 * a sub class
 */
module.exports = class SubClass extends SuperClass {
    constructor(message, options = {}) {
        super(message, options);
        // ... specific sub class construction functionality
    }
};
SubClass.name; // -> 'SubClass'
let instance = new SubClass('message');
instance.name; // -> 'SubClass'

Obviously, again this only works with classes you have full implementation control over.

I would probably change it to _name or something else but this is to bring it in line with another library I'm using.

Knightly answered 8/9, 2022 at 14:47 Comment(2)
Since name instance property doesn't interfere with constructor property, I don't see problem here. Notice that name is still the problem for minified code https://mcmap.net/q/127814/-get-the-class-name-of-es6-class-instance , like frontend appGnome
Thanks for the heads up. To be honest, the project I'm working on isn't in production yet. I'll try and remember this so if I do minify/uglify the app and start getting any issues, I'll know where to look.Knightly

© 2022 - 2024 — McMap. All rights reserved.