@uppy/core: add generic to getPlugin

[Murderlon]

It's a common use case to getPlugin and access something on it. Currently it's a bit awkward:

const state = (uppy.getPlugin('Transloadit') as Transloadit<any,any>).getPluginState()

This PR reintroduces the generic on getPlugin, so it's an improvement but also backwards compatibility with 3.x:

const state = uppy.getPlugin<Transloadit<any,any>>('Transloadit').getPluginState()

Unfortunately you must pass the generics, which should be optional but I don't know how to achieve that.

[github-actions]

Diff output files

No diff

[mifi]

wouldn't it be more elegant if we return the correct type based on the string value passed to getPlugin?

from chatgpt:

In TypeScript, you can use conditional types to return a different type based on a constant string value passed as an argument to a function. Here's an example:

type TypeMap = {
  type1: number;
  type2: string;
  type3: boolean;
};

function getValue<T extends keyof TypeMap>(type: T): TypeMap[T] {
  let value: TypeMap[T];

  if (type === 'type1') {
    value = 123 as TypeMap[T];
  } else if (type === 'type2') {
    value = 'hello' as TypeMap[T];
  } else if (type === 'type3') {
    value = true as TypeMap[T];
  }

  return value;
}

let a = getValue('type1'); // a is of type number
let b = getValue('type2'); // b is of type string
let c = getValue('type3'); // c is of type boolean

In this example, TypeMap is a mapping of string keys to types. The getValue function takes a key of TypeMap as an argument and returns the corresponding type from TypeMap. The actual implementation of getValue would depend on your specific use case.

[aduh95]

wouldn't it be more elegant if we return the correct type based on the string value passed to getPlugin?

I don't think that's possible, the id is user-provided, we can't know in advance what type it's going to be – or if there's going to be any plugin with that ID.

[aduh95]

We could also have a static method e.g. Transloadit.getPlugin(uppy, 'Transloadit'); another idea would be to change the function signature to be uppy.getPlugin(Transloadit, 'Transloadit'), and we could make the second argument optional, defaulting to arg1.constructor.name EDIT: I just tried that locally, and failed.

[Murderlon]

wouldn't it be more elegant if we return the correct type based on the string value passed to getPlugin?

Indeed not possible afaik. There might be one small chance at getting something to work like that, which is this todo I wrote here:

uppy/packages/@uppy/core/src/Uppy.ts

Lines 147 to 149 in c5d7808

	// TODO: can we use namespaces in other plugins to populate this?
	// eslint-disable-next-line @typescript-eslint/no-empty-interface
	interface Plugins extends Record<string, Record<string, unknown> | undefined> {}

Something along these lines, in every plugin:

declare module '@uppy/core' {
  export interface Plugins<M extends Meta, B extends Body> {
    'Transloadit': Transloadit<M, B>
  }
}

[mifi]

I don't think that's possible, the id is user-provided, we can't know in advance what type it's going to be – or if there's going to be any plugin with that ID.

but won't users 99% of the time write getPlugin with a constant string literal, like getPlugin('transloadit') (not getPlugin(someVariable))? and typescript is perfectly able to statically analyse string literals and create a proper return type for our built in plugins. of course it won't work with third party plugins but at least it will make the api more developer friendly 99% of the time

[mifi]

We could also have a static method e.g. Transloadit.getPlugin(uppy, 'Transloadit');

that could work

alternatively we could implement a new static API for accessing our built in plugins, like

uppy.transloadit?: TransloaditPlugin
uppy.dropbox?: DropboxPlugin
// and so on

or

uppy.plugins.transloadit?: TransloaditPlugin
uppy.plugins.dropbox?: DropboxPlugin
// and so on

[aduh95]

@mifi what I meant is that users can provide a different id, and we can't really predict what those are going to be (heck they could use the string 'Transloadit' to refer to the Dashboard)

uppy/packages/@uppy/aws-s3/src/index.ts

Line 339 in 35525ae

this.id = this.opts.id || 'AwsS3Multipart'

[mifi]

@mifi what I meant is that users can provide a different id, and we can't really predict what those are going to be (heck they could use the string 'Transloadit' to refer to the Dashboard)

maybe we should prevent people from using the string transloadit to refer to Dashboard etc (throw an error in such case), because in that case how can one even call getPlugin to get the real Transloadit plugin if the id transloadit refers to Dashboard?

then we can predict the return type in most cases, but of course if they have a custom plugin our return types can be unknown or some generic plugin type

[aduh95]

in that case how can one even call getPlugin to get the real Transloadit plugin if the id transloadit refers to Dashboard?

The Transloadit plugin would also have its own id, and that's what they'd need to pass

Let's not overthink it, this PR is already an improvement, no user has complained about this.

[Murderlon]

@mifi it's likely impossible. Maybe we could hack together something in the way I described, but then it won't work with different id's as @aduh95 pointed out, which wouldn't make it an acceptable solution.