URL in javascript nel browser

Sono un fan dell'uso degli attributi dei dati:

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');
    ...
});

I vantaggi per questo sono molti.

• Sono facilmente analizzabili con jQuery.
• Offre una buona separazione delle preoccupazioni (che consente di mantenere il tuo JS fuori dalle tue visualizzazioni e nei file JS).
• Puoi creare widget / plugin flessibili e modulari utilizzando lo stesso JavaScript che può essere indirizzato a vari endpoint senza modificare JavaScript.
• Evita di dover controllare l'ambiente in modo funky nel tuo JS - configura URL specifici per l'ambiente lato server e lascia che il client faccia il suo lavoro con qualsiasi cosa tu gli dai.
• Puoi utilizzare gli helper MVC senza sporcare il tuo JavaScript (e, di nuovo, inserendolo nelle tue visualizzazioni).
• È possibile creare facilmente prototipi HTML che puntano a endpoint che restituiscono risultati pre-specificati (come file JSON statici) che consentono di sviluppare e testare il codice lato client in modo indipendente senza dover modificare il codice JS in produzione.
• Probabilmente molti altri a cui non riesco a pensare in questo momento.

Questa è la convenzione standard che usiamo e onestamente penso che sia azzeccata. I vantaggi che ho elencato sopra sono nel contesto delle chiamate AJAX, ma si applicano praticamente a qualsiasi scenario che puoi nominare in cui avresti bisogno di fare qualcosa del genere (reindirizzamenti sul lato client, creazione di collegamenti ipertestuali dinamici e così via).

Quello che vuoi fare è iniziare con un oggetto config:

myApp.config = {
  myUrls: {
    someUrl: "http://default.com";
  },
  someSharedPropAcrossAllEnvs: 'something'
};

Quindi creare versioni specifiche per l'ambiente che sostituiscano i valori appropriati:

var envs = {};

var envs.dev = {
  myUrls: {
    someUrl: "http://localhost:8080";
  }
};

var envs.test = {
  myUrls: {
    someUrl: "http://test.com";
  }
};

var evns.production = {
  myUrls: {
    someUrl: "http://productiob.com";
  }
};

In qualche modo devi in qualche modo impostare l'ambiente appropriato in cui sei in esecuzione:

var env = envs['<%= SOME_SERVER_VALUE_OR_SOMETHING%>'];

Che dovrebbe legarsi a:

env = env['dev'] // test or production

Quindi mescolare la configurazione appropriata e sovrascrivere i valori predefiniti

config = $.extend({}, config, env);

Questo mescolerà i vars di ambiente corretti che puoi usare:

   function onButtonClick() {
        $.ajax(myApp.config.myUrls.someUrl);
    }

In tal caso, farei qualcosa del genere (scusate la sintassi del mio rasoio):

Codice link HTML:

    @Html.ActionLink("Link Text","ActionMethod","MyController", new { someArgument }, new{ id="mylink"})

Codice Javascript:

$("#mylink").click(function(e){
   e.preventDefault();
   $.ajax({url:'@Url.Action("ActionMethod","MyController",new{ someArgument })'});
});

Questo ti dà alcuni vantaggi:

1. Facilità di adattamento alle modifiche del routing - L'app ASP.NET MVC ha configurazioni di routing configurate. Cosa succede se la configurazione del routing cambia in modo tale che gli URI siano diversi? Usando i metodi di aiuto non ti devi preoccupare di cambiarli manualmente. Il framework sta iniettando l'URI corretto per tuo conto e, quando cambi la configurazione del tuo routing, i tuoi link verranno aggiornati per te.

2. Degradazione elegante: stai creando il tuo sito in modo tale che il link funzioni senza Javascript. Quando il DOM è pronto, stai bloccando l'azione href creata nell'HTML e migliorandola con una chiamata AJAX. Se ti iscrivi al treno di pensiero Unobstrusive Javascript, questo è un vantaggio enorme.

Come puoi vedere è molto simile a quello che stai facendo in # 2 con alcune modifiche minori. Non penso che ci sia molto vantaggio nell'ottimizzare oltre questo. Sapete dove sono gli URL, e il framework lato server sta determinando come costruirli correttamente. I tuoi sviluppatori decidono dove e come vengono creati.