Is it bad practice to return partial views that contain javascript?

Question

Hi,

I am implementing a customer database which lets me search for users and companies, browse and edit their details, and many other things using ASP.NET MVC and javascript (jQuery).

Whenever a post or get occurs, I do that via jQuery.load and insert the PartialView into the DOM.

Some partial views include forms. I want those to be ajax forms as well, so those partialviews have document.ready handlers that turn the forms into ajax forms (via jquery.form).

At the beginning I was handling this in the callback / code that inserts the partial view into the DOM. However, this resulted in one big script containing lots of javascript functions that refer to different pages. I refactored the big javascript by inserting the scripts into the respective pages.

Now the code is sleeker (I have much less OnXXXPartialView handlers) and the code is neatly inside the partial view it belongs to. Most of those files only include 3-4 lines of javascript code, so the overhead is not really significant.

So effectively I am not only adding elements to the document DOM, but sometimes I am also adding a piece of javascript. In practice this works fine, but it seems Firebug can't debug the dynamically loaded scripts.

There are ofcourse workarounds the Firebug issue, but I am wondering whether my architecture may be the real culprit here. Where do you put javascript that belongs to partial views? Is there any best practice?

Answer 1

If you are going through the hassle of including javascript in your partial views, I would switch to just returning JSON in your ajax calls, that way you can handle it all on the client. Though, I will admit I always prefer this method.

As for best practice, I've always considered it bad to return generated html in an ajax call instead of json, but thats just me (NOT knocking you, its a personal choice). Obviously Microsoft doesn't think its bad practice as they've specifically built in functionality to support it. Anyway, I wouldn't consider including javascript with your html any worse than just sending html back in the first place.

I'm curious though, what's in the javascript?

Edit: To be specific, I'm in favor of making an ajax call to get json, then using client side JS to build that "partial view" and insert it into the dom. As opposed to making an ajax call to get server rendered html for the client to then insert into the dom.

Some partial views include forms. I want those to be ajax forms as well, so those partialviews have document.ready handlers that turn the forms into ajax forms (via jquery.form).

I would think that you could handle this in the callback / code that inserts the partial view into the dom.

Edit: If its orderly, efficient, well organized and works for you then I'd stick with it. The idea of having everything nice and compact into a partial view is definitely appealing so I wouldn't be too concerned with violating any best practices. My only concern was that the JS might be reusable, which would be the case if you where inserting the same script over and over. But in this case it sounds like you have a good deal of compartmentalization going on so I'd stick with it unless you can generalize your scripts and include them with the rest of your JS.

Answer 2

At the end - javscript is supposed to be in 1 file (cause every http GET costs some precious time) and minified. These links could interest you: here and here.

Your way of handling JS makes some unneeded data transfer - instead of sending JS, make it static, cache it on client side and parametrize.

Post above gives a nice hint (JSON) how to parametrize your JS :)