blueprint: @HotkeysTarget TypeError: class constructors must be invoked with |new|
Environment
- Package version(s): “@blueprintjs/core”: “^3.15.1”, “typescript”: “3.5.1”
- Browser and OS versions: Ubuntu 18.04, FireFox 67.0.2
Steps to reproduce
import { Hotkey, Hotkeys, HotkeysTarget } from "@blueprintjs/core";
@HotkeysTarget
export class MyComponent extends React.PureComponent<{}> {
public render () { return <div>Hello there</div> };
public renderHotkeys() {
return <Hotkeys>
<Hotkey
combo="up"
label="Up"
onKeyDown={() => { alert('Need to go up'); } }
/>
</Hotkeys>;
}
}
Actual behavior
The component cannot be rendered. I get an error that starts with this:
TypeError: class constructors must be invoked with |new|
HotkeysTargetClass
node_modules/@blueprintjs/core/lib/esm/components/hotkeys/hotkeysTarget.js:32
29 | tslib_1.__extends(HotkeysTargetClass, _super);
30 |
31 | function HotkeysTargetClass() {
> 32 | return _super !== null && _super.apply(this, arguments) || this;
| ^ 33 | }
34 |
35 | HotkeysTargetClass.prototype.componentWillMount = function () {
Full traceback available, but probably not needed.
Expected behavior
The component should be rendered and the hotkey should be working.
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 7
- Comments: 34 (17 by maintainers)
Commits related to this issue
- Implement workaround from @alxmiron at https://github.com/palantir/blueprint/issues/3604 for making the class annotations work. — committed to pmclachlan/blink-mind by deleted user 4 years ago
- fixing hotkeys target issue https://github.com/palantir/blueprint/issues/3604; fixing view > parts to not show submenu in certain cases — committed to TeselaGen/openVectorEditor by tnrich 4 years ago
I met the same error (but I dont use TS, just ES6 + webpack + babel).
This is a tanspiled to ES5
HotkeysTargetClassclass constuctor. The problem is that it expects_super(which isWrappedComponentactually) to be a function (ES5-style class). If in your code WrappedComponent is a ES6 class, it throws an error.I solved it by using
packages/core/lib/esnext/components/hotkeys/hotkeysTarget.jsinstead ofpackages/core/lib/esm/components/hotkeys/hotkeysTarget.js, because HotkeysTargetClass is declared in modern way there:I’m working on this as part of Blueprint v4.0 changes, it’s the next thing on my list, should be able to prototype something later this week.
Some thoughts on this: Create React App does not support decorators by default, see here.
I propose just moving away from decorators for now, as many libraries (e.g. MobX) have done, or at least adding another option for users to declare HotKeys, maybe a React hook.
@sgaloux I second you.
Used
create-react-app --typescriptin my project, I checked I have the same blueprint and react versions as the codesandbox thing, yet I get the error in my project.Also having es5 as target.
This seems like the best solution to me as well. I use nwb on top of webpack and don’t feel like digging into the babel stuff right now so just downgraded nwb to a previous version where everything was working. This is fine for the time being but it would be great to have a simple HOC solution.
@maclockard here’s what I see when I tried:
I got similar looking webpack errors when trying the “mainFields” solution.
I started suddenly to have the same problem. The strange thing is that I cannot reproduce it when I build the application (CRA + typescript) myself, but the CI build has the issue. I tried several versions of typescript / blueprint / react (I first thought that bumping to the latest version caused the problem but it didn’t).
Maybe this has to do with node version. I’m using 13.7.0 locally (no issue) but CI uses older versions (one env uses 8.x, the other I’m not sure).
Edit: I applied the same workaround as in commit just above and it did the trick 👍
This was fixed by https://github.com/palantir/blueprint/pull/3230.
Also @alxmiron it can be safe to add
esnexttoresolve.mainFieldseven if you support older browsers as long as you are using babel-loader and you are babeling your dependencies. Check out this blog post from the babel folks on their thoughts towards babeling deps.