Polymer({privateMethod_() { ... method body ... },});
Polymer({privateMethod_: function() { ... method body ... },});
class ClassName() {privateMethod_() { ... method body ... }}
const o = {
[prop]: 'hey',
['b' + 'ar']: 'there',
};
For method properties, it might be confusing not to allow the shorthand in object literals, given that it's allowed in class definitions.
But computed and shorthand properties are weird, IMO. I'd prefer if literals were explicit about their property names and values. If we're generating property names as in this example:
const o = {
[prop]: 'hey',
['b' + 'ar']: 'there',
};I would ask why we aren't using a Map object instead.
On Friday, January 4, 2019 at 12:28:08 PM UTC-8, Dan Beam wrote:Hey all,Often I see (either intentionally or accidentally) object literal extensions (specifically, property methods) being used in our code.Polymer({privateMethod_() { ... method body ... },});
We haven't formally discussed this (like I'm doing now), but I think we should go ahead allowing these everywhere. The alternative is this:Polymer({privateMethod_: function() { ... method body ... },});which isn't really much better (it's just longer, basically the same). Note that we also allow the class syntax, which looks similar:class ClassName() {privateMethod_() { ... method body ... }}Cross-browser support for object literal extensions seems to be there (except for property spread which doesn't work on iOS10, but that's being discussed separately):
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Object_initializer#Browser_compatibilityI also tested clang-format[1], closure compiler, and eslint: results. I don't see anything totally show-stopping; I don't think we use computed property names much and shorthand formatting weirdness seems to only happen sometimes.
Thoughts?-- Dan[1] There are a couple formatting bugs; I've filed a bug internally.
--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/2e668377-8831-4869-8db4-de3579081c84%40chromium.org.
For method properties, it might be confusing not to allow the shorthand in object literals, given that it's allowed in class definitions.But computed and shorthand properties are weird, IMO. I'd prefer if literals were explicit about their property names and values. If we're generating property names as in this example:
const o = {
[prop]: 'hey',
['b' + 'ar']: 'there',
};I would ask why we aren't using a Map object instead.
class DataStream {
[Symbol.asyncIterator]() {
return { next() { ... } }
}
};
for await (const item of new DataStream(backendUrl)) {
...
}
const myStyles = {
width:'200px',
height: '200px',
};
if (isRTL()) {
myStyles['margin-left'] = '20px';
myStyles['padding-left'] = '20px';
} else {
myStyles['padding-right'] = '20px';
myStyles['margin-right'] = '20px';
}
const paddingInlineStart = isRTL() ? 'padding-left' : 'padding-right';
const marginInlineStart = isRTL()? 'margin-left' : 'margin-right';
const myStyles = {
width: '200px',
height: '200px',
[paddingInlineStart]: '20px',
[marginInlineStart]: '20px',
};
// Throws an error saying myProperty is not defined.const myObj = { [myProperty]: 1,};
// Does not throw an error.const myProperty = 'one';const myObj = { [myProperty]: 1,};
// Throws an error saying myProperty needs to be string or symbol.const myProperty = function() {};const myObj = { [myProperty]: 1,};
--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/9de46f5f-db80-497d-9711-0f9016c440a7%40chromium.org.
This example worries me... Why not write style in, well, CSS? Why do you use JavaScript in the first place?
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev+unsubscribe@chromium.org.
This example worries me... Why not write style in, well, CSS? Why do you use JavaScript in the first place?(I have almost no experience with Polymer, is this advocated/encouraged by it? I hope not...)And we have margin-inline-start and such (or [dir=rtl]), why would you compute those in JavaScript?
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CABc02_%2B2e%2B1POk%2BTRgHft%2BGY_CYQF07bsGQ_DMiP3zvqKkY4BA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CANNW_QpUon1SwAgUUr9wJrf4obR0or3-JoFMGYFZcGB1iNkvRA%40mail.gmail.com.