Use object-literal-like notation for attributes?

[tc39]

Use object-literal-like notation for attributes?

[xtuc]

I think we came to a conclusion to add braces. I sent a PR and once it's merged we will close this issue. Thanks

[littledan]

Personally, I'd like to minimize the number of analogous cases we introduce. I think each one adds a bit of confusion. So, I'd prefer to omit the braces.

[devsnek]

there'd likely be a comma there:

import { foo } from 'foo.js' with type: "json",
  foobar: "baz";

[bmeck]

I think the argument for wanting braces/adding familiarity of syntax is less compelling if the non-brace syntax still allows copy pasting albeit requiring a wrapping {/*paste here*/}. I'm fine on either, just pointing out that the usability concern of braces enhancing copy/paste between locations seems somewhat weak.

[littledan]

Personally, I still prefer the no-brackets notation, but I'm open to using the brackets here.

I'd like to propose that, while the choice of a key-value notation is pretty core for Stage 2, the question of whether or not we use brackets is a more detailed/superficial decision, which we could continue debating and conclude for Stage 3. Do folks agree?

[gibson042]

In addition to having nice symmetry for import expressions, I believe braces or other delimiters are actually required to preserve future potential for solving things like #56 (i.e., the trailing comma case mentioned above). The no-braces syntax cuts off too much IMO.

[gibson042]

I don't think the question of braces vs. no braces should block Stage 2.

[chicoxyzzy]

No-braces syntax could be even more confusing. Also we already use curly braces in imports and they are not an object destructuring.

[chicoxyzzy]

I'm in favor of this. I agree with @justinfagnani on readability. Besides that (as I mentioned in #3), this look pretty similar to dynamic import variant and if attributes line is very long, than multiline attributes should be considered.They look better with curly braces (this also makes trailing comma possible).

[jridgewell]

There's an ASI hazard without braces:

import { foo } from 'foo.js' with type: "json"
  foobar: "baz";

labels (while rare) can't be differentiated. Is it supposed to be { type: "json", foobar: "baz"} or { type: "json" }; foobar: "baz" (a labeled string statement).

If we consider this to be arbitrary metadata proposal, it becomes more likely that we'll have multi-line metadata, making this more likely to hit.

[littledan]

@gibson042 I guess I'm still not convinced that we shouldn't solve that within the key/value-only syntax. Nevertheless, I'm not extremely against brackets, it's more of a minor preference.

Do you think we need to resolve this brackets-or-no-brackets question before Stage 2, or can we continue discussing it between Stage 2 and 3?

[xtuc]

I don't have a preference for braces vs no braces, but I'm not convinced that braces would address #56.

In general, my understanding is that braces seems to allow better UX because of copy pasting, traling comma or being closer to the dynamic import. My only concern is that the static restriction on value will confuse developers that think it's just an object.

[bmeck]

I think as long as the attributes are able to be wrapped in {} to become an Object literal it seems a fair tradeoff to allow some copy pasting.

[littledan]

@bmeck I am trying to understand; does this mean you would be OK both with or without braces?

[littledan]

Thanks for clarifying. I think this matches my intuition as well.

[jridgewell]

Ahhh, you’re right.