However when testing our application on IE11 we have experienced that ::class.js.name fails (returns undefined), however ::class.simpleName works fine.
Any idea why ::class.js.name fails on IE11 and not other browsers?
And what is recommended?
And does JetBrains have any list of browsers and version of them that you intent to support?
::class.js returns merely a JavaScript constructor (which in turn is just a function). Function.name is a non-standard property (in ES 5.1), and not supported in IE. Also, minifiers usually rename functions, so personally I would not recommend relying on Function.name in production.
Yes. ::class returns KClass, which is part of Kotlin. KClass.simpleName returns name written to class metadata generated by Kotlin compiler.
@jstuyts it’s not a bug. JsClass is just an interface to JavaScript native API. We just provide direct access to it, we aren’t responsible on how it’s actually implemented in a certain browser/JS engine.
Okay, but the fact that you cannot assume the properties and functions to be present can only be deduced from the keyword external. I guess that I should know this when targeting JavaScript, but it would be nice if the documentation of the standard library only shows properties and functions that will work on all supported JavaScript platforms. Unlike regular JavaScript, it is not possible to test for the presence of properties and functions.
Sorry, but I don’t think we’ll do something like this. There are functions that might be useful, but unavailable on some platforms. This does not mean we should not provide these functions or their description to users. However, there are almost 60 versions of FF, 60 versions of Google Chrome, many versions of node.js, Phantom.js, etc, each with its own set of supported functions. It’s virtually impossible maintain something like this. Luckily, there’s existing catalog of functions supported on different platforms, called Can I use. What we can do here is to:
Give more attention to external declarations, either by giving warning in API description, changing color, icon, etc.
When possible, provide a link to caniuse.com. Unfortunately, it’s often impossible, since most of external declarations in stdlib are generated from WebIDL, and we simply have no way to link these declarations with corresponding entry in caniuse.com table.
Anyway, for now the rule is following: when you see a Kotlin/JS declaration marked with external modifier, and you in doubt, you can always refer to caniuse.com, or find corresponding article in MDN.