feat: Avoid class fields all-together #14887
Conversation
size-limit report 📦
|
| @@ -137,59 +189,4 @@ class SyncPromise<T> implements PromiseLike<T> { | |||
| }); | |||
| }); | |||
| } | |||
|
|
|||
| /** JSDoc */ | |||
| private readonly _resolve = (value?: T | PromiseLike<T> | null) => { | |||
There was a problem hiding this comment.
l: Instead of defining these fields in the constructor, can we declare them as regular methods (i.e. without the assignment)? I might be missing something as to why we didn't do this before though
So basically, like the public methods above, just as private? (Which I'm aware doesn't prevent them from being called externally but that should be fine)
There was a problem hiding this comment.
we need to do bind then a bunch of times, which... is also possible probably, let me check the bundle size diff!
There was a problem hiding this comment.
I rewrote this here to generally be a bit cleaner, so this should make more sense now!
| * be hidden. Likewise, moving a different window to cover the contents of the | ||
| * page will also trigger a change to a hidden state. | ||
| */ | ||
| private _handleVisibilityChange: () => void = () => { |
There was a problem hiding this comment.
same question as with syncpromise. But I feel like I'm missing something 😅
There was a problem hiding this comment.
here this is def. "needed" because we need to un-register the callbacks again, for which we need the same function instance. so we cannot use fn.bind(this) here. I added a comment for this here!
|
|
||
| /** | ||
| * Custom instrumentation for nestjs event-emitter | ||
| * | ||
| * This hooks into the `OnEvent` decorator, which is applied on event handlers. | ||
| */ | ||
| export class SentryNestEventInstrumentation extends InstrumentationBase { | ||
| public static readonly COMPONENT = '@nestjs/event-emitter'; |
There was a problem hiding this comment.
@chargome & @andreiborza I do not think these are needed/do anything, looking through the instrumentation base class code 🤔
There was a problem hiding this comment.
I agree, not sure why I copied it in the first place 👍
We already have an eslint rule to avoid class fields, but had exceptions for static fields as well as for arrow functions. This also leads to bundle size increases, so removing the exceptions and handling the (few) exceptions we have there should save some bytes. Additionally, this has additional challenges if we want to avoid/reduce polyfills, as class fields need to be polyfilled for ES2020, sadly.
6ad56f1 to
b2d4ca2
Compare
We already have an eslint rule to avoid class fields, but had exceptions for static fields as well as for arrow functions.
This also leads to bundle size increases, so removing the exceptions and handling the (few) exceptions we have there should save some bytes.
Additionally, this has additional challenges if we want to avoid/reduce polyfills, as class fields need to be polyfilled for ES2020, sadly.
Found as part of #14882