Angular Lifestyle. In Brief. Comments

So I’m somewhat transient, living situation wise. Not that that’s changed for the past couple years.

I have, however, settled on a workplace I really enjoy, acting as the primary front-end developer for a highly-visible application within FINRA, used by both internal auditor types and external firm representatives.

I’ve learned and have built all the front-end bits using AngularJS (we’re locked to 1.2 for the moment for IE9 compatibility, and are trying to use as few third party libs as possible… certain complexities in the latest batch of pages have necessitated adding jQuery and Select2)

I’ve also learned bits of XHR2 (for upload progress events), have used CORS while in dev-mode, and am relying on mocked backend service bits for dev-mode to allow me to build out functionality even before the backend has been built! Also had to build a drag and drop uploader that handles multiple files in browsers that support it (which covers pretty much all browsers that support drop events in the first place) … falling back on an invisible iframe form-post for older IE.

Overcoming some of the trickier bits with Angular has mostly been a matter of learning not to make calls to functions in templates when possible, including pre-filtering data before rendering the template, limiting the number of times a repeater repeats via either pagination or infinite scrolling (we’ve got an interesting custom bit for that as we don’t have just a single repeated on our page, so none of the out-of-the-box solutions work…) Also un-learning the whole UJS “don’t use inline event listener hooks in your markup!” propaganda I’ve lived by seems to be less useful and desirable when directives like ng-click handle all the setup and teardown for you, which otherwise would be a chore in an SPA app.

Bindonce is also a very handy set of directives, though you must be careful to watch out for situations where data needs updating and re-rendering, where Bindonce doesn’t update it the way vanilla Angular two-way binding would.

Contrariwise, it’s also been quite useful on my latest controller to set up a number of watches manually, for working with UI and in-memory data aspects that have no directives or in-build functionality to handle, that I’m aware. This same controller is my first attempt at using the this instead of $scope referencing needed for a “controller as X” usage within the template. I intend to use this more going forward, especially any time I have lots of smaller controllers living on a page together. That could otherwise get rather awkward quickly.

I’ve been testing all my controllers at least, using Karma/Jasmine, locally as well as from Jenkins. Works out pretty nicely. I’m espousing a BDD approach where I only test surface area rather than internals, but occasionally I do need to check state as there’s no output to check from certain methods, etc. I’d like to say I’m always doing things test-first, but it’s usually more like “muck around a bit sketching out a half-working bit of code, then write tests and clean up the sketch till everything passes”. But it’s close enough I feel somewhat ok about it.

More to come on code organization, glitches to watch out for (oh man, I’ve seen a nasty environment-specific issue with ng-min transpilation of template expressions into inline JS strings that bugged me for hours before I located it!) and so on.

Needless to say, I am really digging Angular. Haven’t had time to compare it with Ember, and haven’t dug into Polymer or similar either. Intend to do both (and plenty more besides) in the coming months.

So that’s it for the moment, but please do post up with any questions of concerns about Angular, XHR2, Select2 with Angular, writing directives, controllers, nested views, or whatever else crops up.

And to anyone who’s actually read more than a single post on here, cheers. It’s appreciated.

Post a Comment

Your email is never published nor shared. Required fields are marked *