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

fix: event mixin types #10543

Merged
merged 1 commit into from
May 17, 2024
Merged

fix: event mixin types #10543

merged 1 commit into from
May 17, 2024

Conversation

Zyie
Copy link
Member

@Zyie Zyie commented May 17, 2024

Ok so this PR was a fun rabbit hole 😄

Overview

The main overview of what this PR is actually changing is that i have removed the abstraction of IFederatedEventTarget in favour of just using Container. IFederatedContainer is still mixed into the Container, which means that all types should work as before.

I believe this change reflects a more accurate description of what object is stored in an FederatedEvent.

The benefits of this is that we don't need to do any typescript magic that decouples the two different implementations of EventEmitter e.g

This

export interface Container<C extends ContainerChild>
    extends Omit<PixiMixins.Container<C>, keyof EventEmitter<ContainerEvents<C> & AnyEvent>>,
    EventEmitter<ContainerEvents<C> & AnyEvent> { }

Becomes this

export interface Container<C extends ContainerChild>
    extends PixiMixins.Container<C>, EventEmitter<ContainerEvents<C> & AnyEvent> {}

What Is This Fixing

The current implementation revealed a nasty bug with using our PixiMixins that is hidden in v7 due to Container extending DisplayObject and everyone will be attaching there custom properties to Container, not DisplayObject, because of this we have never seen the issue.

Hopefully i can try and explain it here...

If you try to add your own properties to Container in v8 currently like this:

declare namespace PixiMixins {
    interface Container {
        overrideMethod(): void
		returnThis(): this
    }
}

Then you try to override and use these methods like:

class NewContainer extends Container {
    testProperty: number;
    override overrideMethod(layout: ComputedLayout) {}
}

const container = new NewContainer();
const container2 = container.returnThis();
container.testProperty // type error: does not exist

We get two TS errors:

  • Class 'Container defines instance member property overrideMethod, but extended class NewContainer defines it as instance member function.
  • Property 'testProperty' does not exist on type Container

The first issue is that typescript believe the overrideMethod is a property on Container and not a method. So it wants you to declare it like this

override overrideMethod = (layout: ComputedLayout) => {}

However this isn't accurate as if we wanted to declare it as a property it should be defined like this

declare namespace PixiMixins {
    interface Container {
        overrideMethod: ()=> void
    }
}

The second issue is that this is not being respected correctly. It should be returning NewContainer, however it always returns Container

Now I have zero idea what sort of typescript magic is going on that messes up these types so badly but the change here is minimal and seems to work.

Copy link

korbit-ai bot commented May 17, 2024

My review is in progress 📖 - I will have feedback for you in a few minutes!

Copy link

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit ed92806:

Sandbox Source
pixi.js-sandbox Configuration

Copy link

@korbit-ai korbit-ai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have reviewed your code and found 6 potential issues. To discuss my individual comments that I have added, tag me in replies using @korbit-ai.


Please react with a 👍 to my comments that you find helpful and a 👎 to those you find unhelpful - this will help me learn and improve as we collaborate.

Copy link
Member

@bigtimebuddy bigtimebuddy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like this change. Flattening the layers of abstractions for events is welcome.

@Zyie Zyie added ✅ Ready To Merge Helpful when issues are in the queue waiting to get merged. This means the PR is completed and has t v8 labels May 17, 2024
@Zyie Zyie added this pull request to the merge queue May 17, 2024
Merged via the queue into dev with commit dd74d11 May 17, 2024
4 checks passed
@Zyie Zyie deleted the fix/event-types branch May 17, 2024 12:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
korbit-code-analysis ✅ Ready To Merge Helpful when issues are in the queue waiting to get merged. This means the PR is completed and has t v8
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants