2012-02-17 28 views
12

http://sugarjs.com/Cómo usar sugar.js en nodejs?

Es una biblioteca así que puedo cargarla en el navegador directamente. También es un paquete npm, pero ¿cómo puedo usarlo como un moudule?

En el navegador, cargar un archivo js cambiará los objetos fácilmente, pero no es lo mismo al trabajar en nodejs, y no puedo resolverlo.

Respuesta

8

Sugar no se utiliza como un módulo CommonJS estándar, ya que el objetivo de la biblioteca es modificar los prototipos incorporados. Si lo requiere en su proyecto, todos los objetos incorporados se extenderán y podrá usarlos desde allí.

Editar: Esto ya no es cierto a partir de v2.0.0. La modificación de prototipo ahora es opcional, por lo que puede usar Sugar como cualquier otro módulo de nodo que utilice el objeto exportado. Para más información, véase el https://sugarjs.com/quickstart/

28

Usted acaba de instalar el módulo:

npm install sugar 

luego usarlo al igual que la API dice:

var http = require('http'); 
var sugar = require('sugar'); 

http.createServer(function (req, res) { 

    res.writeHead(200, { 'Content-Type': 'text/html' }); 
    res.end('hey_there_good-lookin'.camelize()); 

}).listen(process.env.PORT || 8080); 
+0

Buena demostración. Entiendo ahora. – jiyinyiyong

+8

¿Hay algún punto en asignar el valor de retorno de 'require ('sugar')' a una variable? – callum

+4

@callum Nope 'require ('sugar')' devuelve un objeto vacío. Escribir la parte 'var sugar =' es inútil. –

1

No utilice sugar.js - Modifica prototipos nativos entonces TODO los usará, no solo su módulo. Hacer esto es increíblemente insidioso, no es modular, y te morderá en el culo cuando menos lo esperes.

Vale la pena repetirlo: no utilice ningún módulo que modifique prototipos nativos fuera del contexto (muy razonable) de polifilling. No uses Sugar.js. Especialmente en node.js - hay un sistema de módulos allí por una razón. Personalmente he tenido problemas terribles con cosas que modifican los prototipos nativos. Cosas raras pueden suceder en las entrañas de tu código.

Aquí hay más información sobre por qué la modificación de objetos nativos es malo:

http://www.nczonline.net/blog/2010/03/02/maintainable-javascript-dont-modify-objects-you-down-own/

ACTUALIZACIÓN: Parece que ahora trata de azúcar v2.0.0 nativos que se extienden como opt-in, que es mucho mejor (ya que los nativos no se extienden por defecto).

+0

B T, estos son argumentos antiguos, y en su mayoría válidos, contra la modificación de los objetos del host en el navegador y los prototipos nativos. El desarrollador de Sugar está muy consciente de estos problemas, y Sugar está diseñado teniendo en cuenta la seguridad de ellos. http://sugarjs.com/native –

+0

Habiendo dicho eso, yo diría que usar sugar.js en una biblioteca aún no es aconsejable. Pero no veo ninguna razón para no usarlo en las aplicaciones, y de hecho, mi equipo lo ha estado utilizando en aplicaciones grandes y frecuentemente modificadas durante varios años para lograr un gran efecto. Hasta ahora hemos encontrado exactamente un problema, y ​​era obvio y simple de resolver (fue causado por una versión de Sugar de tres años, solo tuvimos que actualizarlo). –

+0

Incluso si está usando solo en sus aplicaciones, es muy posible (¿podría decir probable?) que interactuará mal con algún código aleatorio que * usted * escribió o algún código aleatorio que haya importado. Literalmente nunca toleraría sugar.js - me he encontrado con problemas varias veces, y por eso escribí esta respuesta en primer lugar. El desarrollador de azúcar definitivamente es tan consciente del problema que dedicó todo un espacio en el sitio para sofocar a la chusma. Desafortunadamente * no puedes * hacer que sugar.js sea seguro. La API simplemente no es segura en javascript, por no decir que podría estar en otros idiomas –