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

Use ember-ajax as base #118

Open
jamesarosen opened this issue Jun 7, 2016 · 4 comments
Open

Use ember-ajax as base #118

jamesarosen opened this issue Jun 7, 2016 · 4 comments

Comments

@jamesarosen
Copy link

We have an application that uses Ember-Uploader and Ember-AJAX together. Because Ember-Uploader uses Ember.$.ajax directly, it doesn't take advantage of any global settings we've done in Ember-AJAX like headers and error-handling.

What do you think of swapping in Ember-AJAX for the transport? Because it's container-based, one change that would be required (or a workaround found) would be

import EmberUploader from 'ember-uploader';

export default EmberUploader.FileField.extend({
  filesDidChange: function(files) {
    const uploader = EmberUploader.Uploader.create({
      container: this.container, // <-- Uploader would need a container so it could look up service:ajax
      url: this.get('url')
    });

    if (!Ember.isEmpty(files)) {
      // this second argument is optional and can to be sent as extra data with the upload
      uploader.upload(files[0], { whatheverObject });
    }
  }
});
@digitaltoad
Copy link
Member

I'm all for keeping up with what is current in Ember.

@jamesarosen
Copy link
Author

One thing to be careful of is that any time you create an object with { container: this.container }, you need to be careful about tearing it down or you'll end up with a bad memory leak in test runs.

@kjhangiani
Copy link

@jamesarosen Can you elaborate on that? I have used that pattern previously, and I was unaware of that possibility. What is required to tear down an object like that properly?

@jamesarosen
Copy link
Author

I can! The issue is that the EmberUploader.Uploader instance has a reference to the container, which is a huge graph. Nothing destroys the EmberUploader.Uploader instance. It's possible it will get garbage collected when filesDidChange goes out-of-scope, but if anything else holds a reference to it, it definitely won't. This is more dangerous if you do something like

uploader: Ember.computed(function() {
  return EmberUploader.Uploader.create(...);
})

since then the component is definitely holding on a reference.

The solution is to call .destroy() on the EmberUploader.Uploader when you no longer need it.

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

No branches or pull requests

3 participants