Brett Uglow Thanks for the article, it’s helping me get closer to a more maintainable testing pattern for my nearly 2 year old Angular project.
I’ve recently migrated the project to webpack and es6 and went from a single
angular.module to multiple modules. Although, I haven’t achieved the nirvana state where we have every component in its own
angular.module. This is where I’m struggling…
Can you describe how you’d organize the following example component into its own module?
PersonComponent that depends on a
PersonService but also depends on other common services/filters (these can be used elsewhere in the application) like a
nameFilter and an
Today I would create an
PersonModule and add the
PersonComponent and the
PersonService to it, and then add the other common services/filters/etc as module dependencies. Or… Would you simply have separate
angular.module's for each service/filter/etc, no matter its direct or indirect relation to the
PersonModule? And then inject those as dependencies of the
PersonModule? I guess I’m having a hard time drawing the line where I stop adding things to an
angular.module so that I can make my components both re-usable and easily tested.