Use object-literal-like notation for attributes?
justinfagnani opened this issue · 16 comments
To me, reading the key-value structure of attributes is a little difficult without the common structure of braces. An option is to use object-liter-like notation:
import {foo} from 'module' with {type: 'json'};Since braces are already used with imports, and they aren't actual expressions, I don't think this would be any more confusing than what we have now. Both uses may look a bit like expressions (destructuring and object-literals respectively) and that's nice to intuitively understand some of the syntax, but they aren't and this is ok because import is special.
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.
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).
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.
@bmeck I am trying to understand; does this mean you would be OK both with or without braces?
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.
Thanks for clarifying. I think this matches my intuition as well.
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.
there'd likely be a comma there:
import { foo } from 'foo.js' with type: "json",
foobar: "baz";Ahhh, you’re right.
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 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?
I don't think the question of braces vs. no braces should block Stage 2.
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.
No-braces syntax could be even more confusing. Also we already use curly braces in imports and they are not an object destructuring.
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