Brian Grinstead [:bgrins] Reporter
	Description • 10 years ago

From a comment on our hacks post (see URL):

> Object literals don’t work in the console for some reason. e.g. “{}” returns “undefined”, “{ foo: ‘bar’ }” returns “bar”, and “{ foo: ‘foo’, bar: ‘bar’ }” raises a SyntaxError

So, typing the following input into the console leads to the following output:

{} -> undefined
{ foo: "bar" } -> "bar"
{ foo: "foo", bar: "bar" } ->  SyntaxError: missing ; before statement


Note that assigning it to a temporary variable and then logging the variable gives the expected output:

var a = {foo:"bar"}; a; -> { foo: "bar" }
var a = { foo: "foo", bar: "bar" }; a; -> { foo: "foo", bar: "bar" }

	Panos Astithas (he/him) [:past] (please ni?)
	Comment 1 • 10 years ago

The web console expects JavaScript code and all those cases are evaluated as blocks. I don't see how it could work any other way. Chrome does the same thing FWIW.

	Victor Porof [:vporof][:vp]
	Comment 2 • 10 years ago

We could cheat and add parens around the evaluated string, to avoid breaking *some* of our user's expectations. Not sure if that will do more harm than good though.

	Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]
	Comment 3 • 10 years ago

(In reply to Victor Porof [:vporof][:vp] from comment #2)
> We could cheat and add parens around the evaluated string, to avoid breaking
> *some* of our user's expectations. Not sure if that will do more harm than
> good though.

It would break perfectly valid code, though.

	Brian Grinstead [:bgrins] Reporter
	Comment 4 • 9 years ago

FWIW Chrome has landed support for this https://twitter.com/ChromeDevTools/status/676531222609182720.

James pasted this code into #devtools, as I understand it this is how they are detecting / fixing the input:

if (/^\s*\{/.test(text) && /\}\s*$/.test(text))
  text = '(' + text + ')';

	Jonathan Allard
	Comment 5 • 8 years ago

I was gonna file the same bug. I agree the fix is kindof hacky. I must say I was expecting the console to behave the same as a Node prompt. Don't know how they do it, but it might be worth looking into?

Typing an object literal is most useful when debugging/'trying stuff', eg. I have a function that works as an enumerator and I want to try it on a known dummy object to see if it works. At least I'm glad to know there's a workaround to put parens around the object literal.

	Jonathan Allard
	Comment 6 • 8 years ago

And indeed, it looks like that's how they do it in the Node repl too (see this helpfully verbose commit):
https://github.com/nodejs/node-v0.x-archive/commit/9ef9a9dee54a464a46739b14e8a348bec673c5a5

	Brian Grinstead [:bgrins] Reporter
	Comment 7 • 8 years ago

Reopening - I think it's worth following suit to match expectations

	Claude Pache
	Comment 8 • 8 years ago

Possible gotcha if the hack of Comment 4 is implemented. Someone tries:

> {foo, bar} = {foo: 2, bar: 3}

it works in the console, but not in a JS file.

Such a feature may bring convenience but also confusion.

	Nicolas Chevobbe [:nchevobbe]
	Comment 10 • 7 years ago

We have a couple of people asking about that from time to time. Most of them don't know that {} can be used as a block. Hiding this behind a special case would not help them understand that either. Maybe we could have a mix of 1. showing a learn more link to mdn when said error is shown, highlighting the case of console input evaluation, 2. ask if they want to wrap the input into parens in some way.

This would provide ease of use to users as well as educational material. I for one, was glad to stumble upon that bug so i was able to learn more about the language in the end.

	Nicolas Chevobbe [:nchevobbe]
	Comment 11 • 6 years ago

What could happen is that we accept the expression (e.g. `{keys: 10}`, but when we show the "command" in the output, it appears like that: `({keys: 10}) — input was modified [Learn more]`, where the [Learn more] part is a link taking you to an MDN page explaining what happened and why.