30-seconds-of-code: [SUGGESTION] Array initializing

[kingdavidmartins]

[SUGGESTION] Array Initializing

Description

I believe we should decide how we want to initialize arr's in this project

When going through the snippets I realized that

I think its important for the following reasons: consistency, readability, performance, and modernity

Early on in the project we decided to stray from
Array.apply(null, {length: n}) for Array.from({ length: n})

Now there's quite a few of snippets initializing arr's like so.

Array(n) & Array.from({ length: n})

Just wanted to make sure I knew which is preferred in the future when implementing/updating other array type methods/snippets & the reasoning behind which we do so choose

Example

initializeArrayWithValues

const initializeArrayWithValues = (n, value = 0) => Array(n).fill(value);
// initializeArrayWithValues(5, 2) -> [2,2,2,2,2]

initializeArrayWithRange

const initializeArrayWithRange = (end, start = 0) =>
  Array.from({ length: end - start }).map((v, i) => i + start);
// initializeArrayWithRange(5) -> [0,1,2,3,4]

Thoughts? @atomiks @skatcat31 @fejes713 @Chalarangelo

[skatcat31]

I think we need to avoid Array(n) due to the over laoded nature of it unless we want to enforce type casting

Array('string')
Array(8)
Array([1,2,3])
Array(NaN)

Granted that's not to say .from({}) is any better

Array.from({length: NaN})
Array.from({length: []})
Array.from({length: [1]})
Array.from({length: [1,2]})
Array.from({length: 2})
Array.from({length: '2'})
Array.from({length: 'two'})

Then of course there's

var a = [], a.length = 4
a = [], a.length = NaN
a = [], a.length = 'asd'

So you're right in that we need to decide which way to go

[Chalarangelo]

Array(n) seems cleaner and more readable to me than Array.from(), except in certain cases. I vote for Array(n), but that's my own personal preference. Please comment below to make a decision and retroactively update all snippets and guidelines.

[kingdavidmartins]

Hey Everyone 👋

I think we need to avoid Array(n) due to the over loaded nature

Array(n)

I have to agree with @skatcat31 I honestly think we need to avoid Array(n) for 2 reasons

Reason 1

We need to use Array(n) in conjunction with Array.fill() because you can't iterate over Array(n)

Array(1) // -> [ <1 empty items> ]
Array(1).fill() // -> [ undefined ]

Reason 2

Since we are essential relying on 2 different methods to initialize an array we have to deal with their both potential pit falls

Array(NaN).fill() // ->  With .fill() Err Thrown &  Without Fill() ->  Err Thrown
Array([]).fill() // -> With .fill() [ undefined ] & Without Fill() -> 1x1 Matrix Initialized
Array([1,2]).fill() // -> With .fill() [ undefined ] & Without Fill() -> 1x1 Matrix Initialized
Array('two').fill() // -> With .fill() [ undefined ] & Without Fill() ->  [ 'two' ]
Array('string' * 23).fill() // -> With .fill() Err Thrown & Without Fill() ->  Err Thrown
Array('err').fill() // -> With .fill() [ undefined ] & Without Fill() ->  [ 'err' ]


Array(2).fill() // -> [ undefined, undefined ]
Array('2').fill() // -> [ undefined ]
Array([1]).fill() // -> [ undefined ]


Array(2).fill().map(v => 'simple' ) // -> [ 'simple', 'simple' ]

Array.from({length: n})

I honestly believe Array.from({ length: n}) is more robust and protect both the users/collaborators from error prone headaches since the length object is only looking for a valid number which if true returns its corresponding length and in the event that it's not an valid number an array is initialized with a length of zero -> []

Example

Array.from({length: NaN}) // -> []
Array.from({length: []}) // -> []
Array.from({length: [1,2]}) // -> []
Array.from({length: 'two'}) // -> []
Array.from({length: 'string' * 23}) // -> []
Array.from({length: 'err'}) // -> []


Array.from({length: 2}) // -> [ undefined, undefined ]
Array.from({length: '2'}) // -> [ undefined, undefined ]
Array.from({length: [1]}) // -> [ undefined ]


Array.from({length: '2'}).map(v => 'simple' ) // -> [ 'simple', 'simple' ]

As you can see Array.from({length: n }) is much more consistent in it's behavior

[Chalarangelo]

@kingdavidmartins Compeling argument, let's get on that, then! Whoever can retroactively update existing snippets (some or all), please feel free to submit a PR and reference the issue so we can resolve and close. Also remind me to update the guidelines, because I will most likely forget.

[kingdavidmartins]

@Chalarangelo I will get on this right away 😄

[Chalarangelo]

Resolved in #288.

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for any follow-up tasks.