JavaScript Guide: Arrays #35
Conversation
|
|
||
| ### 3.6 Mapping Over Iterables | ||
|
|
||
| Use [array spread syntax][Array Literal Spread Syntax] `...` instead of [`Array.from`][Array.from] for mapping over iterables. |
There was a problem hiding this comment.
I ran a JSPerf and it seems going with the opposite of what the Airbnb Guide suggests performs better overall. I'd like your thoughts, if you have any, on this. I wanted to make sure my JSPerf tests were accurate and that I wasn't testing incorrectly.
There was a problem hiding this comment.
I tried it in Chrome 69 and Chrome 70 on Linux, which resulted in spread being more than twice as fast, and I also tried FF on Linux, where spread is almost twice as fast.
There was a problem hiding this comment.
I also created this test, which compared Array.from() and [...].map() as well as Array.from().map. https://jsperf.com/array-from-vs-spread-vs-array-from-map/1
There was a problem hiding this comment.
Nice! Thanks for the test! I think I'll add that to the docs! 👍
There was a problem hiding this comment.
Interesting. On this note, is there any thought of adding comments about native support (thinking browsers), so that we don't end up relying on Babel or polyfills to use what should be more performant, future-friendly methods, but are actually being transpiled to something less performant, at least for some clients.
I realize this is a moving target and also very much a case-by-case thing, but even links to caniuse might be helpful.
gerardo-rodriguez
changed the title
javascript/README.md
Outdated
|
|
||
| - ESLint: [array-callback-return] | ||
|
|
||
| ### 3.8 Array Line Breaks |
There was a problem hiding this comment.
It appears that the rule is that line breaks, indents, etc are driven by the individual contents of the array, not the array itself, which defaults to no formatting (i.e., inline). https://eslint.org/docs/rules/array-element-newline and related rulesets apply, but I'm not sure what the best settings are.
There was a problem hiding this comment.
Like I said in the strings PR, can we just have something like:
Code should conform to Prettier formatting
instead of concerning ourselves with individual stylistic details?
There was a problem hiding this comment.
I think you should mention prettier somewhere in the js guide, but I think it is fine if you remove that section and put the prettier note at the top or something.
Summary
This PR adds the "Arrays" section.
Use the GH UI as shown in the GIF below to view the rendered README: