Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Property decorator not working anymore #44449

Closed
maccesch opened this issue Jun 4, 2021 · 7 comments
Closed

Property decorator not working anymore #44449

maccesch opened this issue Jun 4, 2021 · 7 comments
Labels
Question An issue which isn't directly actionable in code

Comments

@maccesch
Copy link

maccesch commented Jun 4, 2021

Bug Report

Using a property decorator doesn't seem to work anymore. In the playground it does work however (see links below).

🔎 Search Terms

typescript 4.3 property decorator

🕗 Version & Regression Information

  • This changed between versions 4.2 and 4.3

⏯ Playground Link

Interestingly this bug doesn't occur in the playground. Maybe it is linked to modules somehow? This is the link to the repo.

Only the index.ts and the C1.ts are relevant.

💻 Code

The difference seems to be that for this TS code

function dec(proto, key) {
  Object.defineProperty(proto, key, {
    get() { ... }
    set(value) { ... }
  });
}

class C {
  @dec
  foo: string;
}

In the playground sth like this JS is generated:

class C {
}
decorate(C, 'foo', dec);

while in my example project this JS is generated:

class C {
  foo;
}
decorate(C, 'foo', dec);

🙁 Actual behavior

The code behaves as if the decorator is never executed (it is however).

🙂 Expected behavior

The simple field should have been replaced by the property with getter/setter.

@MartinJohns
Copy link
Contributor

The playground emits the same code when you turn the flag useDefineForClassFields on.

@maccesch
Copy link
Author

maccesch commented Jun 5, 2021

Indeed! And it causes the same behaviour as in my repo. So is this expected behaviour? I suspect not, given that it makes this property decorator useless

@MartinJohns
Copy link
Contributor

No idea. Most likely unintended, but working as it should. The class fields feature is fairly new, and the decorator support is based on a deprecated proposal. Tho the decorator isn't even relevant here - it's working perfectly fine and as it should.

What doesn't work as you expect is the Object.defineProperty. You can find more details here: https://github.com/tc39/proposal-class-fields#public-fields-created-with-objectdefineproperty

@2-5
Copy link

2-5 commented Jun 5, 2021

I have the same problem, upgrading TypeScript from 4.2 to 4.3 broke my Vue components which uses vue-property-decorator:

import Vue from "vue"
import { Component, Prop } from "vue-property-decorator"

@Component
export default class Test extends Vue {
  @Prop(Number) readonly id!: number

  readonly idStr: string = this.id.toString()
}

this.id will be undefined when the idStr value is initialized, instead of the passed in property number.

Setting useDefineForClassFields to false fixes the problem. But the docs insist that false is the default value anyway, which seems untrue, and there is nothing in the release notes regarding this change.

@fatcerberus
Copy link

Are you targetting esnext? If so, class fields are supported natively, and per spec, native class fields use [[Define]] semantics. I would consider it more surprising when targeting ESNext if I didn't get native class fields by default.

@maccesch
Copy link
Author

maccesch commented Jun 6, 2021

Ok all that makes sense. Is there a recommended way or alternative to these kinds of property decorators? They do provide a nice way to reuse getter / setter code.

@RyanCavanaugh RyanCavanaugh added the Question An issue which isn't directly actionable in code label Jun 8, 2021
@typescript-bot
Copy link
Collaborator

This issue has been marked as 'Question' and has seen no recent activity. It has been automatically closed for house-keeping purposes. If you're still waiting on a response, questions are usually better suited to stackoverflow.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Question An issue which isn't directly actionable in code
Projects
None yet
Development

No branches or pull requests

6 participants