Skip to content
This repository has been archived by the owner on Aug 1, 2024. It is now read-only.

[Question] How can I define custom EventType for a sub class of goog.ui.Component? #1099

Closed
pirosikick opened this issue Dec 2, 2020 · 2 comments

Comments

@pirosikick
Copy link
Contributor

I've defined custom EventType for a sub class of goog.ui.Component like following:

goog.provide('a.b.c.SomeClass');
goog.provide('a.b.c.SomeClass.EventType');

goog.require('goog.ui.Component');

a.b.c.SomeClass = class extends goog.ui.Component {
  /* some codes... */
}

/**
 * @enum {string}
 */
a.b.c.SomeClass.EventType = {
  CUSTOM_EVENT_A: '...',
  CUSTOM_EVENT_B: '...',
};

But, when I updated Closure Libray and Compiler to v20190709, the above code becomes causing JSC_HIDDEN_PROTOTYPAL_SUPERTYPE_PROPERTY_MISMATCH and JSC_HIDDEN_SUPERCLASS_PROPERTY errors.

How can I define custom EvenType for a sub class of goog.ui.Component with ES2015 class inheritance?

@shicks
Copy link
Member

shicks commented Dec 2, 2020

The short answer is you can't. This is actually a known issue that's blocking us migrating many of the goog.ui classes to ES6.

The underlying issue is that ES6 classes have class-side inheritance, and Closure Compiler (and TypeScript as well, FWIW) seem to want to enforce that static properties on a subclass are assignable to static properties on the base class. In my opinion, this is incorrect, since subclasses are not generally substitutable for base classes (see microsoft/TypeScript#4628 (comment) for a familiar example). But that's beside the point, it's unlikely to change any time soon.

Instead, the approach we recommend is to make this a module with "named exports". That is,

goog.module('a.b.c.someClass');

exports.SomeClass = class extends goog.ui.Component { ... }
/** @enum {string} */
exports.EventType = { ... }

This avoids needing to nest the enum on the class, which our internal TypeScript infrastructure doesn't even really support anyway (so there's another reason we're moving away from that pattern).

More broadly, I'd also recommend getting off of goog.ui entirely. It's been effectively unmaintained for years, and we continue to get more and more hesitant to touch anything about it as time passes.

@shicks shicks closed this as completed Dec 2, 2020
@pirosikick
Copy link
Contributor Author

@shicks Thank you for answering!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants