Volunteer shift signups are working again

I've made some changes to how we do Angular now that I have an extra year of Angular experience and have a better idea of how to write idiomatic and testable Angular code.  (Still no Angular unit tests for the signups code, but at least we could easily write some now, whereas before it was out of the question.)

I'll leave a bunch of inline comments explaining what I did.
What's the proper ticket to discuss these config option issues in?

> On Oct 5, 2014, at 3:48 PM, Eli Courtwright <notifications@github.com> wrote:
> 
> In uber/decorators.py:
> 
> > @@ -175,15 +169,6 @@ def screw_you_nick(rendered, template):
> >      else:
> >          return rendered
> >  
> Ok, so here's the deal. We have a LOT of constants in our code, e.g. ATTENDEE_BADGE and HIDE_SCHEDULE and BEFORE_PRINTED_BADGE_DEADLINE, etc. When we write an Angular app, we need to be able to access those values.
> 
> Last year I did this the lazy way (which is definitely NOT idiomatic Angular) which was to basically take all of our Angular templates and first render them with any of these constants that we might encounter on the server, so that by the time they got to Angular they already had all of the correct values.
> 
> The main problem with this is that it means you can't really write Angular unit tests. Since I didn't write any of those last year anyway, this didn't matter much. Still, even without writing unit tests, I think there's a lot of value in using a framework like Angular in an idiomatic way. When our code looks like other people's Angular code, it makes it a lot easier for a newcomer to jump in, and it makes it way easier to ask questions on Stack Overflow, etc.
> 
> So this year we're "doing it right". We have a magfest Angular module with a magconsts constant defined, which is a dictionary with all of the settings we care about for our Angular code. Although this module is rendered dynamically on the server, we could mock it in the standard Angular way when writing unit tests for our other modules that we'd want to write tests for. This seems to be how Angular is supposed to handle this kind of server-driven configuration.
> 
> —
> Reply to this email directly or view it on GitHub.