file input : optionally return File[]

[ppierre]

It would be nice if we could optionally return File[] instead of { file:File; name:string }[] for value of file input.

In React code we can read SO Formik file input:

onChange={(event) => {
   if (event.currentTarget.files) {
       formik.setFieldValue(
           "file",
            event.currentTarget.files[0]
        );
   }

They extract the useful values of files property as you do in Formkit.
But FormKit field input map this to { file:File; name:string }[]

Would it be possible to add a boolean option to use the original files property as value ?

Maybe I am wrong but it seems you did this just to make FileList iterable in createSection.

Replacing the forloop in /packages/inputs/src/features/files.ts#L91 by:

// not tested
files = Array.from(e.target.files.length)

It should make it iterable.

And/Or:

type FormKitFile = File | {
name: string
  file?: File
}

Maybe just a boolean option to switch between the actual `for`loop and an `Array.from`

I am asking this because going around  your personal `FormKitFile` may take [more code than changing the original type](https://github.com/patmood/pocketbase-typegen/issues/65#issuecomment-1565356405). I understand that some other may rely on the actual format. So I propose a boolean option.

I can try to test my idea and propose a patch if there is hope for it ?

[fenilli]

You can still get the FileList using @change like so https://formkit.link/8eb69e78045ad31b8e6d1c62e9b1bc96 I will leave to @justin-schroeder to see if there is a better way to make it using a plugin or hook that doesn't break the code.

[ppierre]

The shorter I did get was kinda :

const nvlMaison = ref()

const schema = [
{ 
  name:"images"
  type:"file"
  onchange: (e: Event) => {
    nvlMaison.value = {
      ...nvlMaison.value,
      // @ts-ignore Impossible to assign type `File[]` to type `string[]`
        images:Array.from(e.target.files)
    }
  }
}
]

Because I have to get the files back into the form.

The problem isn't that's difficult. Is that it is uneasy and superfluous!

I can even more easily ignore it and process {name:string, file:File} in my 'back end'. It is what I do actually. But it leads to this discussion: patmood/pocketbase-typegen#65

[justin-schroeder]

I’m not entirely opposed — although I’m curious what your submission strategy is. Are you creating a FormData object in your submit handler or just allowing a directly submit via action on the form. Obviously in the later case, your FormData would act just like any other field submission, but in the former you would need to craft your FormData appropriately anyway, so there is an interstitial phase here that might be worth sussing out a bit more.

Another reason for the wrapper object { file: File, name: string } is that it allows us to put arbitrary data in there in the future which will inevitably be needed once we start introducing much more complex uploader inputs.

I’m sympathetic to the idea though and happy to get something worked out here.

[ppierre]

I submit the form by passing a FormData to PocketBase API : so yes extracting the file Object : it's a no brainier.
But I wanted to type my code and @patmood/pocketbase-typegen is using string[] for image fields as like (all) other back-end the file URL is build by an id.
I did ask him to change the type to a polymorphic one (ex: (string | (Custom = never))[] ). But he asked : why not "always" (string | {name:string, file:File})[]...
So I looked deeper and came to the conclusion: File[] seem more common and practical than {name:string, file:File}[]

In the end I intend to write a form who create an update seamlessly. I wrote a wrapper around PocketBase submission to process the File value. Having to look for File[] or {name:string, file:File}[] isn't the problem. Having the type automatically generated is.

So having (string | File)[] seem a good default. And you could propose a "Pro" component who take a function to process file id string when present and display a file selector otherwise. I suggest that because it seems a common use case (to me at least).

So File or {name:string, file:File} don't matter too much. The former simply seem more standard and maybe on day PocketBase JS client will automatically process {key: File[]} but the later: I don't think so.