jvandemo / generator-angularjs-library

A generator for Yeoman to generate the boilerplate for creating an AngularJS library
117 stars 33 forks source link

how to reference other javascript libraries #32

Closed erikyuzwa closed 8 years ago

erikyuzwa commented 8 years ago

I'm using the generator to put together a small component library of Directives. It's great so far, but I'd like to now include other libraries like lodash.

Since this project has no real index.html, where would I put the lodash reference. I'm guessing somewhere in the module.js file where the Angular references are put together?

denisos commented 8 years ago

Hi, did you get an answer to this question? I'd like to do same and have been researching. I did notice that there is a ng-lodash wrapper for lodash which you could use: https://github.com/rockabox/ng-lodash From what I see, it copies lodash and wraps it for angular. This means it has to keep in synch with lodash over time. A downside but maybe thats fine for your needs. So definitely an option. I will note Brian Ford from angular team wrote a good post on building angular bower libraries and at the end of the post advises against this wrapper approach: "The "right" way to use d3 right now is to include it as a dependency of some directive that accesses the library directly off of window.d3" http://briantford.com/blog/angular-bower

I checked angular-ui and how they include dependent libraries including angular, jquery, jquery-ui. From what I see they:

  1. don't list such files as dependencies (e.g. in a module.js) but make it clear in the comments on the github readme that you need to include such dependency files in your index.html when using
  2. include their dependencies in karma.conf.js so unit tests work correctly
  3. ensure the bower.json lists dependencies so they are installed

Thats the route I plan to follow in such cases i.e.

erikyuzwa commented 8 years ago

No I never did @DenisOS - but at the same time, it's given me time to think about it more and realize that perhaps this is why most libraries leave out those decisions in favour of letting the end-developer integrate any component library with their existing codebase which has already likely decided upon issues like underscore vs. lodash vs. library_x.

Like you, I ended up following the same strategy in order to at least be able to unit test.

jvandemo commented 8 years ago

The guidelines by @DenisOS look really solid.

What I usually do as well is wrap the native dependency in a service and throw an error if the dependency is not available. Suppose that you require the D3 library:

(function () {
  function D3Factory($window) {
    if(!$window.d3){
      throw new Error('D3 is required!');
    }
    return $window.d3;
  }
  D3Factory.$inject = ['$window'];
  angular
    .module('app')
    .factory('d3', D3Factory);
})();

the you can inject d3 anywhere in your application without having to use window.d3 or $window.d3.

This is really convenient. If the developer forgets to include the dependencies, the application wil throw an error and the console will show the reason why.

jvandemo commented 8 years ago

@erikyuzwa, @DenisOS: did my example code answer your question(s)?

Thanks!

erikyuzwa commented 8 years ago

Yup, I like it! great suggestion indeed. I'll close it, but if @DenisOS needs more help, please don't hesitate to re-open. #high5

jvandemo commented 8 years ago

@erikyuzwa — :+1:

denisos commented 8 years ago

@jvandemo looks good to me too; thats a nice technique and throwing the exception will help developers know what to fix.

jvandemo commented 8 years ago

@DenisOS — Perfect, thanks for the confirmation!