-
Notifications
You must be signed in to change notification settings - Fork 12.5k
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
Incorrect emit for parameter properties when using standard class fields #55132
Comments
I’d argue that it’s not OK because you’re potentially changing the initialization behavior of a bunch of unrelated properties just because the class constructor has some parameter props, which feels icky. If I enable |
We've done a similar transformation in the past, such as we do for |
I appreciate this fix will align the newer mode with the original intended behaviour. What are the chances this will be a breaking change for users of |
@robpalme As far as I can see, the pre-5.2 state is: Typescript doesn't error, but you may crash at runtime, depending on order of class fields vs parameter properties. Post-5.2: Typescript errors. So fixing this bug would avoid crashes or compile errors; that doesn't sound like a breaking change except in the very strictest of meanings where "I expected a crash but the program terminated successfully". |
@sandersn wrote:
Totally Agree! This bug (until fixed) forces us to stay with @fatcerberus wrote:
Exactly. As I understand it, the In general: regarding whether this bugfix maybe could be a breaking change or not, this is how I see it:
Final Note: (Example taken from https://ngrx.io/guide/effects) export class MoviesEffects {
loadMovies$ = createEffect(() => this.actions$.pipe(
ofType('[Movies Page] Load Movies'),
exhaustMap(() => this.moviesService.getAll()
.pipe(
map(movies => ({ type: '[Movies API] Movies Loaded Success', payload: movies })),
catchError(() => EMPTY)
))
)
);
constructor(
private actions$: Actions,
private moviesService: MoviesService
) {}
} |
Any news on this? It's 2024 now but because of this issue we're still forced to stick with Side note: this issue duplicates #45995 |
CC: @sandersn @rbuckton @alan-agius4 I think this issue really should be resolved rather sooner than later! I just found out that Angular has had to force-patch their users' tsconfig.json inside I can easily imagine this not ending well ... as soon as TypeScript will drop support for |
Pointed out by @rbuckton on #50971, based on the repro from that bug. When targetting ES2022 or higher, and leaving useDefineWithClassFields: true (the default) for that target:
Produces
Currently the compiler issues an error on
bug = this.facade.create()
to avoid the bad emit, but it might be better to change the emit when parameter properties are used:Unfortunately, this isn't standard initialisation order for class fields...so it's correct, but not standard. That's probably OK since parameter properties aren't standard.
The text was updated successfully, but these errors were encountered: