bug: custom decorators are not invoked for state properties

[jgroth]

Prerequisites

• I have read the Contributing Guidelines.
• I agree to follow the Code of Conduct.
• I have searched for existing issues that already report this problem, without success.

Stencil Version

2.19.0

Current Behavior

If a property is decorated with both @State and another decorator, the code for the other decorator will never be invoked.

In the following component nothing will be logged to the console with Stencil 2.19.0. It works perfectly in 2.18.1. Probably introduced in #3614

const MyDecorator: () => PropertyDecorator = () => {
  return (target: Object, propertyKey: string) => {
    console.log({target, propertyKey});
  };
};

@Component({
  tag: 'my-component',
  shadow: true,
})
export class MyComponent {
  @State()
  @MyDecorator()
  decoratedProp: any;
}

After inspecting the compiled javascript files, the TypeScript __decorate helper function is missing for the component in 2.19.0, and is present in 2.18.1

Expected Behavior

Decorators added to properties also decorated with @State should be invoked

Steps to Reproduce

Create a new component with a property decorated with both @State and something else. The other decorator will not work

Code Reproduction URL

https://github.com/jgroth/stencil-decorator-bug

Additional Information

No response

[alicewriteswrongs]

Hello @jgroth, thanks for filing the issue and for providing a reproduction case! I just checked this out and was able to confirm that this is an issue, custom decorators worked great in 2.18.x but the 2.19.0 release broke them because of this change: #3614

In short, in order to support emitting ES2022+ we needed to change some parts of how we support the built-in Stencil decorators, and unfortunately due to some oversight on our part that change stepped on custom decorator support.

This is a problem we plan to fix, and something the team is actively looking into. I'm going to label this so we can ingest it into our internal backlog and prioritize it going forward.

Thanks again for filing the issue, and stay tuned for updates soon!

[jgroth]

Thanks for the quick reply! Any estimate on a timeline when it might be fixed?
This is a quite serious breaking change for us and will prevent us from upgrading. We use this quite extensively to reduce the amount of boilerplate we have to write when connecting a component to a Redux state, e.g.

class MyComponent {
    @State()
    @SelectCurrentUser()
    private currentUser: User;
}

[alicewriteswrongs]

@jgroth ah sorry that it broke a common pattern you all are using. Part of the sticky bit with this issue is that we need to do some discovery work to figure out exactly the right way to address this — this doesn't mean that it will take eons to address, but just that at present I don't have a clear roadmap of exactly how we'll fix it in my head, so I can't commit to a specific timeline at present.

However! That said, the ticket for doing this work has been pulled in to our next sprint, so we will start work on it relatively soon.

[Dayvisson]

Hello @alicewriteswrongs, thanks for your attention in this subject.
Does you have any updates about this issue?
We are looking foward to use stencil 3.0, but this issue is preventing us from upgrading too.

[alicewriteswrongs]

Hey @Dayvisson, thanks for following up on this and keeping the fire burning here. We're currently doing the discovery / research work I mentioned about about how Stencil should handle decorators going forward. The recent inclusion of ECMAScript standard-compliant decorators in TypeScript 5.0 has increased the urgency of addressing this, as we need to determine how we can 1) support upgrading to TypeScript 5.0 2) support Stencil's current built-in decorator behavior and 3) support user-defined custom decorators.

The wrinkle is that Stencil's built-in decorators are essentially implemented using custom TypeScript transformers (transformations on the TypeScript syntax tree that run during the compilation process) and they aren't directly compatible with either the decorators that TS developers have been able to use for a few years with the experimentalDecorators flag or with ECMAScript decorators as documented in the current TC39 proposal.

So we're evaluating what to do here. Once we have a firmer idea of what we think the right path forward is here I will make sure to get your feedback on it, as we do want to make sure that using custom decorators is supported in Stencil in a way that jibes with the community's existing workflows.

Thanks again for pinging, and apologies that this has been open a while!

[jgroth]

Any updates on this? 🙂

[alicewriteswrongs]

Hey @jgroth unfortunately I don't have anything specific to share at present as far as a timeline for addressing this or more on our specific thinking on how to allow for custom decorators in Stencil going forward. At present the loose plan is to refactor how Stencil's current decorators are implemented by the Stencil compiler, basically re-implementing them as standards-compliant decorators which can be used without any custom compiler support (or possibly with more minimal support than is needed right now). That rough idea hasn't really been proven out yet though, so definitely subject to change.

Right now I can also say we're close to clearing a few big things off of our plates which will free us up to look at the decorator issue more closely in general. I know it's been a while without any updates, but we do still want to support custom decorators!

[jgroth]

This is honestly a mess. I was going to try and see if we could update our code to use the new decorator syntax from TypeScript 5, but that does not seem to be supported either. The code does compile even if VSCode gives a lot of errors and complains about the Stencil decorators when I remove experimentalDecorators from tsconfig, but the decorator code is not executing.