É considerado uma prática ruim ter PHP em seu JavaScript?

Normalmente, é uma prática ruim para usar a linguagem X para gerar código na linguagem Y.

Tente separar os dois idiomas, tornando data sua única interface - não misture o código .

No seu exemplo, você poderia melhorar o código usando o PHP para preencher uma estrutura cfg disponível para JavaScript:

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

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

Desta forma, o PHP só se preocupa em preencher a estrutura de dados e o JavaScript só se preocupa em consumir a estrutura de dados.

Esse desacoplamento também leva ao carregamento dos dados de forma assíncrona (JSON) no futuro.

Atualização:

Para responder às perguntas adicionais que você fez com sua atualização, sim, seria uma boa prática aplicar o princípio DRY e permitir que o PHP e o JavaScript compartilhem o mesmo objeto de configuração:

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

  ...

Não há mal nenhum em inserir a representação JSON de sua configuração diretamente em sua página como esta. Você não precisa necessariamente buscá-lo via XHR.

JavaScript gerado dinamicamente é uma prática ruim e ruim.

O que você deve fazer é compreender o que significa Seperation of Concerns e Progressive Enhancement.

Isso basicamente significa que você tem HTML dinâmico e JavaScript estático (o que aprimora o HTML).

No seu caso, você provavelmente quer uma aula na sua div e selecione-a com um seletor de turma

O maior problema com o seu snippet é que você está perdendo o # para torná-lo um seletor jQuery válido;).

Eu diria que você deve tentar evitar incluir PHP em seu JavaScript sempre que possível. O que há de errado em alterar o seletor no manipulador click() para uma classe e adicionar a classe ao elemento em questão se você quiser que o manipulador seja acionado e não se você não o fizer;

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

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

  });
</script> 

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

Existem circunstâncias em que você precisa incluir o PHP em seu JavaScript; mas devo admitir que são poucos e distantes entre si.

Uma vez que o exemplo é quando você tem ambientes diferentes; teste, encenação e ao vivo. Cada um deles tem uma localização diferente dos seus ativos (imagens, principalmente). A maneira mais fácil de definir o caminho para que ele possa ser usado pelo JavaScript é algo como:

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

Esta é uma má prática na minha opinião, como você precisaria chamar esse arquivo de algo.php e então você não poderia compactá-lo por exemplo, sem mencionar que não é ok para misturar o seu material de servidor com o seu JavaScript . Tente limitar a mistura entre PHP e JS o máximo possível.

Você sempre pode fazer isso:

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

E então você poderia chamar essa função em um arquivo php, para tornar essas coisas tão pequenas quanto possível.

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

Ao fazer isso (ter arquivos JS maiores, não 2 a 3 linhas em que não importa), você pode aproveitar a compactação do arquivo JS e os desenvolvedores front-end se sentem muito confortáveis trabalhando apenas com JavaScript na minha opinião (como você poderia escrever Python, Ruby, etc, não apenas PHP - e o código poderia ficar maior e maior, dependendo do que você precisa fazer lá).

Eu não acho que isso seja uma prática ruim. Se o ID exigido em seu JavaScript for dinâmico, não há outra maneira de fazer isso.

Eu consideraria essa prática ruim. Ao colocar conteúdo dinâmico dentro de blocos de script você sempre deve estar ciente do fato de que escapar dentro de um contexto javascript não é tão simples quanto você esperaria. Se os valores forem fornecidos pelo usuário, não é suficiente para escape-los via HTML.

A folha de dicas do OWASP XSS tem mais detalhes, mas basicamente você deve adotar esse padrão:

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

Em seguida, em um arquivo .js separado vinculado ao seu html principal, carregue este código:

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

O motivo para usar um arquivo .js separado é duplo:

• É armazenável em cache, portanto, o desempenho é melhor
• O analisador de HTML não é acionado, portanto, não há risco de um bug XSS passar por alguém colocando uma tag rápida do <? php em algum lugar

Algumas pessoas argumentam que é uma prática ruim. Não porque é PHP dentro de JS, mas porque é in-line JS e, portanto, não será armazenado em cache pelo navegador para facilitar o carregamento da próxima vez.

IMO é sempre melhor usar o JSON para passar variáveis entre os dois idiomas, mas acho que depende de você.

Eu diria que, em geral, não faça isso. No entanto, se você quiser passar dados do PHP - > Javascript não me parece tão louco para ter um bloco Javascript inline, onde você tem o código do formulário mostrado abaixo. Aqui o código é apenas passar dados de php para javascript, não criando lógica em tempo real ou algo parecido. A boa parte de fazer isso versus uma chamada ajax é que os dados estão disponíveis assim que a página é carregada e não requer uma viagem extra para o servidor.

<script>
window.config = <?php echo json_encode($config);?>;
</script>

Claro, uma outra opção é criar um arquivo de configuração javascript a partir do PHP, através de alguma forma de script de construção que irá colocar isso em um arquivo .js.

A única coisa que posso pensar que pode realmente causar problemas é quando os erros do PHP são definidos para serem exibidos e por isso ele empurra uma carga de HTML mostrando o erro do PHP em seu JavaScript.

Também porque é um script que, por isso, não aparece e às vezes pode demorar um pouco para perceber por que seu script está quebrado.

Depende de quem, e se você me perguntar, sim eu considero isso de volta por algumas razões. Primeiro de tudo, eu prefiro ter o código javascript em seu próprio arquivo JS que o analisador de php não seria capaz de tocar.

Em segundo lugar, o php é executado apenas na hora do servidor, portanto, se você estiver dependendo de alguma variável no php para alterar seu javascript, isso pode não funcionar muito bem. Se houver alguma configuração de carregamento de página que você deseja controlar com o javascript, normalmente prefiro adicionar esse valor ao DOM com php para que o javascript possa alcançá-lo quando e se quiser (em um div oculto, por exemplo). / p>

Finalmente, apenas para fins organizacionais, isso pode ficar muito chato. É ruim o suficiente para misturar html e php (na minha opinião).

Contendo o PHP em um objeto config data vai 90% do caminho, mas a melhor prática é separá-lo completamente. Você pode usar uma API RESTful para solicitar apenas os dados de que precisa, é um pouco mais de javascript, mas com algumas vantagens.

• O script é estático e pode ser armazenado permanentemente em cache
• PHP não é mais um vetor XSS
• Separação completa de preocupações

Desvantagens:

• Requer uma solicitação HTTP extra
• javascript mais complexo

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

Não é uma má prática APENAS se for usada para inicialização de código javascript, (nos meus temas WordPress, inicializo meus objetos javascript com funções php como site_url () porque é a única maneira de lidar com isso (talvez possamos usar um ajax) pedido para obter um json, e assim ... mas é uma dor na bunda).

Boa prática:

Má prática: