Best way to architect JavaScript UI code with ASP.NET in terms of reuse and logic encapulation?

Question

I am having trouble settling down to a proper practice for UI JavaScript coding. So I am looking for a smarter way to do things. I’ve been using jQuery with ASP.NET and I have been doing things like below which seems unprofessional and dumb. JavaScript UI programming has always been a mysterious to me. I know how to do it but I never knew how to do it properly.

$(function(){
    $('submit').click(function() {
        //behaviors, setup styles, validations, blah...
    });
});

Problems:

• Code duplications are often therefore harder to maintain and reuse
• With ClientIds are generated by ASP.NET, it’s hard to pull code chunks into separate js files
• Common declarations are placed on master pages, however jQuery document ready function appears almost on every other pages as well

Goals:

• JavaScript library/framework independent, so that it will be easier to switch frameworks down the road
• Encapsulate/modulate logic for easy reuse, so that on each page, it will only be a few simple lines of initialization code
• Separation of concerns for easy maintenance and readability

Questions:

Being a C# developer mainly my thinking is very OO and jQuery is very procedural. I understand the concepts of Anonymous Function however in general my mind is still trying to make a domain model which abstracts the UI then declares properties or methods. But I am really not sure if this is the way in JavaScript. Or am I being too ideal or am I trying too hard to make something that's not supposed to be OO OO like? So the questions are:

• Should I start to encapsulate/modulate functions using JavaScript prototype and make it a bit more OO like? So that HTML controls or behaviours can be encapsulated for reuse?
• Or should I start encapsulate logics into jQuery plug-in? But this way the code will be 100% dependent on jQuery.
• Or any other approaches?

Thank you.

Updated: I just found this slide and it seems to be a good starting point. This is also a good example that I just found. And a good tutorial by the creator of jQuery.

Answer 1

The best technique I have found for code reuse, dealing with client ids and so on is to intoduce a more object oriented approach into my Javascript.

This has the following benefits

1. Easier to introduce scoping and multiple instances of the same thing on the same page
2. Easier to manage client id farce

I still use Jquery within this.

So to give an example if I had a javascript based widgit I wanted to make use of I would create an "object" called widget and save it in a Widget.js file. The widget object would have instance variables, a constructor and public, private methods just like in any other OO langauge e.g Widget.js would look like

// constructor
function Widget(aFooId,bBarId)  
{
 // instance variables  
 var fooId = aFooId;  
 var barId = bBarId;  

 // some magic to expose public methods  
 this.Init = Init;  

 // public methods  
 function Init()  
 {  
   alert("called init");  
 } 

 //private methods  
 function PrivateMethod()  
 {  

 }  

}  

The call on the aspx page would look like

var widgetInstance = new Widget("<%=Foo.ClientId%>",<%=Bar.ClientId%>);
widgetInstance.Init();

Answer 2

The ClientId issue is a known one and tough to get around. ASP.NET 4.0 is introducing a ClientIDMode that will let you have some finer-grain control over the final id rendered. ASP.NET MVC would definitely make your client scripting life a lot easier. If this is causing you a lot of grief and waiting for ASP.NET 4.0 or going with ASP.NET MVC are viable options, I would explore those alternatives.