972530 - Object literals / JSON typed directly in web console do not output as expected

Status: REOPENED

(DevTools :: Console, enhancement, P3)

Description

[Brian Grinstead [:bgrins]]

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" }

Comment 1

[Panos Astithas (he/him) [:past] (please ni?)]

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.

Comment 2

[Victor Porof [:vporof][:vp]]

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.

Comment 3

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

(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.

Comment 4

[Brian Grinstead [:bgrins]]

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 + ')';

Comment 5

[Jonathan Allard]

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.

Comment 6

[Jonathan Allard]

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

Comment 7

[Brian Grinstead [:bgrins]]

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

Comment 8

[Claude Pache]

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.

Comment 10

[Nicolas Chevobbe [:nchevobbe]]

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.

Comment 11

[Nicolas Chevobbe [:nchevobbe]]

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.

Comment 12

[Oriol Brufau [:Oriol]]

If this is done, make sure to do it properly. Initially, Chrome returned an object for {a:1}),({b:2} instead of a SyntaxError.

However, I agree with Jason Orendorff in bug 1264308 comment #6:

This is a longstanding JS wart and I think it's a mistake to try to paper over it. Making a clean spot in one place just makes the rest of the language look shoddy and inconsistent:

$ node
> {}+{}
'[object Object][object Object]'
> eval("{}+{}")
NaN

Comment 13

[:Harald Kirschner :digitarald]

The main use case this would support is that users can just post JSON and have it properly expanded. Both Chrome DevTools and Node's REPL allow executing {} and pretty prints the result. As second mover, we can avoid prior mistakes and get this right the first time with much smaller investment.

where the [Learn more] part is a link taking you to an MDN page explaining what happened and why.

This makes some sense, but maybe we can identify the problem this solves. Users expect the execution to just work, are we trying to teach them to wrap objects with ()? This would inform what kind of material we need to create.

Comment 14

[Nicolas Chevobbe [:nchevobbe]]

(In reply to :Harald Kirschner :digitarald from comment #13)

This makes some sense, but maybe we can identify the problem this solves. Users expect the execution to just work, are we trying to teach them to wrap objects with ()? This would inform what kind of material we need to create.

Not to wrap object in parens, since we would support it from the console, but tell them what are code blocks?