JavaScript URLs – Handling URLs in the Browser

asp.net-mvcjavascripturl

We are trying to continually improve our source code base and a question came up recently which throws open a new area to improvement. Where best to put URLs that are needed in JavaScript?

  1. Do we put the URLs in the JavaScript files themselves?
    function onButtonClick() {
        $.ajax({url:"/my/url/directly/in/the/javascript"});
    }

Note: The magic string above is incidental. There could be an object that returns URLs or whatever. The point is that the URLs are stored in the JavaScript files.

  1. Do we have some mechanism to inject the URLs into the JavaScript. e.g. Having a small script on the page that sets up the URLs from which the JavaScript in the files can access.
    <script>
        var ps = new pageScript();
        ps.initUrls({someUrl:<%= Url.Action("SomeAction", "SomeController").ToJson() %>);
        ps.run();
    </script>

The .ToJson() method is an extension method that turns an object into its JSON serialised version, so, for a string it outputs the quotation marks and escapes it if need be.

Then in the JavaScript file it can pick up the URLs from where ever the initUrls() function stored them.

    function onButtonClick() {
        $.ajax(myUrls.someUrl);
    }
  1. Or something else?

We already use 1 and 2 in our code base from various developers over the years, but is there a better way? Or is either of the above a good overall solution?

Best Answer

I am a fan of using data attributes:

HTML:

<div class="ajax-widget" data-endpoint="/api/some-endpoint">
    ...
</div>

JS:

// Or whatever your initialisation logic is.
$('.ajax-widget').each(function() {

    // Grab the endpoint and use it for something.
    // e.g. AJAX call, assigning to a property for later etc.
    var endpoint = $(this).data('endpoint');
    ...
});

The benefits to this are many.

  • They are easily parsed with jQuery.
  • It offers good separation of concerns (allowing you to keep your JS out of your views and in JS files).
  • You can create flexible, modular widgets/plugins using the same JavaScript that can be pointed to various endpoints without modifying JavaScript.
  • Avoids having to have funky environment checks in your JS - configure environment-specific URLs server-side and let the client just do its thing with whatever you give it.
  • You can make use of MVC helpers without littering your JavaScript (and, again, pulling it into your views).
  • You can easily build HTML prototypes which point to endpoints returning pre-specified results (such as static JSON files) allowing you to develop and test client-side code independently without having to change JS code in production.
  • Probably many more that I can't think of right now.

This is the standard convention we use and I honestly think it's spot on. The benefits I've listed above are in the context of AJAX calls but they apply for just about any scenario you can name in which you'd need to do something like this (client-side redirects, dynamic hyperlink creation and so on).

Related Topic