A project should have a bundler, regardless of the technology stack. A bundler is software that bundles your application code along with its resources into a minimized, zipped bundle that can be easily deployed on the server (at its most basic form).
There are many bundlers out there, most widely used are Grunt, Gulp and lately, Webpack. They each take a different approach to fulfill the task at hand – but Webpack really stands out from the crowd.
Say you want to test your Angular application.
To do that you’ll be implementing Unit tests (with the Jasmine + Karma + PhantomJS stack) or E2E tests (with the Jasmine + Protractor stack).
You could choose any other stack using Cucumber, mocha, chai or any other testing framework – the principle of today’s topic remains the same.
The scenario is this:
There’s this piece of setup code that needs to be executed before each spec in every suite (performing login, for example).
I chose before each spec for the sake of the argument, but the same concept could be applied to before all specs in the suite and/or after each and after all specs in the suite.
for the sake of the post: describe = suite and it = spec.
Recently, I had to add white-label support for the project.
This means, that some elements on screen had to be able to get theme-specific styling. Usually this mainly means theme-specific colors, but this can easily be extended to SVGs, graphics, Logos etc.
So, I came up with a neat CSS trick I’ll go over today.
When I was working on the TickerSrv, I wanted to support task auto-unregister. To accomplish that, in the module’s run phase, I added register & unregister functionality to the $rootScope.
Mid 2014, I published a post about a timing service. You can read the post here.
Recently, I wanted to use this service for a client but the requirements meant that I had to refactor the code to be more robust.
When I published the post about the Local Storage Cache Service, I also published the service code and test on GitHub.
This raised quite a few questions from readers in regards to the test. Specifically, why I implemented it with a main describe that contained an inner setup describe and an inner tests describe.
When working on a large scale application, eventually you’ll want to break it down to one or more product sub projects that all depend on a common project.
This post will discuss how to work with 2 projects properly while still using bower to manage dependencies
If you ever took part in any serious JS development in general and AngularJS specifically, you know that every time you create a new js file, you need to manually include a reference to it in the index.html file, other wise it won’t be included and the app will fail.
How would you feel about not having to do that?
When working on large scale projects, java back-end code is usually being built using Apache Maven.
This is usually part of a larger framework in charge of project life cycle that is part of the Continuous Integration DevOps realm, either Hudson, Jenkins or something else.
In such a case, you’d want your AngularJS code to run grunt/gulp as part of the CI procedure as well.
As part of a requirement I was implementing, I needed to create a model object.
I wanted to do this ‘The Angular Way’ – non-intrusive, extensible and injectable.
AngularJS provides us with the means to create Services, Controllers and Directives, Model Objects are somewhat of a missing piece.
I was thinking of implementing this with a service but ran a quick Google search just to make sure I was on the right track.
I stumbled on a very good article, written by Gert Hengeveld on this subject.
I liked the approach and the explanations, A really good read in my opinion.
Here is the link.
A JS Black Belt Blog 