Avoiding Angular's Digest Cycles Limit Reached

Hi guys,
I've recently encountered an issue where in a certain view on an Angular application I've reached the digest cycle limit. If you got here, 80% that you've reached the same issue yourselves.
I would like to elaborate here on how I've managed to avoid it, and fix the issue. It might not work for all the variation of this problem, but it is worth trying before you go into more serious measures.

Avoid calling processing-function from the view
I’m talking about manipulating data from the view in order for it to suite the view needs, e.g. ng-repeat=”value in yourFunction(scopeMemeber)”
If you need to manipulate the data for your view, do it on the logic tier, which is the controller.
Try to use only $scope member directly on the view.

When preparing data on the controller, avoid referencing $scope members up until the very end
If you’re getting a value from some service and on the controller you’re start to “work” on it, try to avoid referencing $scope members in it, since any change to them is a potential dirty-check loop.
What you want to do is try and save the assignment to the $scope member to the very end. Manipulate you’re data using plain JS, and only in the end make the assignment to the $scope member.
Note that sometimes it would even be more efficient to copy an Object, just to make sure it is not linked to the $scope anymore…

Put Sorting, Filtering, etc. outside of the view if possible
Although Angular offers nice ways to sort, order, filtering, etc. as a part of their API on the view level, I would be much better to do that on the logic tier (controller) when the view is complex and have a lot of these.
It is sometimes more efficient to order and array and assign it to the $scope member again, than to do it on the view.

If you have more suggestion, I would be happy to hear about it :)

Cheers

Flashmatticomponents now on GitHub

Hi guys,

It took 1 email from a developer who contacted me about my old Flex/Air open source project called Flashmatticomponent, which made me finally take the time and migrate this project from Google Code to GitHub.
I don't know how many of you are still interested in the murdered-by-Adobe-and-Apple technology called Flex, but if you do, I bet you can make use of it.
I, myself, am really proud of this project ;)

You can find it here:

https://github.com/mbarzeev/flashmatticomponents

I've also copy-pasted the Wiki pages, but it didn't turned out so well, and to be honest, I can't be bothered with fixing it right now, so sorry about that.

Enjoy. 

Quake III Arena - Statistics including Flags

Hi guys,

It is a tradition for us, to drop everything and play Quake III Arena, CTF mode, on every Thursday. Now, we did have some statistics showing each players kills etc. but we never had something to show statistics for Flags. How many did one fetched, how many did he score? did he restored any? you know... what really counts when you're playing CTF.
I looked for something on the web but couldn't find anything (if you know of any solution I'll be happy to know), so I've opened the log file and went through it to see if there is anything that might help me.
Apparently the log does mention the Flags but in such manner that it is really hard to understand in what status is the flag. You can't find anything resembling "Score" or "Fetch" but rather entries where the flag has been "touched" by a player.
To make a long story sort, I came up with a simple algorithm to resolve the Flags status, and having achieved that, the rode for creating an Angular/Node/Express (using Yeoman) application was easy.
I've uploaded that application source to Github and you can find it here:

quake-stats, an open source project

Feel free to download and use, and of course, if you feel that something is missing, or you have anything to add/fix, be sure to pull-request. The code was done pretty quickly, and therefore, somewhat dirty. I know and apologize, but hey - it's an open source project, so if you see something smelly - go ahead and fix it :)

Enjoy and Frag you later ;)

Metronome Directive using the Audio API

Hi,
A few months ago a came to notice this article by Chris Wilson.
Being into Angular I thought it would be nice to create a Directive for a reusable Metronome. I'm guessing it can be useful if you're building some musical application utilizing the Audio API.
So I've publish this GIST where you can find the code for embedding this Directive in you application. You'll have to forgive me for there is still room for improvement there, but I'm sure that if you come this far it will be a walk in the park for you to modify it to you needs.

Metronome Directive Gist

BTW, if any of you knows how to make the Gist bear a name which is not derived from the files name in it, I'll be happy to know.

Cheers

AngularJS Module Seperation needs help

If you're using AngularJS as your framework of choice you probably know that it is recommended that you separate your modules according to Logic (Directives, Filters, Services) of by view type (i.e. dashboard-module) or combine the 2, but the idea is to have a single main module which depends on these "sub" modules.
This is better for testing since you don't need to load them all if you only going to test one of them, and better for keeping you stuff organized.
Currently, if you wish to create a module that, for instance, holds all the Directives, what you need to do is to have a JS file which defines the module and on top of it, it will create all the Directives with the .directive() factory method, and this is where I find the design a bit lacking, since it's really smells bad to have a big (big) file with all you're directives defined in it. no... I want each Directive to live in it's own file.
So this is where it gets uglier. If I want each Directive to be in it's own file, this means I need to load each of these files on my index.html. Now, some of you might say "Hey! use RequireJS to load them up, dummy!" but I know that RequireJS creates a whole new set of issues with the E2E tests... I really don't want RequireJS.
The direction I went with was to go with other script loaders like $script or yepnope and have them define the scripts to load on each module file - on the Directive module I will define all the directive that needs to be loaded. Doesn't work.
In the meantime, if any of you wants to share his/hers idea - I'll appreciate it :)

Cheers.

Twitter - Here I come

So whud'ya know... I'm going Twitter.
I know, I know - I have written these lines (for those of you who don't understand Hebrew, I'm bashing Twitter like hell), but I found myself more and more coming up with short ideas that posting a blog entry for is a bit of an overhead, you know what I mean? I need something I can tap to easily and write a quick thought or revelation that comes to my mind. 140 chars should do the trick, no? :)

So I set myself with a Twitter account and it's here:
https://twitter.com/Flashmattic.

For now, only confirmed followers have access to it... suites me at this point. Not everyone should go there ;)

I hope you'll find the twits interesting and given I'm an easily distracted person, you can expect a lot of them :)

See you (also) there,

Cheers

What is a data grid?

I lately found myself explaining to different people what is a data grid, or to be more accurate, what is not a data grid.
There seems to be a common misunderstanding of what a data grid should do and what are it's responsibilities among developers and UX experts equally.
Below I will list what a data grid should not include with hopes it helps you in future debates over one of the most common component in RIA. Of course it really depends on UX requirements in the end, but given your UX is not trying to invent the wheel all over again, the following lines are true to you as well.

A data grid is not responsible for fetching it's data

The data grid should not know where it gets the data from nor the API which is behind the collection it receives. If you want a fully business-detached component there shouldn't be any call to the server from the data grids. This includes refreshing the data of course.

The actions available on the data grid are not a part of the data grid

Add, delete, refresh, export to excel etc. are all actions a user can do on the data of the data grid. The data, not the data grid.
Let's take "add" for example - you create a model, insert it into a collection (sync the server if required) and give the updated collection to the data grid to display it.
I can smell the next question popping - No! a toolbar is not a part of a data grid.

Paging is only triggered by the data grid, not done by it

Some data grids embed paging mechanism, but as mentioned before, grids do not fetch their data, and given that paging is actually fetching the data with params, the grid should not handle the paging but just dispatch an event with the page number, start index and range included. "Someone" else should take this data and fetch the page.

Filtering is not the grid's business

Again, grids do not fetch their data. Filtering is actually fetching a data with constraints to it. Do it elsewhere and bring the results to the grid.

Sorting, in most cases, is done on the server...

I know that most grids support sorting within results, meaning that they sort the results which were already fetched, but in most cases you would like to go to the server and ask for a new sorted data, since the results exceed the page row limit (or lazy load limit). In these cases, the data grid simply tells that one of it's header were clicked, and let's other do the fetching for it.

Bottom line...

The data grid is mainly for displaying data, not messing around with it. pretty simple concept that keeps slipping under UX big mocks. If you keep your grid at doing what it should and nothing more, you will create a more reusable and portable component.

Take care.

Flashmattic or JSMattic?

I guess that this post is out for all who have approached me and asked if it wasn't time for me to change my blog name into something more suitable to what I'm actually practicing for the past year or so - JavaScript. Well, it's not really JavaScript, since I played around with all kinds of technologies like GWT, Grails and some libraries on top of JS like ExtJS, but yeah, they had it right - I haven't been practicing (nor preaching) Flex or Flash.

There is no question here. Flashmattic.

Flash, my friends, is a state of mind and I'm sure that all my Flash/Flex mates will agree. The Flash/Flex communities were the most exciting forums I had the privileged to be a part of. Developers who took a relatively simple technology and made amazing stuff with it, including the creation of RIA.

Being a Flash-Developer meant that you had to think outside the box, always looking for ways to amaze people using your products. It is no wonder that the top Flash developers of the time are now among the top JS developers of today, people like Grant Skinner and Jesse Warden bring their creative minds into the not-so-recent-dry-as-F&^k JavaScript realms (Hey, the JS community is so hyped about discovering the MV* patterns in a way that makes any Flex developer ROFL).

So, my friends - This blog's name remains Flashmattic though you will see more and more content which has nothing to do with Flash.

Plus, it simply sounds better :)

Cheers.