Recientemente tuve el problema de que el mismo código se ejecuta en algunos motores y no en otros , y la razón es que el método DOM no puede encontrar los elementos. Esto genera otra pregunta: dado el mismo código, ¿por qué algunos intérpretes/motores pueden encontrar los elementos y otros no?
Intérpretes que son capaces de encontrar los elementos:
Intérpretes que no pueden encontrar los elementos:
Obviamente, es conveniente que los intérpretes sepan lo que haces, pero ¿hay algún inconveniente en asumir automáticamente lo que quieres decir, de modo que los demás no implementen esta función?
Este parece ser el problema del navegador. ¿Es eso correcto?
Estos no son intérpretes, son contextos donde se ejecuta su script.
Difieren porque, por ejemplo, la misma página .html ejecutada desde un servidor enviado a través de HTTPS no representa los mismos riesgos de seguridad que la misma página servida desde el protocolo file:// .
Si bien no pude encontrar el culpable exacto en este caso, descubrí que para Firefox está relacionado con la conexión WebSocket que está creando su biblioteca, que arroja StackSnippets, pero no pude encontrar exactamente por qué arroja StackSnippets. Para ser claros, el problema no es que no puedan encontrar el elemento DOM, sino que el código genera una DOMException que solo se maneja a medias y, por lo tanto, la ejecución del script se detiene.
try { const connection = new WebSocket('wss://b95e1176.databases.neo4j.io:7687/'); console.log('passed') } catch(err) { console.log('caught'); } Entre las pocas diferencias entre los iframes de jsfiddle y los de StackSnippets, primero sospeché la falta de la cláusula allow-same-origin en StackSnippets, luego su falta de window.origin , pero dado que traté de reproducir ambos casos en jsfiddle y todavía funcionó allí, yo Ahora sospecho que esto tiene que ver con los encabezados HTTP enviados a la página, pero como dije, no estoy seguro.
De todos modos, todo esto para decir que, de hecho, se espera que algún código funcione de manera diferente en varios contextos, y también se espera que diferentes navegadores usen varias medidas de seguridad, incluso puede esperar que una versión futura del mismo navegador se comporte de manera diferente en el mismo contexto.
Desafortunadamente, no hay mucho que nosotros como desarrolladores web podamos hacer aparte de pruebas extensas y regulares.
La estructura de
<div id="foo" data-function="bar">string1</div> <div id="lorem" data-function="ipsum">string2</div> <div id="dolor" data-function="es">string3</div>tiene para cada elemento:
iddata-functionEl JavaScript de
function myfunction(context, id, func, str) { context[id] = undefined; return context[func] = function() { var config = { a: id, b: str, //otherConfigs... }; context[id] = new NeoVis.default(config); context[id].render(); console.log(`function ${func} was called and ${id} is the id`); }; } for (let item of document.querySelectorAll("#foo, #lorem, #dolor")) { myfunction(window, item.id, item.getAttribute("data-function"), item.innerText)(); } tiene las últimas tres líneas que inician la llamada para myfunction . Ahora, si no tiene elementos con los id de foo , lorem y dolor , querySelectorAll devuelve un objeto similar a una matriz vacío y myfunction nunca se llamará. Deberá asegurarse de que sus elementos div se puedan encontrar correctamente y cambiar el selector en consecuencia. Luego, defina sus funciones como valores para data-function y sus cadenas como textos internos para los divs.