DEV Community

How to create range in Javascript

YCM Jason on January 05, 2018

range is a function that basically takes in a starting index and ending index then return a list of all integers from start to end. The most obvio...

Read full post

Namir • Jan 6 '18 • Edited

I like this way:

const range = (start, end) => {
    const length = end - start;
    return Array.from({ length }, (_, i) => start + i);
}

As array from works with arrayLike structures and receives a second optional argument mapFn, it's a nice candidate to build range.

John • Apr 25 '19

Yes, excellent solution.

This, slimmed down, version also works...

const range = (start, end, length = end - start) =>
  Array.from({ length }, (_, i) => start + i)

Matt • Jan 9 '20

Almost.

Try:

const range = (start, end, length = end - start + 1) =>
  Array.from({ length }, (_, i) => start + i)

> range(0,2)
[ 0, 1, 2 ]

Adam Catalfano • Feb 8 '22

as satisfying as this is, you're exposing a third argument that anyone can override. In a modern tech stack, this code is hesitantly admissible only if you can guarantee that absolutely no one can set length to be anything but end - start, otherwise you need to invest in a much more complex testing framework, likely outweighing the expense of adding a second line to this function.

kerafyrm02 • May 5 '19 • Edited

const range = (start, end) => Array.from({length: end}, (_, i) => start + 1);

John • May 5 '19

Sorry kerafyrm02, but that does not produce a range.

If I run range with range(1,50) I get [2,2,2,2,2,2,2,2,...]

const range = (start, end) => Array.from({length: end}, (_, i) => start + 1);

console.log(range(0,20))

kerafyrm02 • May 5 '19 • Edited

let r = (s, e) => Array.from('x'.repeat(e - s), (_, i) => s + i);

Ok here ya go... even shorter. :D

John • May 5 '19

Rock, paper, scissors... 68 chars, you've nailed it!

kerafyrm02 • May 5 '19

lol., made range to r.. so even shorter :D

John • May 5 '19 • Edited

Trust me to bump into a js golfer.

Next you'll be telling me that you're dropping the let keyword and just leaving r on the global object!!

YCM Jason • May 6 '19

haha! nice solution John!

John • May 6 '19

Well, thank you so much for saying!

rionse09 • Sep 26 '23 • Edited

Hi All, I'm trying to grasp this function:

const range = (start, end) => {
    const length = end - start;
    return Array.from({ length }, (_, i) => start + i);
}

But I still confused on why does passing { length } as first argument in Array.from is work to create new array with specific length.

Because what I read in the documentation about Array.from is only works for iterable or array like object.

Any explanation or help would be appreciate a lot. Thank you.

Jordan Clemens • May 28 '22

This is how I went about creating a different solution although it is only really beneficial by calling (value in target) and really only counts as a "typeof range" :) Just bored and playing around with proxies.

console.log(...generateRange());

let range = {
    start: 1,
    end: 10,
};

range = new Proxy(range, {
    has(target: typeof range, prop: string | symbol | number) {
        if (typeof prop === 'number') {
            return prop >= target.start && prop <= target.end;
        } else {
            return Number(prop) >= target.start && Number(prop) <= target.end;
        }
    },
});

console.log(5 in range);
console.log(50 in range);

Perry Donham • Jan 5 '18 • Edited

If you're going to use => might as well go all in... (line break for readability on dev.to)

const range = (start, end) => new Array(end - start + 1) .fill(undefined).map((_, i) => i + start)

YCM Jason • Jan 5 '18

I am quite against writing all functions as arrow functions. The reason being that arrow functions are not bind-able and it refers to the this from the outer scope. I feel that it is designed to prevent us writing var self = this; and refer to self in a callback function. So I tend to write arrow functions only when it is a callback or when it is a one-off function. Also if we use arrow function instead of proper function declaration in this case, we will lose the advantage which function hoisting provides. This means range might not be accessible by some earlier parts of our code. But it is all down to personal preference, do tell me what you think.

Perry Donham • Jan 5 '18

I don't like ambiguity in code. When I'm reviewing code and have to stop and figure out what this is referring to, it makes me frown; with arrow functions I always know exactly what this is. The 'swap this and that' pattern in JS always struck me as a hack. One of the big wins of arrow functions is eliminating the this ambiguity.

I have a similar feeling for hoisting. I understand why it is part of the language, but it always feels like a path to ruin when I have to rely on some behind-the-scenes reshuffling by the interpreter to get my code to run.

All that said, you are correct that there are situations in which arrow functions are not appropriate, which also make me crazy. Having two ways to write functions just adds confusion. "We recommend using arrow functions everyhwere. Oh, sorry, was that a constructor? Write that one this way instead..."

I can't wait to start seeing code in review that's built with templated classes. Maybe ES7 will introduce header files...

YCM Jason • Jan 5 '18 • Edited

Haha! I totally understand what you mean. But still since ES6 introduces class we should really move away from using function as a constructor. As soon as it is consistent in a team then it's fine.

Perry Donham • Jan 5 '18 • Edited

Also, I'm a big fan of using variable names that describe what they are (even for internal functions), so (line break for readability on dev.to)
const range = (start, end) => new Array(end - start + 1) .fill(undefined).map((value, index) => index + start)

YCM Jason • Jan 5 '18

On the other hand, I am a big fan of Haskell. And we tend to use _ to refer to variables which we don't use in the function. But I do agree with you that having meaningful names is a good practice and could help readability.

Perry Donham • Jan 5 '18 • Edited

Even in Haskell, _ is a bad idea :⁾ Think about the poor intern trying to learn the language while debugging your code. (And it isn't just Haskell...I did a lot of Perl back in the day, which at it best can look like line noise).

BTW since you are a fan of Haskell, I ran across this article the other day that you might enjoy, describing how to structure JS function with Haskell-styl currying.

Rick Ellis • Jun 4 '19 • Edited

I liked your recursive generator. How about something like this:

Number.prototype.to = function* (end) {
  const start = this;
  const step = end > start ? 1 : -1;
  const fn = function* (n) {
    let next = start + step * n;
    yield next;
    if (next === end) return;
    yield* fn(n + 1);
  };
  yield start;
  yield* fn(1);   
}

const asc = [...(1).to(5)];
const dsc = [...(5).to(1)];

console.log(asc); // [1, 2, 3, 4, 5]
console.log(dsc); // [5, 4, 3, 2, 1]

Sammy Taylor • Aug 2 '21

This is great, I wish this would make its way into the spec.

YCM Jason • Jun 4 '19

Haha! I like this idea!

Ighor Jesse • May 26 '19 • Edited

This is an Awesome string of code you've written. I'm partial to Python3 behavior of range though. Made a few minor adjustments yours. Better to steal like an artist then build from scratch.

function* range(start=0, end=undefined, step=1) {    
    if( arguments.length === 1) {end = start, start = 0}    

    [...arguments].forEach(arg => {    
        if( typeof arg !== 'number') {throw new TypeError("Invalid argument")}                               
    })    
    if( arguments.length === 0) {throw new TypeError("range requires at least 1 argument, got 0")}    

    if(start >= end) return                                                                                                                                     
    yield start    
    yield* range(parseInt(start + step), end, step)    
}

// Use Cases
console.log([...range(5)])

console.log([...range(2, 5)])

console.log([...range(2, 5, 2)])

Josef Richter • Jul 28 '20

The recursive one is really nice. Can be shortened to:

const range = (s, e) => e > s ? [s, ...range(s + 1, e)] : [s];

Also this is another approach, + easier to handle descending sequences too:

const range = (s,e) => e > s ? Array(e - s + 1).fill(0).map((x, y) => y + s) : Array(s - e + 1).fill(0).map((x, y) => - y + s);

Daniel Boll • Oct 1 '20

I'm a little late for the discussion 😅 but I found the different ways interesting, I ended up getting this one. Is it valid?

const range = (start, end, length = end - start + 1) => [...Array(length).keys()].map(d => d + start)

YCM Jason • Oct 1 '20

Looks great to me!

John Lynch • Dec 8 '18

I just use a one-liner recursive arrow function in ES6; note, it doesn't check but you should only pass it integers else it will never get to a == b so it will blow the stack!



let range = (a, b) => a>b ? range(b, a).reverse() : (a==b ? [a] : range(a, b-1).concat(b));

Comment marked as low quality/non-constructive by the community. View Code of Conduct

YCM Jason • Dec 8 '18

Are you actually using this in production code? 😂😂

You realise how inefficient this is right? 😂😂

YCM Jason • Dec 8 '18

I have adapted Namir's method (see comments). And it is probably the most efficient.

David Chase • Mar 20 '19

Why not get really wild and crazy :P ?

1st define a unfoldr

const unfoldr = (f, seed, xs = [], next = f(seed)) =>
   next ? unfoldr(f, next[1], xs.concat(next[0])) : xs

then define a range in terms of unfold

const range = (from, to) =>
   unfoldr(seed => seed > to ? false : [seed, seed + 1], from)

excellent article btw, keep them coming :)

George Mihailov • Oct 27 '20

Why nobody is wondering why this is not part of the standard library?

php.net/manual/en/function.range.php
ruby-doc.org/core-2.5.1/Range.html
docs.python.org/3.3/library/stdtyp...

John • Apr 24 '19 • Edited

It rather depends, Jason, on what you mean by cooler.

If you only needed range to handle approx. 6000 iterations then I think a recursive range function is pretty cool, but slow:

const range = (s,e) => (s === e) ? [s] : [s, ...range(s+1,e)]

But, if you need a much bigger range and fast executuion then do something like this:

const range = (s=0,e=10,r=[]) =>
  {while(e >= s){ r.push(s); (e>=s)? s++ : s--; } return r }

And if you don't like the arrow function, then it's easy to convert to a standard es5 style function.

Step Chud • Jan 5 '18

Might be inefficient to create an array for large ranges, and only supports range of integers (no dates). Have you seen Ruby's Range class? ruby-doc.org/core-2.2.0/Range.html
You could still implement toArray() and offer a covers() function.

YCM Jason • Jan 5 '18

Yes! You are right! I will add a generator implementation as well which should solve this problem! ;D

Step Chud • Jan 6 '18

I'd like to see the generator implementation!

YCM Jason • Jan 6 '18

What do you think about it? I have implemented.

Bryan Ryan • Oct 18 '19

The for loop is by far the easiest to read and also by far the most efficient. Your last example was literally more than 15 times slower than the for loop. Far too many developers these days are trying to get all fancy when the simple solution is much better.

Micah Dameron • Oct 26 '19

Thanks for this article. I find your first answer to be the most intuitive, and it works great for my situation.

function loopASequenceAgain(start, end) {
  // create a loop which loops from start to end
  var ans = [];
  for (let i = start; i <= end; i++) {
  // log current value to console
      console.log(i); 
      ans.push(i);
  }
  return ans;
}

Big-Zude • Aug 14 '21

After reading through this helpful discussion this what I came up with, I added a condition if the start point of the range is greater than the end point. This my very first contribution

function range(s, e) {
  var arr = [];
  for (let i = s; i <= e; i++) {
      arr.push(i);
  }
  return  s > e ? Array(s - e + 1).fill(0).map((x, y) => - y + s):arr;
}
console.log(range(10,1)

Oros Alexandru • Apr 28 '22

function range(start: number, end: number, step = 1) {
  return {
    [Symbol.iterator]() {
      return this;
    },
    next() {
      if (start < end) {
        start = start + step;
        return {done: false, value: start - step}
      }
      return {done: true, value: end}
    }
  }
}

Jeudi Prando • Apr 9 '20 • Edited

/// declaration
(s,e)=>[...Array(e-s+1)].map((_,i)=>s+i)
/// use
((s,e)=>[...Array(e-s+1)].map((_,i)=>s+i))(5,9)
/// output
[5, 6, 7, 8, 9]

😉🤩✨✨✨

keith p. jolley • Mar 3 '21

☝️ is what i was looking for. tweaked it slightly:

((e, s=0, d=1)=>[...Array(e-s)].map((_,i)=>(s+i)*d))(5,0,1/4)
[0, 0.25, 0.5, 0.75, 1]

Dave Furfero • Oct 13 '22 • Edited

let's go both ways!

function range(start, end) {
  const sign = start > end ? -1 : 1;
  return Array.from(
    { length: Math.abs(end - start) + 1 },
    (_, i) => start + i * sign
  );
}

YCM Jason • Nov 1 '22

oooooo maybe with Math.sign?

Nassehk • Feb 11 '23

Python world has experimented with creating the whole array vs generator. They landed on the generator. In Python 2 they have range for whole array and xrange for generator. In python 3 they dropped the array all together and use range function to return a generator.

QJ Li • Jul 5 '19

function range(start, end) {
  return [...Array((end - start) + 1).keys()].map(val => val + start);
}

Petr Odut • Nov 11 '19

Or one-liner:

const range = (start, end) => [...Array(end - start + 1)].map((_, i) => start + i)

AyobamiMichael • Aug 10 '21

Thanks bro, it was helpful.

Oscar Andrés Russi Porras • Oct 29 '20

Like this:
[...Array().keys()];
this way you get the range from 0 til -1

Abdullah Shafiq • Jul 27 '19

I think this code is not going to work with float values. like generating a range like [0.01, 0.02, 0.03 ...]

Perry Donham • Jan 6 '18

Jason, just curious, what's your concern about looping? I don't have a reference, but I would think that the various interpreters (especially V8) would optimize / unroll them.