È considerata una cattiva pratica avere PHP nel tuo JavaScript

Tipicamente, è cattiva pratica usare il linguaggio X per generare codice nella lingua Y.

Prova a disaccoppiare le due lingue rendendo data la loro unica interfaccia - non mescolare il codice .

Nel tuo esempio, potresti migliorare il codice utilizzando PHP per popolare una struttura cfg disponibile per JavaScript:

<script type="text/javascript">
  var cfg = {
    theId: "<?php echo $divID ?>",
    ...
  };

  $(document).ready(function(){
     $("#" + cfg.theId).click(funtion(){
       alert('do something');
     });
  });
</script>

In questo modo, PHP si preoccupa solo di popolare la struttura dei dati e JavaScript si preoccupa solo di consumare la struttura dei dati.

Questo disaccoppiamento apre anche il modo di caricare i dati in modo asincrono (JSON) in futuro.

Aggiornamento:

Per rispondere alle domande aggiuntive che hai chiesto con il tuo aggiornamento, sì, sarebbe buona norma applicare il principio DRY e lasciare che PHP e JavaScript condividessero lo stesso oggetto di configurazione:

<script type="text/javascript">
  var cfg = <?php echo json_encode($cfg) ?>;

  ...

Non c'è nulla di male nell'inserire la rappresentazione JSON della tua configurazione direttamente nella tua pagina come questa. Non devi necessariamente recuperarlo tramite XHR.

JavaScript generato dinamicamente è una pratica orribile e pessima.

Quello che dovresti fare è comprendere cosa significhi la separazione tra preoccupazioni e miglioramento progressivo.

Questo significa fondamentalmente che hai un codice HTML dinamico e JavaScript statico (che migliora l'HTML).

Nel tuo caso probabilmente vorrai un corso sul tuo div e selezionalo con un selettore di classe

Il problema più grande con il tuo snippet è che ti manca il # per renderlo un selettore jQuery valido;).

Direi che dovresti cercare di evitare di includere PHP nel tuo JavaScript, ove possibile. Cosa c'è di sbagliato nel cambiare il selettore nel tuo click() handler in una classe e aggiungere la classe all'elemento in questione se vuoi che il gestore venga licenziato, e non se non lo fai,

<script type="text/javascript">
  $(document).ready(function(){

     $('.foo').click(funtion(){
       alert('do something');
     });

  });
</script> 

<div id="bar" class="<?php echo ($someCond ? 'foo' : ''); ?>">Hello</div>

Ci sono circostanze in cui è necessario includere PHP nel tuo JavaScript; ma devo ammettere che sono pochi e lontani tra loro.

Un esempio è quando hai ambienti diversi; test, messa in scena e live. Ognuno di loro ha una posizione diversa delle risorse (principalmente immagini). Il modo più semplice per impostare il percorso in modo che possa essere utilizzato da JavaScript è qualcosa di simile;

var config = { assets: "<?php echo $yourConfig['asset_url']; ?>" };

Questa è una cattiva pratica secondo me, dato che avresti bisogno di chiamare questo file something.php e quindi non potresti comprimerlo per esempio, senza menzionare che non è corretto mescolare il tuo server con il tuo JavaScript . Cerca di limitare il più possibile il mix tra PHP e JS.

Puoi sempre farlo invece:

function setOnClick(divid) {
 $(divid).click(funtion(){
   alert('do something');
 });
}

E quindi potresti chiamare questa funzione in un file php, per rendere queste missioni il più possibile ridotte.

$(function() {
  setOnClick('<?php echo $divId; ?>');
});

Facendo questo (avendo file JS più grandi, non 2-3 linee dove non ha importanza) puoi trarre vantaggio dalla compressione del file JS e gli sviluppatori front-end si sentono a loro agio lavorando solo con JavaScript a mio avviso (come potresti scrivere Python, Ruby etc non solo PHP - e il codice potrebbe diventare sempre più grande a seconda di cosa devi fare lì.

Non penso che questa sia una cattiva pratica. Se l'ID richiesto nel tuo JavaScript è dinamico, non c'è altro modo per farlo.

Considererei questa cattiva pratica. Quando inserisci contenuti dinamici all'interno dei blocchi di script, devi sempre essere consapevole del fatto che l'escape in un contesto javascript non è così semplice come vorrai. Se i valori sono stati forniti dall'utente, è non sufficiente per fuggerli da html.

Il il cheat OWASP XSS ha più dettagli, ma in pratica dovresti adottare questo modello:

<script id="init_data" type="application/json">
    <?php echo htmlspecialchars(json_encode($yourdata)); ?>
</script>

Quindi, in un file .js separato collegato dal tuo html principale, carica questo codice:

var dataElement = document.getElementById('init_data');
var jsonText = dataElement.textContent || dataElement.innerText  // unescapes the content of the span
var initData = JSON.parse(jsonText);

Il motivo dell'utilizzo di un file .js separato è duplice:

• È memorizzabile nella cache, quindi le prestazioni sono migliori
• Il parser HTML non viene attivato, quindi non vi è alcun rischio che un bug XSS passi attraverso qualcuno che inserisce un tag HTML <? php da qualche parte

Alcuni sostengono che è una cattiva pratica. Non perché è PHP in JS, ma perché è inline JS e quindi non verrà memorizzato nella cache dal browser per facilitare il caricamento la prossima volta.

IMO è sempre meglio usare JSON per passare variabili tra le 2 lingue, ma suppongo che dipenda da te.

L'unica cosa che riesco a pensare che possa davvero causare problemi è quando gli errori PHP sono impostati per essere visualizzati e quindi spinge un carico di HTML che mostra l'errore PHP nel tuo JavaScript.

Anche perché è nella sua sceneggiatura e quindi non mostra e a volte può essere necessario un po 'per capire perché il tuo script è rotto.

Dipende da chi, e se me lo chiedi, sì, lo considero di nuovo pratica per alcuni motivi. Prima di tutto, preferirei avere il codice javascript nel proprio file JS che il parser php non sarebbe in grado di toccare.

In secondo luogo, php viene eseguito solo al momento del server, quindi se si sta dipendendo da qualche variabile in php per cambiare il javascript, potrebbe non funzionare molto bene. Se c'è qualche impostazione di caricamento della pagina che vuoi controllare con javascript, in genere preferisco aggiungere quel valore al DOM con php in modo che javascript possa raggiungerlo quando e se vuole (in un div nascosto, per esempio).

Infine, solo per scopi organizzativi, questo può diventare molto fastidioso. È già abbastanza brutto mixare html e php (secondo me).

Il contenimento del PHP in un oggetto dati config è del 90%, ma la migliore pratica consiste nel separarlo completamente. Puoi usare un'API RESTful per richiedere solo i dati di cui hai bisogno, è un po 'più javascript ma con alcuni vantaggi.

• Lo script è statico e può essere memorizzato nella cache in modo permanente
• PHP non è più un vettore XSS
• Completa separazione delle preoccupazioni

Svantaggi:

• Richiede una richiesta HTTP aggiuntiva
• javascript più complesso

Script

//pure javascript
$.on('domready',function({
    //load the data
    $.get({
       url:'/charts/3D1A2E', 
       success: function(data){
           //now use the chart data here
           ChartModule.init(data);
       }
    });
})

Non è una cattiva pratica SOLO se è usata per l'inizializzazione del codice javascript, (nei miei temi WordPress, inizializzo i miei oggetti javascript con funzioni PHP come site_url () perché è l'unico modo per gestirli (forse potremmo usare un ajax richiesta di ottenere un json, e così ... ma è un rompicoglo.

Buona pratica:

Cattiva pratica: