File Upload / upload completed

[figuerres]

I am looking at the code and trying to see if this is already created or missing and how to setup my code.

the uploader gets files added. the user clicks the upload all files button

is there an event i can pickup that tells me all the files have finished uploading ? i want to clear the queue and update my UI to show the files as uploaded to the server.

where to start ?

[AckerApple]

I can't be giving huge lengthy lessons but the following may help:

See the practical example seen here: https://github.com/AckerApple/angular-file/blob/development/README.md#examples

Review the functionality surrounding "manualFormDataUploadFiles". I do not use nor encourage anyone uses the "uploader" class to transmit files. That code approach is left over from the code I forked from ng2-file-upload. I'd get rid of the uploader class if people didn't need it from the code before my fork

[AckerApple]

If you use a more manual route, you'll have much better event control. So instead of answering your question, I'm asking you to change your approach for the hook-in you seek

[figuerres]

OK , but still the same basic question that i need to solve: how should i know that the file was uploaded ? is there an event i should wire up ?

can you make some small example ?

i know that the uploader from the old project did not have any events, i see that your code has events so i am looking for the right one to use .

[AckerApple]

In the practical example, a Promise is used. If you don't know what or how to use a Promise, then you need a little more knowledge.

It's relatively: uploadFunction().then().catch()

[AckerApple]

If none of that makes sense then you are way too behind on knowledge. Instead of callbacks or event emitting, a Promise is used.

You yourself have many many options on how to control the end of an upload. This is rather common knowledge I won't be supplying

[AckerApple]

Confirmed, the practical example has it all including an alert of success or a catched failure.

I'm not too fond of free knowledge. Free code yes but please refrain from turning to me for things that are documented.

[figuerres]

so you are dropping the old packages function code that uploaded the files and leaving that as an item the user of your package has to build ? if that is what you are doing then that is ok. just that i need to know that is what you are doing.

i saw the page with that code and i do understand it i was just not sure if that was your path or a work in progress.

[AckerApple]

I think we are on the same page.

Yes, the old uploader is there out of convenience. I'm sorry the examples still support that route but I sure do live by "release early, release often". Overtime those examples will be converted.

The only possible value I see in the FileUploader class, is that it has some legacy iFrame way to send files... Not much value to me as I wont work for any project that wants to support uncommon HTML5 browsers like IE11

[AckerApple]

Also, again I think, you can choose your own "event" handling.

By default the Angular Http class supports observers in which you register a function that is called at .emit() ... I prefer to use the rxjs import Promise enabler that makes Angular return Http calls as Promises.

Love love love dem Promises. I wrote my own Promise library that gets some attention (little): https://www.npmjs.com/package/ack-p

[figuerres]

having the old bit there and the new stuff you did is confusing at times....

possibly add comments to the old stuff that is is going to be removed etc.... then as folks read the code they can see that.

[AckerApple]

I have comment already there. I believe even yourself missed documentation that resulted in this issue report.

It's bound to happen and I'm more than fine to live through the issue reports of it. My attitude typically helps keep people at bay (or not intentionally, away).

Hey thanks again for your interest in this package. I very lightly care to help others. Pull requests are what I'm after with my public code.

[figuerres]

the promise is a good thing in general .

if i had the main app we are building where you could see it you would see a whole lot of ts services and all that....

also in my case i do need to support IE 11 in most of our stuff, we have a lot of clients that are not tech savy, we will be making IE 11 the only ie we support and trying to nudge them to use chrome or edge or some other main stream client. :--)

[AckerApple]

That's excellent to hear because a lot of other programmers are dying to try and support every browser and it's more of a killer on the industry than meets the eye

[figuerres]

with regard to pull requests: that is one thing i want to get up to speed with, i have no problem createing a repo, downloading a repo, posting updates to my own repo but i have not yet done a PR on any repo.

[figuerres]

Hey, i go wayy back at one time i had to deal with IE2 to 5 and Netscape V1 and 2 for dialup internet customers no less.... i also was on the IETF work group on spam back in the later 90's

[AckerApple]

They make pull request process so stupid simple on github

I was where you were. It starts with editing someone elses README files where their documentation is lacking... Such as, when you read a README on github, an icon exists somewhat along the lines of "fork and edit". Right after you fork, and then edit, its a dead easy button of "Make Pull Request" which contacts the package owner....

Anyway, not gonna read what I typed above but just get the drift that its mighty easy and starts with an easy README edit of someone elses code (causes a fork)

[AckerApple]

You should try editing my README file where you think more attention needs to be drawn to NOT using the FileUploader.

You would then become more than just a random friendship, of mine. We'd be like coworkers.

Seriously, you should try it while you have a package willing to have you goof off with it.

Enjoy!

[figuerres]

will check it out soon as i can, just got a request to fix a webservice bug.

[alignsoft]

Happy to see this package has been forked and is being maintained. I'm just in the process of understanding what's staying, what's going, and what the new code looks like that replaces what's being dropped. If I can help by making doc and code updates, I'll certainly do that via the pull request mechanism.

My only initial comment is the largest example that demonstrates all the functionality https://ackerapple.github.io/angular-file/ seems to lean pretty heavily on the uploader class, and from the discussion here it sounds like that's deprecated.

Does that mean that the uploader.queue shouldn't be used either, or that just the file-uploads mechanism should be handled differently?

If you can provide some additional insight, I'd be happy to pitch in cleaning up docs and examples.

[AckerApple]

Hey hey. Great to see another good looking face.

Yup, so you are mostly all right in your remarks. The future of the FileUploader and queue are undetermined as of right now. But I do think it would be best to act quickly to figure its future out.

List of semi-random thoughts

• I think FileLoader class may still hold value but think it should stand alone. The directives should NOT need the FileLoader class at all. Currently, the directives push to an unnecessary que array which typically requires manual clear or GC cycle to occur after ngOnDestroy break ref. I, Acker Apple, let the GC method occur and I never clear a que (risky business when compared to a [(files)] model)
• The examples page is what needs cleaned up hard core. I want to remove Bootstrap and slim the heck out of it plus reduce the use of FileLoader. Buttttttttttt no time today.
• I took the unit tests much further than they every were before. Really would like to finish ensuring thats working all mighty fine coverage wise (it works, not all functionality is tested).

I think thats it for now.

Unrelated, I got on a Florida radio show, talking about Flat Earth Theory. Did you know some people question if the earth is flat with actual doubt that it is round? I found the recording of my call in, edited the audio and posted to YouTube. Check it out, its long but worth listening with headphones on: https://www.youtube.com/watch?v=qja4MU-duxM

[alignsoft]

Honestly the mechanics of the uploader / queue and Bootstrap are what attracted me to the library in the first place, but the old implementation seemed incomplete and inaccessible (and all but abandoned).

I'm happy in a project to manage my own array of files, and for the library to give me the hooks to select files/images to add them to the array, then I can iterate over the array to pre-process them if need by, and then upload them. Being able to display thumbnails and image info in a list, and to do some processing on the selected files (resize, compress etc.) is extremely useful, especially when people can take massive pictures on their phones and try to upload them over a cell connection, so having accessible hooks for that is pretty important.

Maybe a useful step would be for you to provide an executive summary of the functionality you want the library to provide, and that will help determine what needs attention, and what needs to go.

[AckerApple]

I think my goals can also be simply stated that Im trying to do everything ng-file-upload did for AngularJs. That package is/was extra fantastic: https://github.com/danialfarid/ng-file-upload

If Bootstrap and having a FileUploader class first attracted you to this library, then I can fairly easily build some judgements and assumptions about your depth of knowledge and experience with advanced Html5 techniques. I like to sarcastically ask Bootstrappers if they even know at all how to use flexbox.

Yeah, I'm gonna say with cockiness: get with the times. You don't need an uploader class, you need to consolidate your uploads, gets, puts, patchs, and posts down to one or as little Services as possible. The more classes you have making uploads the more base urls and server addresses you have to manage on change AND THE BIG kicker is more error flow control instead of having one big application error handler for route failures. If it doesn't make sense, oh well, it's the difference between having a million catch promise handlers VERSUS one observer function that processes ANY Http failure.

Good luck figuring out your upload logic flow thru classes. It's not that hard

[AckerApple]

This happens to be some code in my life that I use to set just one error handler for all of my entire route requests INSTEAD of putting a catch on every request. If u interested:

Create Obsever: https://github.com/AckerApple/ack-angular/blob/src/src/AckApi.ts#L10

Observer emits to any registered listeners (same file same class): https://github.com/AckerApple/ack-angular/blob/src/src/AckApi.ts#L231

I POST all ngf results thru the same service that all my other classes use to get, put, post, patch, and so on so they all experience that same error control, security headers, and base href

[alignsoft]

I'm working with a small team with developers of varying degrees of skill. Bootstrap makes it much easier for everyone to build components with a consistent look and feel, and I don't have to teach everyone everything - the team got productive quickly, so before you knock Bootstrap, understand it has its place - not everyone has the luxury of pivoting to the new shiny all the time, or rolling your own everything - most of the time we're working against a deadline and a budget.

I'm not a purist, I'm a pragmatist - I need to get jobs done - period. They need to be maintainable, and I don't have any tolerance for shitty coding, but I make concessions sometimes in the interest of hitting a target and getting projects in on time and budget.

I don't want an uploader class in the component, but I do want to be able to accumulate a list of file's to be uploaded in the component, manage the list there and then pass the list off to a service to do the heavy lifting and return a list of success/error responses as appropriate. That's one thing I didn't like about the original library, is that uploader was self contained and you couldn't abstract out the http code into a centralized service where it belongs.

[AckerApple]

I keep up a certain amount of sassy talk to encourage blog like communications. I like your "fired up" response so I do hope any static is just that and nothing more.

I can hate on Bootstrap since I worked hard to escape from it and I've worked that extra hard road of educating my team out of it.... You have some judgement guesses on how maybe I've not used Bootstrap and that I am just hating on it for popularity sake. Bootstrap is meh, I'll admit I am being more than sassy/dramatic about it though. We've all learned just to install the dependencies needed for a project and not every bell whistle and pinwheel and typically people Bootstrap with them all installed. Last on it, when I see the row col-* mess is when I like to ask if the author if they have heard of CSS flexbox.

I straight up question your desire for how you think you want your app logic flow, specifically as to error control and service consolidation. Exactly at your statement of "heavy lifting" is taken that you still find uploading files a daunting task and that you think you need some "lifter" in the first place... How much have you worked with the FormData class of Html5? It makes things so stupid simple as essentially Http.request({post:new FormData()}). I also try to have more than just an opinion about it and its harder to have more than the minimum amount of transmitting Services as possible when it comes to maintaining request security headers, base hrefs, and error control. I tried to demonstrate why, I see it as you are stuck on the old school and with your own admittance of carrying an old school team I am concluding that you are where I was annnnnnnnnnd eventually you'll get here to less is more land......

Hey, I could totally be wrong. Trying to push the topics annnnnd fight against some of the popular tech I disagree with.

[alignsoft]

All good. I'm happy to learn new things, and if you've got a better way that you're able to demonstrate or point me at, that's great, just understand that if you're looking to build something that a lot of people are going to find useful, be sensitive to people's needs and environments. You don't have to cater to them, but dumping on them can be a bit off-putting.

When I talk about 'heavy lifting', I'm talking about anything that needs to be done to the data between the user picking a file and the server receiving it. As I mentioned earlier, we routinely downsize and compress image data before sending it to the server - we don't need 10mb image files, and we don't want the users burning cell data to submit them, so we process in the service first. We're also working with some pretty old school services on the servers receiving some of this data, so that typically presents some challenges.

Is there something specific you'd suggest reading that provides a good insight into FormData class of Html5 that might get me where I need to be more quickly?

[AckerApple]

I appreciate the encouragement to conduct myself better for the benefit of others. My attitude is a constant work in progress in trying to find balance between entertaining and effective... I sure wouldn't offer all this hand typed support/opinions if I wasn't having fun with it. I also don't at all aim to be number 1 smarty pants. Again, balance.

FormData, I absolutely learned it on the file by goggling the top docs which typically come from W3C like websites. And still today I primarily only use the .append(inputName, file, filename) function.

Today, I'm actually working on changes for this package just for the two of you in this issue. Coming real soon (release early release often):

<input ngf (filesChange)="uploader.uploadFiles($event)" />
<ngfUploader [(ref)]="uploader" [options]="..." (success)="" (catch)="" />

[alignsoft]

Excellent! I have my homework then, and I'll look forward to seeing your changes!

[AckerApple]

@alignsoft and @figuerres

I have release version 0.2.0 and I think it should be near exactly what you'd like to have. It for the most part, does not break anything and allows a smooth transition before I get rid of [uploader] all together as an attribute of any directives

The docs and the example have been updated BUT they certainly need to be updated further. For instance, [uploader] declarations still exist but the weight of initializing the Uploader class has been moved to the <ngfUploader> directive. EVERYONE should move to use <ngfUploader> so your code doesn't break when I remove [uploader] from ALL directives.

TO ELABORATE: I've created a way for ya'll to get off the [uploader] attribute and into a more clean way of having an uploader defined in template via the <ngfUploader> directive.

Let me know your thoughts. Test it out. Do hope you like as I wont be using any of this code, tis for you.

[alignsoft]

Excellent! Thanks very much! I'll update and test out the new version.

[figuerres]

Hey @AckerApple just to let you know i will be checking out the updates and stuff but i have a bunch of stuff on my work list so it may take a few days or a week before i get back to this.

[AckerApple]

Closing this issue. We have moved far beyond this issue and as I pointed out and @figuerres has now too found out as well: Http transmission is not a duty meant for this package. This package is about selecting files and providing examples of how to upload those selected files.

FINAL SHORT ANSWER TO REPORTED ISSUE: It is not the responsibility of this package to upload files nor indicate when files have been uploaded.