Hacker News Reader

Comment by Hovertruck | Hacker News Reader

This is pretty cool.

Is there any particular reason for the name 'fx', though? Seems a bit strange for a global variable name to be a two letter string that could be used relatively commonly as a variable name in browser-land.

Aside from that, I love it!

View on HN

I thought that might come up and maybe should clear it up in the docs - `fx` is a term used often in finance or accounting to refer to forex or, loosely, 'currency'

So, in our analytics application, we have multiple currencies represented in one table, the result being that we have a separate column for "currency" (next to e.g. "revenue") which is shortened to "fx".

It is definitely a potentially common global variable name though, so there's a handy `noConflict` method that can be used to assign the library to another var (eg `money`), and restore the previous global value of `fx` before moneyjs was loaded.

Eg:

    var money = fx.noConflict();
    // now it's `money.convert()`, and `fx` is whatever it was previously

Also, if using money.js as a node package or AMD module, you simply assign it to whatever you like:

    var moneyBro = require("money"); // no need for `fx`

Having said that, I think it works nicely as a namespace, if confusion can be avoided

Or you could just call it CurrencyConverter and let me say var fx = new CurrencyConverter(), deciding if I want it to be called that. Global clobbering should be opt-in, not opt-out.

That might not work so well with the structure of the library, but I'm open to calling it something else, if enough people say it's an issue - so feel free to fork it and do a pull request.

moneyjs-noconflict.patch:

  --- money.js
  +++ money.js
  @@ -13,6 +13,8 @@
   		return new fxWrapper(obj);
   	};
   
  +	var NS = 'CurrencyConverter';
  +
   	// Current version.
   	fx.version = '0.0.1';
   
  @@ -122,28 +124,14 @@
   	// Otherwise, just add `fx` to the global object
   	if (typeof module !== 'undefined' && module.exports) {
   		module.exports = fx;
  -		fx.fx = fx;
  +		fx[NS] = fx;
   	} else if (typeof define === 'function' && define.amd) {
   		// Return the library as an AMD module:
   		define([], function() {
   			return fx;
   		});
   	} else {
  -		// Use fx.noConflict to restore `fx` back to its original value before money.js loaded.
  -		// Returns a reference to the library's `fx` object; e.g. `var money = fx.noConflict();`
  -		fx.noConflict = (function(previousFx) {
  -			return function() {
  -				// Reset the value of the root's `fx` variable:
  -				root.fx = previousFx;
  -				// Delete the noConflict function:
  -				fx.noConflict = undefined;
  -				// Return reference to the library to re-assign it:
  -				return fx;
  -			};
  -		})(root.fx);
  -
  -		// Declare `fx` on the root (global/window) object:
  -		root['fx'] = fx;
  +		root[NS] = fx;
   	}
   
   	// Root will be `window` in browser or `global` on the server:

You can change NS to whatever you like, but I believe that this is all you need to do. Because everything internally uses the enclosed `var fx`, I don't foresee issues.

Looks like you can use fx.noConflict() to work around possible global conflicts.

Reply on news.ycombinator.com