qzind / qz-print

Archive for legacy qz-print versions (1.8, 1.9). See https://github.com/qzind/tray for modern versions.
Other
141 stars 101 forks source link

Suggestions for qz-tray.js 2.0 #126

Closed andreialecu closed 8 years ago

andreialecu commented 8 years ago

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

Good work otherwise, looking forward to 2.0.


Edited Dec 28 @tresf, add checklist style bulleting

tresf commented 8 years ago

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

-Tres

andreialecu commented 8 years ago

@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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

@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 commented 8 years ago

@tresf For automating releases [...]

Bumped to other thread. Thanks.

tresf commented 8 years ago

@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 commented 8 years ago

@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 commented 8 years ago

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

tresf commented 8 years ago

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 commented 8 years ago

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