Please suggest a strategy for serving JavaScript containing server side code

I think this is a common scenario - I have a view where I use HtmlHelper to generate some HTML elements, I also have a helper extension that lets me get the generated element's ID, so that I can use it in JavaScript (e.g., jQuery):

$('#@Html.FieldIdFor(model => model.Name)').autocomplete({

Or when doing Ajax I'm building the URL string from the UrlHelper, again using server side code to put some client side stuff on the page:

$.get('@Url.Action("States", "Location")', { country: $(this).val() }, function (json) {

That part is easy. I know how to do this and I know I can put this code in a partial and render the partial view where 开发者_高级运维I want the code to show up. This is not what I want to ask about.

Code contained within the page markup is not cached, that's one thing. The other thing is that sometimes I need the same bit of code on several views and I would like to keep it in a single place for maintenance. Single place could be a partial view - but I want this code to be cached, ideally it would land in a .js file. However we cannot use server side code in .js files. The keywords are cacheable and single file.

I also know that I can have a JSController which would serve the JavaScript, for example:

<script src="@Url.Action("Script", "JS", { script = "location" })
        type="text/javascript"></script>

This controller action could return JavaScript as a result of a view rendering.

Or maybe I should stop being paranoid and just use normal .js files and put the element IDs and URLs there and if I ever update my view models or views, I'd go and update the .js files. I wonder whether this is an over engineering issue with .NET - I'd be interested to know how people do this in Rails or django.

So what I am really looking for are some "best practice" strategies. What do you do most often? How do you tackle with this problem?

---

Caveat: I don't do much with ASP.Net. But the problem isn't ASP.Net-specific, it's the same sort of thing for all applications that have both server- and client-side code.

I'd probably have the main JavaScript file use IDs and such it gets from a variable, and have your per-view / per-page code generate the variables for it. So for instance:

<script type='text/javascript'>
    if (!window.Stuff) {
        window.Stuff = {};
    }
    window.Stuff.MODEL_FIELD_SELECTOR = '#@Html.FieldIdFor(model => model.Name)';
</script>
<script type='text/javascript' src='commonstuff.js'></script>

In your commonstuff.js:

$(Stuff.MODEL_FIELD_SELECTOR).autocomplete({...
// (Or `window.Stuff.MODEL_FIELD_SELECTOR`, but unless you redefine `Stuff`
// locally, there's no need to prefix it.)

Note that I'm using only one global symbol, Stuff, to contain this stuff, so you don't pollute the global namespace more than necessary.

The idea here is to put the code in a cachable, central, reusable place; but and to just use dynamically-generated code to set up the IDs of the things you need to work with.

---

Update: If you'll have several (or even a lot) of these, and I expect you probably will, and you're using a symbol you know you're the one defining, you can use object literal notation to make things more compact:

<script type='text/javascript'>
    window.Stuff = {
        MODEL_FIELD_SELECTOR:  '#@Html.FieldIdFor(model => model.Name)',
        SOME_OTHER_SELECTOR:   '#@SomeOtherThing',
        SOMETHING_ELSE:        '#@SomethingElse',
        // ...
        LAST_ONE:              '#@TheLastOne'
        //                                   ^
        // Important: No trailing comma here |
    };
</script>
<script type='text/javascript' src='commonstuff.js'></script>

Note that point about the last one; IE7 and earlier choke on trailing commas at the ends of object literals (more).

---

One thing you can do is go away from server side templating/views and go to clientside templating/views. That way all your controllers will serve json only and you will bind that json as viewData to templates directly in the browser. The templates can be cached, since you serve them as a json object (for instance). This is not a trivial implementation, but once you have it up and running it both scales and performance like nothing you have seen before.