¿Se considera una mala práctica tener PHP en su JavaScript?

Normalmente, es una mala práctica usar el lenguaje X para generar código en el idioma Y.

Intente desacoplar los dos idiomas haciendo que datos sea su única interfaz, no mezcle el código .

En su ejemplo, podría mejorar el código utilizando PHP para completar una estructura cfg que está disponible para JavaScript:

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

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

De esta manera, PHP solo se preocupa por rellenar la estructura de datos y JavaScript solo se preocupa por consumir la estructura de datos.

Este desacoplamiento también abre el camino para cargar los datos de forma asíncrona (JSON) en el futuro.

Actualizar:

Para responder a las preguntas adicionales que hizo con su actualización, sí, sería una buena práctica aplicar el principio DRY y permitir que PHP y JavaScript compartan el mismo objeto de configuración:

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

  ...

No hay ningún daño en insertar la representación JSON de su configuración directamente en su página de esta manera. No necesariamente tienes que buscarlo a través de XHR.

El JavaScript generado dinámicamente es una práctica horrible y mala.

Lo que se supone que debes hacer es comprender lo que significa Separación de preocupaciones y Mejora progresiva.

Esto básicamente significa que tienes HTML dinámico y JavaScript estático (lo que mejora el HTML).

En su caso, es probable que desee una clase en su div y selecciónela con un selector de clase

El mayor problema con tu fragmento es que te estás perdiendo el # para que sea un selector de jQuery válido;).

Diría que deberías intentar evitar incluir PHP en tu JavaScript siempre que sea posible. ¿Qué tiene de malo cambiar el selector en su controlador click() a una clase y agregar la clase al elemento en cuestión si desea que se active el controlador, y no si no lo hace?

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

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

  });
</script> 

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

Existen hay circunstancias en las que necesitas incluir PHP en tu JavaScript; pero debo admitir que estos son pocos y distantes entre sí.

Una vez, el ejemplo es cuando tienes diferentes entornos; Prueba, puesta en escena y en vivo. Cada uno de ellos tiene una ubicación diferente de sus activos (imágenes, principalmente). La forma más fácil de establecer la ruta para que JavaScript pueda utilizarla es algo como:

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

En mi opinión, esta es una mala práctica, ya que necesitarías llamar a este archivo something.php y luego no pudiste comprimirlo, por ejemplo, no mencionar que no está bien mezclar cosas de tu servidor con tu JavaScript. . Trate de limitar la mezcla entre PHP y JS tanto como sea posible.

Siempre puedes hacer esto en su lugar:

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

Y luego puedes llamar a esta función en un archivo php, para hacer que estas cosas de mezcla sean lo más pequeñas posible.

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

Al hacer esto (teniendo archivos JS más grandes, no 2-3 líneas en las que no importa), puede aprovechar la compresión del archivo JS y los desarrolladores de aplicaciones frontales se sienten muy cómodos trabajando solo con JavaScript en mi opinión (como podría escribir Python, Ruby, etc. no solo PHP, y el código podría aumentar de tamaño dependiendo de lo que tenga que hacer allí.

No creo que esto sea una mala práctica. Si el ID requerido en su JavaScript es dinámico, no hay otra manera de hacerlo.

Consideraría esta mala práctica. Al colocar contenido dinámico dentro de bloques de secuencias de comandos, siempre debe tener en cuenta el hecho de que escapar dentro de un contexto javascript no es tan simple como cabría esperar. Si los valores fueron proporcionados por el usuario, es no suficiente para html-escape ellos.

El href="https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet#RULE. debe adoptar este patrón:

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

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

Algunas personas dirían que es una mala práctica. No porque sea PHP dentro de JS, sino porque está en línea JS y, por lo tanto, el navegador no lo almacenará en caché para facilitar la carga la próxima vez.

OMI siempre es mejor usar JSON para pasar variables entre los 2 idiomas, pero supongo que depende de ti.

Yo diría que en general no lo hagas. Sin embargo, si desea pasar datos desde PHP - > Javascript no me parecería una locura tener un bloque de Javascript en línea donde tienes el código del formulario que se muestra a continuación. Aquí, el código simplemente está pasando datos de php a javascript, no creando lógica sobre la marcha o similar. Lo bueno de hacer esto frente a una llamada ajax es que los datos están disponibles tan pronto como la página se carga y no requiere un viaje adicional al servidor.

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

Por supuesto, otra opción es crear un archivo de configuración javascript desde PHP a través de algún tipo de script de construcción que lo coloque en un archivo .js.

Lo único en lo que puedo pensar que realmente puede causar problemas es cuando los errores de PHP están configurados para mostrarse, por lo que introduce una carga de HTML que muestra el error de PHP en tu JavaScript.

También porque está en el script, por lo tanto, no se muestra y, a veces, puede tomar un tiempo darse cuenta de por qué tu script está roto.

Depende de quién, y si me preguntas, sí, lo considero una práctica atrasada por varias razones. En primer lugar, prefiero tener un código javascript en su propio archivo JS que el analizador php no pueda tocar.

En segundo lugar, php se ejecuta solo a la hora del servidor, por lo que si depende de alguna variable en php para cambiar su javascript, es posible que no funcione muy bien. Si hay alguna configuración de carga de página que desea controlar con javascript, normalmente prefiero agregar ese valor al DOM con php para que javascript pueda alcanzarlo cuando y si lo desea (en un div oculto, por ejemplo).

Finalmente, solo por motivos de organización, esto puede ser muy molesto. Es lo suficientemente malo como para mezclar html y php (en mi opinión).

La contención de PHP en un objeto de datos config va del 90%, pero la mejor práctica es separarlo por completo. Puede usar una API RESTful para solicitar solo los datos que necesita, es un poco más de javascript pero con algunas ventajas.

• El script es estático y se puede almacenar en caché de forma permanente
• PHP ya no es un vector XSS
• Separación completa de preocupaciones

Desventajas:

• Requiere una solicitud HTTP adicional
• javascript más complejo

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

NO es una mala práctica SOLO si se usa para la inicialización de código javascript, (en mis temas de WordPress, inicializo mis objetos javascript con funciones php como site_url () porque es la única manera de manejar eso (tal vez podríamos usar un ajax solicito obtener un json, y entonces ... pero es un dolor en el culo).

Buena práctica:

Mala práctica: