{id:1,name:'test'}
or
{'id':1,'name':'test'}
I've seen both of them used many times and now I'm confused!
{id:1,name:'test'}
or
{'id':1,'name':'test'}
I've seen both of them used many times and now I'm confused!
In JavaScript, the two ways are almost equivalent, you could use both, but the with the unquoted keys version you cannot define properties with the names of reserved keywords, for example:
// valid
var obj = {
'for': 'test'
};
// SyntaxError
var obj = {
for: 'test'
};
That is the reason why the JSON standard allows by spec to use only quoted keys.
Edit: Ok, now let's see why.
The grammar of an Object initializer is defined in the following way:
ObjectLiteral : {} { PropertyNameAndValueList } PropertyNameAndValueList : PropertyName : AssignmentExpression PropertyNameAndValueList , PropertyName : AssignmentExpression
And the PropertyName token can be:
PropertyName : Identifier StringLiteral NumericLiteral
If it is an Identifier, it's pretty clear and explicit by spec that it can't be a Reserved Word because:
7.5.1 Reserved Words Description Reserved words cannot be used as identifiers.
And, the first definition of the Identifier grammar is:
Identifier :: IdentifierName but not ReservedWord
I usually quote both key and value to be safe. Some keywords and other constraints may cause errors in your keys if not quoted.
The first way is perfectly fine, however sometimes you need to use the second method if you have an issue declaring a property that's a reserved keyword.
With the quotes it's always a string, otherwise the interpreter may interpret it as a literal keyword/variable.
You can use either a string or an identifier to specify a property in an object. You can even mix them:
var o = { 'id': 1, name: 'test'}
Both ways give the same result (with the exception that you can also use keywords and separator characters when you use a string).
In a similar way you can use an identifier or a string to read the properties:
alert(o.id);
alert(o['name']);
Note that a property created using a string can be read using an identifier and vice versa, which shows that it's only different ways of creating and accessing the properties, the resulting properties are the same regardless of the method of creating them.
When defining an object like that, you are just declaring identifiers or variables. Identifiers have certain rules that you can check out in the ECMAScript specification in your spare time, but both forms are equivalent. However, browsers behave differently when you try to use reserved or future reserved keywords. For example, these cannot be used as identifiers
break
do
instanceof
typeof
case
else
new
var
catch
finally
return
void
continue
for
switch
while
debugger
function
this
with
default
if
throwdelete
in
try
Not all browsers will flag it as an error but some might. And there's a future reserved keywords list too :)
class
enum
extends
super
const
export
import
To be safe, and not having to look up the specs every time, I'd say its better to quote your identifiers. To really see the problem, check em' out in Safari, at least in version 4.0.4 when you use any of these keywords as identifiers. For example, try these:
var class = "my class";
Won't work in a simple declaration or inside a JSON type object declaration:
var myObject = {
goodProperty: "this works",
class: "gimmeh the errarz codez!",
};