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

[Feature] Stand alone td-file-browse component. #326

Closed
emoralesb05 opened this issue Feb 6, 2017 · 5 comments
Closed

[Feature] Stand alone td-file-browse component. #326

emoralesb05 opened this issue Feb 6, 2017 · 5 comments

Comments

@emoralesb05
Copy link
Contributor

Feature Request

It would be nice to have 60% of the file-upload code as stand alone for file selection (without upload). This throwing a (selected) event when a file is selected and an API to get the selected file + clear it (up for debate on the API).

Screenshots or link to CodePen/Plunker/JSfiddle

What is the expected behavior?

Acting as a <input file="type"> but following the MD specs.

What is the motivation / use case for changing the behavior?

Create an atom for reusability inside and out the file-upload.

@thekalinga
Copy link

thekalinga commented Feb 14, 2017

This is very much required as currently the upload part has its own way to push the file. This makes the API unusable incase if the user choses to use APIs like custom interceptors that validate, enrich actual request before sending to server, such as this [which I happen to rewrite based based on an existing implementation]

@emoralesb05
Copy link
Contributor Author

Agree, but i think you have a misunderstanding on the how the td-file-upload works atm.. since its not binded to any service or way of pushing to the server at all.

Its (upload) event returns the selected file(s) (no server call done at all), and from there you can send it to the server any way you like. Its only called (upload) by name since its a representation of pressing an upload button, but the developer still has to do the call and provide that implementation (be it adding interceptors, validations or any service for that matter)

The reason we want to split it into 2 parts is to give more flexibility UI wise, and create more atomic components.

@thekalinga
Copy link

Thanks for the detailed explanation. My understanding was quite wrong.

Based on your explanation, I feel that upload is a bit misleading to begin with.

Here is my understanding of what user's expectations are

  1. Whether file(s) are selected (or) not
  2. When they are selected
  3. Ability to bind the files to model using ngModel/formControl, so that this info can be retrieved later, when the user trigger actual server push
  4. Make the upload button look like a material button & customise color
  5. Ability to customise text shown, before & after selection (based on the files selected, via a callback)
  6. Ability to specify what types of files should be allowed to be selected & how many

Given the above requirements, I dont see a reason for the existence of upload event, just select should be good enough (gets triggered as soon as the user selects/drops file(s), which developer can optionally bind to) + component binding (which is required to know what files are selected, irrespective of whether user bound to select event or not).

@emoralesb05
Copy link
Contributor Author

emoralesb05 commented Feb 15, 2017

You basically described the new td-file-input which we created a PR earlier today. #339

@emoralesb05 emoralesb05 added this to the Beta 2 milestone Feb 15, 2017
@thekalinga
Copy link

I still dont get the reasoning behind having td-file-upload?

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