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

Changing placeholder in file upload map #2459

Open
ThirVondukr opened this issue Mar 15, 2024 · 3 comments
Open

Changing placeholder in file upload map #2459

ThirVondukr opened this issue Mar 15, 2024 · 3 comments

Comments

@ThirVondukr
Copy link

ThirVondukr commented Mar 15, 2024

Currently with multi file upload file number is always added at the eng (e.g. file.0, file.), and I have an input for a mutation like this:

input FileInput {
  file: Upload!!
}

input MyInput {
  files: [FileInput!]!
}

Which would require me to have keys input.files.{Placeholder Here}.file, which doesn't seem currently possible or simply isn't documented.
It works if I construct that string myself, but then I obviously can't use multi file upload with altair client

Describe the solution you'd like
I think some sort of placeholder could be added, like {} or $ which would be replaced by the file number

Additional context
Example with manually mapping files:
image

@imolorhe
Copy link
Collaborator

@ThirVondukr is what you are describing something that is supported by the GraphQL multipart request spec?

Assuming we added this placeholder approach to Altair, let's consider how it would work:

Single mode means there is a single named file variable involved (i.e. it is not a list, so no number in the variable name/path) and the GraphQL type for the variable is not a list type

Multiple mode means there is a list of files assigned to one named file variable, which means each individual file is referenced by a number index (corresponding to the position of the file in the file list)

Using the example you have above for the placeholder, input.files.$.file, the $ placeholder is meant to correspond to the position of the file in the file list, which means for each expanded entry (input.files.0.file, input.files.1.file, etc), there can only be one file, so this can only be single mode (although you might be considering input.files as the "multiple" part but seems like a different thing from what you're describing) (or can you imagine how this can be multiple mode, with e.g. input.files.0.file having a [Upload!]! list type?)

While this will be a quality-of-life improvement over what we have today, it doesn't enable any new use cases. Does that summarize this properly?

@ThirVondukr
Copy link
Author

ThirVondukr commented Jun 16, 2024

Honestly I'm not sure if multipart spec explicitly supports that, but you can add/pass files into nested inputs.
I don't think placeholder makes a lot of sense sense to use with single file inputs.
Since I created the issue some time ago I don't remember a lot of details, but placeholders aren't something that should be explicitly supported by the multipart spec since it's purely client side, for example that's how I've done it in my python test client:

response = await authenticated_graphql_client.query(
    QUERY,
    variables={"input": input},
    files={
        "input.arts.$.image": [
            GraphQLFile(
                name=f"{i}.png",
                buffer=create_dummy_image(),
                content_type="image/png",
            )
            for i in range(arts_count)
        ],
    },
)

internally it just unwraps it into a list of inputs with names such as input.arts.0.image, etc:

for i, file in enumerate(file_list):
    id_ = str(uuid.uuid4())
    if placeholder in key:
        file_key = f"variables.{key.replace(placeholder, str(i))}"
    else:
        file_key = f"variables.{key}.{i}"

https://gitlab.com/dpy.su/manga/-/blob/ce21ba4dcedc9a5f3e5ad901dd94345dc5367772/tests/adapters/graphql/client.py#L36

@ThirVondukr
Copy link
Author

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants