views:

73

answers:

2

Hello! This is a general kind of question.

Very often, I need to write JavaScript for web pages. Keeping in mind best practices, unobtrusive js, etc. I have my JavaScript in separate *.js files. Every page gets its own js file. What's been somewhat bothering me lately, is the mix of presentational code with functional code that I always end up with. So, for example, I would assign a .click handler to an element. On that click the element must change its appearance and an AJAX call must be made to the server. So, right now, I'd do both of these things inside that .click handler. It might get bulky depending on what needs to be accomplished. When I come back to these blocks of code after not touching them for a week, I often feel like it takes away too much time to trace through all lines of code when I only need to fix something with appearance...

Anyways, any ideas on architecture/design for presentational js vs. functional js? Keep them in one file, but brake into separate functions? Brake them into 2 separate files? Leave them alone?

Thanks!

A: 

I would tend to keep them all together that are related regarding the event that kicked them off, but sometimes put a function in to call to do a specific group of things. Example:

function domyUIstuff(myevent, myselector)
{
// stuff here
};
function domyBehaviorStuff(myevent, myselector)
{
//dostuffhere
};
$(selector).click(function(e)
{
   domyUIstuff(e,$(this));
   domyBehaviorStuff(e,$(this));
};

Side note: I do keep stuff separate (I do a lot of asp.net stuff) from different user controls - I create a myusercontrol.js file for my myusercontrol.ascx as well as a mypage.js file for my mypage.aspx which tends to cut down on the "noise" when I debug - I put my "generic" functions in the page file that I might call from my controls such as generic ajax message handlers or generic "utility" functions.

Mark Schultheiss
I was also thinking about more "harsh" separation within the same js file. Something like PageName.UIFunctions().doStuff() and PageName.BehaviorFunctions().doStuff(). But then, the structure of the file gets too messy with all the commas, curly braces, parenthesis, etc. Plus, js isn't really object oriented.
Dimskiy
I somewhat came up with an architecture that I seem to like at the moment. I think this answer best matches what I'm doing at the moment.
Dimskiy
+1  A: 

I find it useful to have three JS files in each dynamically generated page. The general functions that are re-used everywhere, the project specific functions that are used all over the project and the page specific js file. This way you have a handle on what is "reusable" and what isn't. This also encourages you to "promote" your code. As you "promote" it, you will find yourself separating it more and more into UI or Behavior. As more stuff gets separated you may find yourself including 6 files or just breaking each file up with a package structure as you suggested earlier UIFunctions().doStuff()... However if you have to prefix your stuff with PageName you haven't promoted your code and maybe it is time you do so :-)

That is just how I have been doing it. Hope it helps.

David T
Thank you for your answer. Could you explain this a little more? In particular, what do you mean by "promote"? I usually have some sort of Common.js file, that has all the functions that could be used from any page of the website and a separate PageName.js file, that is only being used by that particular page. If I write a function that I can see could end up in Common, I just move it to Common.
Dimskiy
You are "promoting" your page specific code to the common js file already. I think of the page specific stuff as the lowest level (in terms of re-use) code, I think of the project specific code as the next level up (therefore page code can be promoted to app code), I think of commonly re-usable code that I can use across many projects as the goal towards which I strive. Therefore the "highest level of achievement" and therefore that this where App specific code gets promoted to. The next level up might be some sort of release to the public but that is just like common code to me.
David T