Support FileInput Component

[sizer]

Summary 💡

When building admin application, a feature uploading files - like csv or etcetera - is often necessary.

Examples 🌈

https://retool.com/components/file-button
https://retool.com/components/file-input

Motivation 🔦

No response

[bytasv]

@prakhargupta1 could you please explain:

1. should this also store files in the database for future use?
2. what are we suppose to be able to do after uploading file?
3. what file formats are we suppose to allow?

It might be easier if at least one e2e scenario would be added how this feature is suppose to be used

[prakhargupta1]

1. should this also store files in the database for future use?
2. what are we suppose to be able to do after uploading file?

For now, let's just support uploading files through REST API. So it can act like the Button component having onClick event.

3. what file formats are we suppose to allow?

Can we support All file formats(<5Mb) for now and support restrictions later?

It might be easier if at least one e2e scenario would be added how this feature is suppose to be used

Example here

[bytasv]

@prakhargupta1 could you provide a more specific example or at least outline which part in the entire documentation refers to the actual usecase? In the link you shared I can only find explanation that the widget allows uploading files but it doesn't mention how those files can later be used:

• Should we have some UI to display uploaded files?
• Should we be able to read the content of uploaded file in the app or do we want to upload files only for linking them?

When I say "e2e scenario" I'm thinking about something like following:

1. I upload CSV
2. I can read content of that CSV file and render it in the Data grid component
   OR
3. I upload image
4. I can display image using image component
   etc..

IMO this is quite a large feature both in scope and functionality and we should have a bit more specific information

[apedroferreira]

I guess that for now we can just allow users to add a local file to a file input, client side, and then the file object can be accessed in the bindings panel, for example?
So then the user can potentially pass the file content to some API if they want to, in order to upload it for example?

[bytasv]

I guess that for now we can just allow users to add a local file to a file input, client side, and then the file object can be accessed in the bindings panel, for example? So then the user can potentially pass the file content to some API if they want to, in order to upload it for example?

That's what I'm trying to understand because doing that client-side only vs uploading to the backend are significantly different tasks

[Janpot]

as @apedroferreira suggests, intuitively I think it could make sense separating the file input component from the file uploading.

Perhaps we could start with a benchmark?

e.g. I noticed retool makes the files available on component state as an array of base64 strings.

Then try to figure out the trade-offs associated with the method

e.g. Does retool make it possible to inspect file names? How easy would it be to feed this array as FormData to a POST request?...

I think I'd at least be interested in how the retool/appsmith/openblocks family compares to dynaboard

[prakhargupta1]

Should we have some UI to display uploaded files?

No UI, just the Native File uploader should come.

Should we be able to read the content of an uploaded file in the app or do we want to upload files only for linking them?

Both of these. Like Pedro mentioned, the file content should be available in bindings for it to be used anywhere in an API. We should show all info related to file like name, file type, base64 string in bindings. Eg: Check the video at 4:34

Let's just first support file uploading in the minimal way possible. I'll see how Dynaboard does it.

[bytasv]

Should we have some UI to display uploaded files?

No UI, just the Native File uploader should come.

Should we be able to read the content of an uploaded file in the app or do we want to upload files only for linking them?

Both of these. Like Pedro mentioned, the file content should be available in bindings for it to be used anywhere in an API. We should show all info related to file like name, file type, base64 string in bindings. Eg: Check the video at 4:34

Let's just first support file uploading in the minimal way possible. I'll see how Dynaboard does it.

@prakhargupta1 what Pedro suggested is client side file upload - which basically means we are not uploading file anywhere except that we open that file for reading in browser. What you asked "For now, let's just support uploading files through REST API." is a full backend support for uploading and storing files.

Minimal way possible, I'd say is client side file read - would that be enough?

[prakhargupta1]

I meant the same: The file is available in the browser to be used as a binding, so that it can be used in a query to be uploaded through a REST API.

[prakhargupta1]

In v2, we can do the following:

1. Support multiple file uploading (this will also require a UI)
2. Read contents of the file. This can be helpful when someone uploads a photo that needs to be shown in the profile picture or a csv that is shown in a data grid.

How it works can also be found here: https://docs.superblocks.com/applications/components-library/file-picker