Resource type as generic

[ivanpopelyshev]

At some point we might move PixiJS to v4, but as far as I understand we cant do it now because real projects in production might use pre and libs that use pre (pixi-compressed, pixi-sound).

Anyway, for that future, there are two things i'm concerned about:

1. metadata field passed from add options to resource.
2. extra fields in Resource.

I propose to make Loader a generic with resource type param, and maybe do something about signal types inside Resource.

https://github.com/pixijs/pixi.js/blob/22c9cc00adaafbfd3a3f51dc74f3c9b4925686dd/packages/loaders/src/LoaderResource.ts#L9

That way we will be able to make our own PixiJS Resource that has all the extra fields. Of course it possible to make a proxy for both loader and resource and I made that kind of hacks many times, but its not for open-source lib :)

[englercj]

We've spoken about pre a bit briefly and AFAIK no one was using pre for anything but URL parsing which has a new API in v4. Are the use cases that aren't covered in v4?

As for metadata, like I mentioned on slack we can add it in pretty easily; just needs to get done.

I propose to make Loader a generic with resource type param, and maybe do something about signal types inside Resource.

I'm not sure making Loader generic is the right way to go because it doesn't actually solve the issue where any middleware can add any property to the resource. You'd only be able to document the pixi ones, and would have to centralize all properties that any pixi plugin might add.

I'm tempted to have an any field on a resource that middleware can put data into, because I'm not sure what a good way of documenting available properties would be.

[ivanpopelyshev]

I'm not sure making Loader generic is the right way to go because it doesn't actually solve the issue where any middleware can add any property to the resource. You'd only be able to document the pixi ones, and would have to centralize all properties that any pixi plugin might add.

When we worked with pixi-v4 typings, we could just override those definitions in d.ts files. now though it wont be possible because of modular design of typings. Or maybe its possible, I wlll try a workaround.

Even adding basic pixijs fields + pixi-spine fields will cover most of cases.

We've spoken about pre a bit briefly and AFAIK no one was using pre for anything but URL parsing which has a new API in v4. Are the use cases that aren't covered in v4?

Yes, I have the same experience.

The problem is that people will have to change their code. I'm not sure we can just turn off that thing in 5.3 without deprecation. Maybe we can do it in next one, 5.4

[englercj]

When we worked with pixi-v4 typings, we could just override those definitions in d.ts files. now though it wont be possible because of modular design of typings. Or maybe its possible, I wlll try a workaround.

Even adding basic pixijs fields + pixi-spine fields will cover most of cases.

I'm not suggesting you override the typings, I'm suggesting it is not possible for you to provide typings for metadata, or the additional fields that are added via middleware, and that to do so will just create incorrect typings. I think the right think to do is to type metadata as any and add a field to resource that is any that all middleware writes to. Or give Resource and index signature that returns any.

[englercj]

I've added metadata back in as any so users can write whatever they want to it, and so can middleware. I think this gives everyone the features they need, even though it is not compatible with v3.