

A post-mortem on my first AngularJS project - JohnMunsch
http://johnmunsch.com/2013/09/22/a-post-mortem-on-my-first-angularjs-project/
If you&#x27;re tired of To-Do lists and Twitter feed examples for AngularJS I can offer a variation. This is a project I did for a t-shirt site and it does quotes using a variety of variables in real time as the user interacts with the UI. I also show how I went back to the existing project to learn how to add unit testing with Karma and Jasmine and a unit testing coverage report with Istanbul. Spoiler: It was pretty easy.
======
jarnix
Post mortem means that your project is dead...

~~~
crusso
Only if you didn't understand conventional use of the term. Since no one
really speaks Latin anymore, the conventional use of the term is all that
matters.

If a speaker uses a term and the audience understands it, whipping out your
Latin dictionary is pointlessly pedantic.

~~~
GrinningFool
I think your anti-pedanticism is excessively pedantic.

Conventional use of the term _does_ indicate an analysis of events after
something has come to an end - if not necessarily death. A company, a project,
an incident response.

I'm with GP on this one. Based on the title, I thought that the project had in
some way come to completion and this was an after-the-fact analysis of cause,
effect, and resulting behaviors.

As you said, the conventional use is what matters - and the author here has
used the term in a non-conventional sense.

Edit: another read through after seeing the author's comment below. The
project did, in fact, come to an end - though that wasn't really clear. Given
the content I think the "retrospective" is a better fit. The author used this
in the content of the entry itself.

------
mdkess
Nice writeup, I especially appreciate the focus on testing. End product looks
really slick. You might want to add a screenshot and a link to the blog post
in the GitHub repo that you posted.

One thing that I think could be improved is the layout of your code. Right now
you have a single controller that handles everything. For example, selecting a
shirt color should be a directive, and so should the quantity picker. Then use
the $scope.$emit and $scope.$on to hook events together. This way, if I make a
better color picker (although yours is pretty stylish), I can swap out yours
for mine so long as I emit the same events as yours.

This would also make it easier to add new directives - for example, maybe I
could choose a decal on the front and back of shirts, or jersey numbers or
something. So I think that the controllers in this case should be pretty
minimal, and just provide a scope to tie the various directives together.

Anyway, just a thought. Thanks for sharing this and the included GitHub repo.

~~~
JohnMunsch
You bring up two really good points there. I will add a screenshot to the
Github repo and there is an opportunity to use a directive for the color
picker.

I'm not sure about the quantity picker though, what's that going to look like
in the HTML? One element in the code gives you all of the quantity fields?

My use of directives to date has been rather limited so I look forward to
exploring that more in some upcoming work.

~~~
mdkess
I'm certainly no Angular expert, so take my advice with a healthy amount of
skepticism, but I think that it would be one element. The idea being that if I
want to swap that stuff out for a new and improved quantity picker, I just
change the directive. The idea of angular is that the HTML is supposed to make
it clear what's going on, so a single element isn't a bad thing - it says,
"here's the part that chooses quantities." Remember that you can nest
directives too - so the meat of your page could look like:

    
    
      <div ng-controller="QuoteCtrl">
        <shirt-chooser></shirt-chooser>
        <color-picker></color-picker>
        <size-picker>
           <size-picker-choice label="SM"></size-picker-choice>
           <size-picker-choice label="MD"></size-picker-choice>
           <size-picker-choice label="LG"></size-picker-choice>
           <size-picker-choice label="XL"></size-picker-choice>
        </size-picker>
        <number-picker></number-picker>
        <order-summary></order-summary>
      </div>
    

And then your directive figures out what that means in terms of rendering. But
now, the nice thing is that I can just substitute that with <my-size-picker>
and, assuming I fulfill the contract, everything should continue to work.

Now you get the added benefit that you can test directives individually, as
well as the whole controller. Right now, if you do some restructuring of the
page, you could end up in a situation where you break all of your test cases.
I mean, in this case it might be overkill, but as a general principle I think
it's the right approach.

Anyway, looking forward to see what you do next!

------
welder
I was hoping this would cover:

1\. Angular.js vs Backbone.js from experience of their differences

2\. Angular.js with Require.js (I already know about Backbone.js AMD
architecture)

Has anyone done a large project in both Backbone.js and Angular.js?

~~~
JohnMunsch
I have done a large Backbone.js project for my last employer. I was on that
for about 18 months. I have not done a project with both Backbone.js and
AngularJS in the same project. I know some people do that but I truly cannot
think of anything Backbone.js brings to that party.

As for Backbone.js by itself... It's OK, I liked it but we had a large project
with as many has half a dozen people working on it at its peak and the problem
we got into was all of the huge gaps in Backbone.js that you typically fill
with other software (two-way binding, validation, templating, AMD, etc.) and
if you don't figure out your solutions for all of those gaps before you start
every developer in the group ends up filling it his or her own way. Especially
if you're under a time crunch and writing really fast.

We ended up with a working project at the end and it was way faster than their
old solution but it was a chimera. Every part of it appeared to be a different
animal. With AngularJS a lot more of those parts are part of the framework
itself and there's less room for that kind of problem. I'm using it for large
project work now and liking it a great deal more.

~~~
chernevik
This is a really helpful answer for n00bs like myself. Often the differences
between technologies emerge not at 'hello world' or 'to do', but in larger
projects or working with teams. It's very hard for someone like myself to see
those differences for ourselves, at least not until we've been through it a
couple of times. Thanks.

------
obilgic
Where did you get those sticker on your laptop?

~~~
JohnMunsch
[http://www.redbubble.com](http://www.redbubble.com)

I still want Chrome, Firefox, and MongoDB stickers too. Feel free to send me
some :)

