Pregunta sobre namespaces, javascript – ¿Por qué los espacios de nombres se consideran una mala práctica en JavaScript? [cerrado]

4

Me han dicho que los espacios de nombres no deben usarse, ya que "contaminan" el alcance global. Me pregunto cuales son las alternativas?

Cuando quiero definir funciones de utilidad y / o constantes, por ej. para un sitio web, una forma sencilla de hacerlo sería definirlos por espacios de nombres, de esa manera el daño al alcance global se restringe a un solo objeto.

Si los espacios de nombres son una mala práctica, un par de preguntas vienen a la mente:

¿Por qué es esta mala práctica?¿Cuál es el alcance de esta declaración (aplicaciones web / sitios web dinámicos / sitios web estáticos, etc.)?¿Cuáles son las alternativas?

Esta pregunta es el resultado de una discusión iniciada enun post sobre los beneficios de usar extend.js.

@Eliran: en resumen de la acalorada retórica que vuela por aquí, menos es mejor que mucho (enfoque de las variables de espacio de nombres), pero existen técnicas para eliminar variables globales, como usted sugirió. Todo se reduce a cómo lo aborda y con qué se siente cómodo en su código. Jared Farrish
@Raynos: ¿Y cómo accedes al cargador de módulos? Necesitasalgunos símbolo global. No estoy hablando de que el usuario debe crear símbolos globales. Felix Kling
@FelixKling no necesitas símbolos globales. El cargador de módulos es un archivo independiente que se envuelve en un cierre y luego carga su archivo de entrada por usted, luego recursivamente carga las dependencias. Un ejemplo de cómo evitar tener un global.define El token para AMD está cargando módulos como texto y luegoevalEntre ellos en el ámbito de cierre donde eldefine El token está definido. Raynos
¡Esos hippies de nombres! ¡Llama a la Policía de la Variable Global! Jared Farrish

Tu respuesta

2   la respuesta
3

os que haya una definición de espacio de nombres que sea específica de JavaScript de la que no tengo conocimiento.

Actualmente estoy trabajando en una pequeña biblioteca, y todo está encerrado por un objeto de nivel superior (¿espacio de nombres?). No pongo nada en la ventana ni en los tipos intrínsecos; Si necesitas algo de mi biblioteca, está disponible en elkilo objeto.

Para mí, tener este 'espacio de nombres' es unbueno practico ya que me permite saber muy rápidamente si estoy llamando a un método en mi biblioteca. No hay necesidad de anular elwindow.alert método que podría atornillar con otra biblioteca cargada en la página; Solo usakilo.alert para la versión personalizada (este es un ejemplo artificial, pero espero que quede claro).

No necesita un 'espacio de nombres' para saber si está llamando a un método desde una biblioteca, simplemente manipula los objetos y tokens expuestos por esa biblioteca. Raynos
Supongo que lo que necesitamos es una definición más clara del espacio de nombres. JavaScript no los tiene, pero estamos hablando de ellos como si fuera parte del lenguaje. Realmente, solo uso un objeto padre para mi biblioteca. Un espacio de nombres no es realmente una cosa en JavaScript; incluso lo que aquí se denomina espacio de nombres es en realidad solo una cadena de objetos. kiswa
8

Los espacios de nombres en sí mismos son malos porque es un concepto innecesario.

Tener objetos con propiedades y métodos es aceptable. También está bien tener un token de "módulo" que sea similar a un "espacio de nombres", pero el significado es que tiene un token de "módulo" por archivo que contiene todas sus propiedades y métodos. Esto es diferente de un "espacio de nombres" porque solo se crea / modifica en un solo archivo y no se expone como un token global.

¿Cuál es el alcance de esta declaración (aplicaciones web / sitios web dinámicos / sitios web estáticos, etc.)?

Todos los ECMAScript, nunca crear nuevos tokens globales

¿Cuáles son las alternativas?

En lugar de tener espacios de nombres, debería favorecer múltiples tokens de "archivo local". Lo que significa que cada archivo / "módulo" debe estar envuelto en un cierre y usted debe tener acceso a múltiples variables locales dentro de este cierre.

Las variables globales también son malas porque no las necesitas, en absoluto, nunca. La forma de evitar los elementos globales es envolver todo en cierres y ser inteligente en la forma de cargar archivos javascript externos.

Ejemplos de cargadores de módulo global cero

nodo-browserificarwebmakemodul8

Otras lecturas:

Modularidad sin globales.Módulos CommonJS
Lo siento, pero me has perdido aquí. Si estoy usando un cargador compatible con AMD y quiero definir un módulo, lo hagodefine(...) - asi quedefine Tiene que estar ahí para que lo use como un global, ¿no? (Por supuesto que no lo definí yo, sino el cargador de AMD). Y lo mismo se aplica a la carga y ejecución de código que utiliza módulos, ahí necesitorequire. Lucero
Confunde los espacios de nombres con los objetos globales o con el espacio de nombres global (ninguno de ellos es intrínsecamente malo). Los espacios de nombres son un concepto muy necesario. Sin él, no puede tener ámbitos separados (si todos sus ámbitos locales compartían una sola tabla de símbolos, entonces ese es realmente un gran ámbito global). Tienes razón en que la mayoría de las personas usan y deben evitarse los usos globales (incluido yo, desafortunadamente). Sin embargo, tener objetos globales comowindow y los objetos estándar en EMCAScript y DOMes necesario, como esos songlobal Objetos que necesitan ser compartidos entre todos sus códigos. Lèse majesté
@JaredFarrish todos estos archivos están envueltos en cierres para usted. Ajustar cada archivo individual en un cierre es feo cuando una tarea de compilación puede hacerlo por usted. Esos son tokens de "archivo local" o "tokens de ámbito de módulo" Raynos
Si tengo toda mi biblioteca aquí.(function () { // my library here}());, He expuesto 0 globals. ¿Es correcta esta afirmación? user656925

Preguntas relacionadas