Suggestions for qz-tray.js 2.0

[andreialecu]

I see some good progress in making qz-tray.js modern with promises and everything, however I have several suggestions:

• [x] Drop jQuery requirement

  Please drop the jquery requirement, it seems to only be used for extends and parseJSON. I do not need jquery (I'm using angular) in my project, and would like to not take it as a dependency.

  Here's a simple extends implementation:

  function extend(a, b){
  for(var key in b)
    if(b.hasOwnProperty(key))
        a[key] = b[key];
  return a;
  }

  For parseJSON, you may just use JSON.parse which is in every supported browser as per the FAQ

  Edit: Done via 037d1d8

• [x] Allow custom promise libraries

  Please allow optionally changing the promise library to a custom one. For example I'm using angular's $q, but also bluebird in a separate project. I'd like to not have to deal with RSVP as well.

  A simple way to achieve this would be to be able to provide a function that creates the promise to the library, and let the developer override it if necessary. For example:

  qz.promise = Q.promise; //q
  qz.promise = function(resolver) {
  return new Promise(resolver); // bluebird
  };
  qz.promise = function(resolver) {
  return new RSVP.Promise(resolver); // RSVP, default?
  };

  You can then use qz.promise(...) instead of new RSVP.Promise to instantiate promises, and developers can override the promise lib on a case by case basis.

  Edit: Done via 4a26d85

• [x] Add "module.exports" support

  I'm using webpack (others may be using browserify) in my app, and would like to be able to require this library and get a reference to the qz object without going through window. Please use module.exports if available: http://www.matteoagosti.com/blog/2013/02/24/writing-javascript-modules-for-both-browser-and-node/

  Edit: Done via de5af23

• [x] Add IIFE syntax

  The entire javascript code should be wrapped in an Immediately Invoked Function Expression. No reason not to really.

  Edit: Done via cd88efc

Good work otherwise, looking forward to 2.0.

---

Edited Dec 28 @tresf, add checklist style bulleting

[tresf]

@andreialecu Top notch. We'll take a swing at this right away, thanks for the recommendations.

-Tres

[andreialecu]

@tresf Awesome! :)

Also, another suggestion would be to publish the javascript file to bower and npm once released. Would help a lot with package management, and make installation much easier.

[tresf]

publish the javascript file

@andreialecu added new issue #127. We pair our JS with our Desktop App, so any feedback on that thread in regards to auto-versioning (to npm or bower) via GitHub would be a big help. We're a very small shop, so anything that eliminates manual work is very valuable. If you're interested in helping set this up, please contact me privately.

@tresf Awesome! :)

:smile: I also edited your original post so that it is in checklist format, so that we can tick them off as we close them.

[akberenz]

We can remove JQuery, but I do want to state that the simple extends implementation provided will not work with our code, as we are using the deep-copy functionality provided by JQuery for sub-object properties (the reason why our own wasn't written).

[andreialecu]

@tresf For automating releases, one idea is to create a gulp file: https://github.com/gulpjs/gulp/blob/master/docs/recipes/automate-release-workflow.md

Also look at: https://github.com/stevemao/conventional-github-releaser

The gulp file can also have a task to publish to bower/npm, but I think the proper way to handle this is to separate the client javascript file into its own separate repository, and only publish that one as needed. It may not always be necessary to publish a new js version along with binaries, and sometimes a js update may be necessary without a binary one.

@bberenz I just noticed that you're using deep extend. Maybe http://andrewdupont.net/2009/08/28/deep-extending-objects-in-javascript/ might work?

[tresf]

@tresf For automating releases [...]

Bumped to other thread. Thanks.

[tresf]

@andreialecu FYI, 3 of 4 tasks have been completed. I've edited the original post to reflect each commit respectively. As always, feedback welcome. Once we get the module.exports feature finished, we'll close this out.

[andreialecu]

@tresf looks good, regarding module.exports, you can change the IIFE to something like this instead and it should work immediately:

(function (root, factory) {
  if (typeof define === 'function' && define.amd) {
    define(factory);  // this is for AMD
  } else if (typeof exports === 'object') {
    module.exports = factory; // this is for webpack and browserify
  } else {
    root.qz = factory(); // the `this` passed here is `window` when used as a script tag in the browser
  }
})(this, function () {
  var _qz = ....;
  return _qz;
});

[akberenz]

module.exports should be available via de5af2306f60b2fc2c3c7c5696a6586414f9a525 @andreialecu can you verify everything works as expected before we close the ticket?

[tresf]

I've documented Q and Bluebird overrides here: https://github.com/qzind/qz-print/wiki/2.0-Override-RSVP

Please notify me of any corrections.

[tresf]

Closing via 037d1d8, 4a26d85, de5af23, cd88efc. Please open a new issue if you encounter any problems with the above implementations.