I've found some weird for me function in the project that I'm currently working on:
Building.Widget.ClientIdV2 = function Building$Widget$ClientIdV2() {
...
What does $ mean here and what does the "name" of this function mean (Building$Widget$ClientIdV2) ? I've seen also ... = function () { code so far..
Thank you.
The dollar sign has no special significance. It is just a character you can use in an identifier.
The name of the function can be used to refer to the function from inside its own scope (which can be useful for recursive functions) and will appear in useful places like stack traces.
$ is just another character you can use in an identifier, it has no intrinsic special meaning. It could be Q or _ just as easily.
In that particular example, the original author is naming the function in a way that they can readily see that it's the ClientIdV2 function on the Widget object on the Building object. But that's just the author's convention. That's useful for looking at call stacks and such.
It looks like it's someones naming convention. You can preety much put anything that you want in Javascript variable names. You should try finding general naming conventions in Javascript in case that you're interested in that(it will make your work with other developers much easier).
For example, some people like to put the $ before jQuery variables, implying that they can chain functions on that selection.
In Javascript it's completely valid to use $ in names, just like letters or underscores, so syntactically it means nothing special. Thought it's frequently used to give extra semantic meaning to names, for eg. it may indicate that a variable is special to a system (internal variable, global, etc.). In your case I believe $ indicates object hierarchy. The use of $ is just conventional.
Related
Does anyone know if the reasoning behind the use of dollar methods and variables in angularJS is to instruct angularJS to avoid checking those values when a digestion is going on? So, if angular comes across $scope.$value and $scope.value, then it will avoid checking the former since it's prefixed with a dollar character in its variable name?
It is just a naming convention from the below snippet
http://docs.angularjs.org/tutorial/step_05
'$' Prefix Naming Convention
You can create your own services, and in
fact we will do exactly that in step 11. As a naming convention,
angular's built-in services, Scope methods and a few other angular
APIs have a '$' prefix in front of the name. Don't use a '$' prefix
when naming your services and models, in order to avoid any possible
naming collisions.
http://docs.angularjs.org/guide/concepts#angular_namespace
Angular Namespace
To prevent accidental name collision, Angular
prefixes names of objects which could potentially collide with $.
Please do not use the $ prefix in your code as it may accidentally
collide with Angular code.
There are a few times Angular ignores variables prefixed with the dollar sign:
In Schumli's comment below, where json filters will not output them
When using the {{ }} directive, angular will not show nested $
variables. For example this only displays the visible property.
<div ng-init="n = { visible: 'foo', $ignore: 'bar' };">{{ n }}</div>
Additionally when adding an explicit watcher on a scope object, changes to properties with a leading dollar sign of this object will not trigger the watcher. See this updated fiddle.
angular.equals() ignores keys prefixed with $.
The $ prefix denotes a variable, parameter, property, or method that belongs to the core of Angular.
Properties on objects that originate inside the framework, but are not actually part of the API, may begin with $ – or even $$ – to denote a private method or property. This is the same way the _ prefix is often used in other libraries.
It doesn't have any effect on the way code is interpreted by the runtime, although the framework itself may give it special meaning. Basically, it is a naming convention that says "You shouldn't mess with this".
Not completely sure, but I believe AngularJS internals rely on manipulating these $-prefixed variables during the digest. Checking these variables would mean that the digest would never stabilize, since they may constantly change during each cycle of the digest.
Don't quote me on it though. :)
Dollar ($) signs also prevent elements from being iterated (or interpreted) in certain directives.
So for example properties that start with $ are not used in ng-repeat because of an if clause in the for loop:
if(collection.hasOwnProperty(key) && key.charAt(0) != '$')
Someone made an issue about the topic here on angulars github page
In the method shallowCopy properties that start with $$ are skipped because of an if clause while iterating the properies:
if (!(key.charAt(0) === '$' && key.charAt(1) === '$')) {
I always figured $ looks like an "S" for service.
#MarcoS provided the link to https://thinkster.io/a-better-way-to-learn-angularjs/scope-vs-scope which explains a difference between $scope and scope. I found this useful, adding to the information in other answers.
In an angular directive there is a link and controller. The link is a standard function with a fixed set of parameters: scope, element, attributes object.
The controller's arguments are managed by the Angular injector and are not order dependent. The injector resolves which objects to pass in by looking for the parameters starting with $.
The author of https://thinkster.io/a-better-way-to-learn-angularjs/scope-vs-scope does a better job of explaining it.
There's a huge difference, not in variables, but in the parameters that a controller receives. A scope parameter is completely different from a $scope one.
For more information, check out this useful post: http://www.thinkster.io/angularjs/aw9kWmdnik/angularjs-scope-vs-scope
It took me a while but I finally figured out what the purpose of symbols in ECMAScript 6 is: avoiding name collision when attaching properties to shared objects - HTML elements e.g. (In case you're stuck on the same question, I recommend this article.)
But then I stumbled upon Symbol.for(). Apparently ECMAScript 6 will maintain a global symbol registry which you can query with this function by providing the symbol description. Come again? If I use symbols to avoid name collisions, why would I want code other than my own to use them? (*) And how would I avoid name collisions in that global registry? Sharing of symbols seems to completely subvert the concept and a global registry doubly so.
(*) Yes, I know symbols aren't truly private, but that's besides the point.
If you don't want your symbols to be available in GlobalSymbolRegistry, just don't use Symbol.for.
Only use it if you want to allow other codes to use your symbol.
In the following example, I create a symbol to store data in DOM elements. And I may want every other code (e.g. internal raw uncompiled handlers) to read that data. So I make the symbol globally available.
var sym = Symbol.for('storeDataInDOM');
document.querySelector('button')[sym] = 'Hello, world!';
<button onclick="alert(this[Symbol.for('storeDataInDOM')])">Click me</button>
It's like creating global variables: should be avoided in general, but has its advantages. But with symbols instead of strings.
If I use symbols to avoid name collisions, why would I want code other than my own to use them?
That's not the only use case of symbols. The two most important other ones are:
they don't collide with string-keyed properties
they are not enumerated by the usual mechanics
Sharing of symbols seems to completely subvert the concept and a global registry doubly so.
Not necessarily. Right from that article you read: "The registry is useful when multiple web pages, or multiple modules within the same web page, need to share a symbol." The best example for these are the intrinsic symbols - they guarantee interoperability across realms, that's why the global symbol registry is more global than your global scope.
For example you might have a library that is loaded in a web page, an iframe and a web worker. If you share data between those environments (realms), all of the three instances of your library would want to use the same symbol.
There also is a real need interoperability between different libraries, which might not even know about each other. Good examples are transducers, algebraic structures or promises. Would ES6 already be in use, all of these would have agreed on common names in the global symbol registry, instead of relying on strings like these or the then method.
Another good example would be custom hooks defined by your engine, e.g. a Symbol.inspect = Symbol.for("inspect") that you can use to define custom stringification behavior to be used by console.log. Admittedly, that symbol does not necessarily need to be made available through the global symbol registry, it could as well be put on that specific library object (e.g. console.inspect = Symbole("console.inspect")).
And how would I avoid name collisions in that global registry?
Just like you previously did with properties, or global module objects: by using very long, very descriptive names - or by good faith. Also there are some naming conventions.
I invented the most useful feature of Symbol.for() call. If there is using symbols in your code sometimes it is difficult to use conditional breakpoints while debugging. For example, you need to catch if the variable equals the value which is of symbol type and this value binded in the different module. The first difficult way is to use this value as a constant and export it from that module. In this case, the condition of the breakpoint will look:
catchedVariable === exportedSymbolConst
But the easiest way is to temporarily change the code inside the module adding .for to Symbol. Then you can write the condition:
catchedVariable === Symbol.for('string_key')
After the successful debugging you will be changing the code back just removing .for part.
Creating online learning material for mathematics, I want to allow users of my website to define (mathematical) functions, which are, by definition, side-effect free. The easiest way to achieve this is by doing the following
// ... get string entered by user and store it in variable user_code
// now build function
var user_function = eval ("(function (x) { return (" + user_code + "); })");
If the users enters x*x, user_function will contain a function that calculates the square of its argument.
Now this opens my page to cross-site scripting and malicious code.
Is there any way to avoid this, apart from writing an expression parser myself? In other words, I want to allow execution of functions in a well-defined context, for example, without the function accessing global variables.
Well, there are lots of good expression parsers that already exist for javascript, why re-invent the wheel?
I'm sure it'll be easier and safer to use something like math.js that has an expression parser built-in...
Over time, I created a bunch of various JavaScript functions. Most of them are static functions, and do things like modify the appears of a date, create the select menu HTML from an array, etc.
I currently have them all in a file called "general.js" which is in turn directly called by my HTML page, and each of them look something like:
function modifyDate(data){....}
function makeArray(arr){....}
And then I use them as:
alert(modifyDate("12/14/2013"));
I am thinking this is a bad idea as it might conflict with other libraries. Instead, I am thinking of something like the following:
myLibrary={};
myLibrary.modifyDate= function(data){....}
myLibrary.makeArray= function(arr){....}
And them use them as:
alert(myLibrary.modifyDate("12/14/2013"));
Note that I am kind of making this up as I go. Please provide advice how I should best organize my JavaScript library. Thank you
What you're describing is called namespacing and is generally considered a good idea.
Some more discussion of namespacing can be found in this question: Why do they use namespaces in javascript?
In general the benefits of namespacing are:
Limiting pollution of the global scope and preventing naming collisions
Providing context for your function names (we'd expect different results for WindowUtils.getHeight and MenuUtils.getHeight for instance).
So your example would provide the first benefit, though not necessarily the second one if this is just a group of grab-bag functions. Whether thats a good thing or not is totally dependent on your individual project and what you're trying to do.
Note that if you're going to be namespacing, you may want to look into the module pattern which is a way of protecting the scope of your namespaces to allow for private variables/protected state. There's a good example in this answer to a similar question or you could check out this canonical blog post on the module pattern
In your case the module pattern would look something like this:
var myLibrary=(function(){
var privateVariable; //accessible by your functions but not in the global context
return {
modifyDate: function(data){....},
myLibrarymakeArray: function(arr){....}
};
}())
This is a two part question: General, and Specific.
For the general: I often find myself wondering what constitutes a viable variable name in JavaScript? I know there are certain 'words' that can not be used as variables in JavaScript; But I have yet to come across either a list of non-viable variable names, or a rule to apply when creating a variable name. I usually err on the side of caution and use obscure names if I am unsure.
It would be nice to know, with certainty, what can be used as a JavaScript variable, and what can not be used.
Any advice?
For the specific: I am wondering if I can use href as a variable name in my JavaScript? Is it viable, or is it reserved?
Afterthought: Perhaps I can extend this question to encompass JavaScript function names as well. What names are viable, and which are reserved? If the two questions are related, I will edit to ask both.
Note: I am not asking which characters can be used in a JavaScript variable; That question is already answered here.
Uhm, actually, you can use any kind of name as a variable name.
Instead of referring to the variable by name, refer to it by array index, since all object properties in JS can be accessed by index*, as well as the fact that global variables are simply properties of the window object.
*a string index can contain literally any kind of character sequence
So the question in turn might be more on the lines of "should I use reserved words as variable names?"
Common sense would say you shouldn't, except when such a name is actually related to the construct and you can't find a suitable replacement.
window['function'] = 2;
window['if'] = 4;
window['var'] = 8;
alert(window['function'] + window['if'] + window['var']);
Warning!
Reserved words are different from native functionality.
Although in many cases you can use names used as reserved keywords as variables, native functionality can actually be overwritten.
For instance Mr Sarris above mentioned Node, (which is a native function not a reserved keyword), you can actually overwrite it by doing window['Node'] = myNewThing;. This has been used in some cases to achieve "wrapper" or "hotfix" functionality, but it is not guaranteed to work in a cross-browser manner (eg; MSIE's console object).
You can find lists of reserved words in JavaScript.
href is certainly fine as a variable name because href is an attribute of an a tag and in no way conflicts with JavaScript naming.
If you are ever in doubt as to whether or not a variable is already in use you can always open the developer tools (F12 in most browsers), go to the console, and type in the name. In this case you'll get:
> href
x ReferenceError: href is not defined
Nothing is using it, so it is yours to use without problem.
Just for kicks if you did enter a reserved word it would look like:
> finally
x SyntaxError: Unexpected token finally
Or if it was a native but already taken word it might look like:
> Node
function Node() { [native code] }
(Node is already defined, and its a native function)
Every programming language has a list of reserved words.
These reserved words consist of the parts that constitute that programming language.
For JavaScript, things like for or function or if are reserved words, since these have special meaning in the language itself. As a rule of thumb you cannot re-use words as identifiers (names) that already have a meaning in that particular language.
The official language specification is a good place to look that up. For JavaScript see the ECMAScript specification, section 7.6.1 (section 7.6. clarifies the other rules that apply to identifier naming).
Your question whether href is okay to use in JS is easily answered by looking there.
rules for variable declaration (on codelifter)
href is ok to use