DEV Community

`at` coming soon to ECMAScript

Laurie on June 14, 2021

If you're a JavaScript developer you've likely used arrays quite a bit. They're an essential data structure within the language. In fact, they're ...

Read full post

The discussion has been locked. New comments can't be added.

Ryan Feigenbaum • Jun 14 '21

Would I use it?
const response = ['No way', 'I don't know', 'Awww yeah'].at(-1)

Muhammad Hasnain • Jun 15 '21 • Edited

Everybody gangsta until .at(-1) returns undefined.

Jan Küster • Jun 15 '21

Would [].at(-1) be like dividing by zero?

RaulC-G • Jun 15 '21

[].at(-1) == [][[].length - 1] == [][-1] == undefined

Junxiao Shi • Jun 15 '21

What if you need second-to-last item?
.at(-2) is as reasonable as .at(-1).

Laurie • Jun 15 '21

Yup, that works fine

Nick Taylor • Jun 14 '21 • Edited

I've used var last = arr[arr.length - 1] in the past, but now with destructuring, I typically do const [, last] = someArray.

I'm not sure I'd use at aside from getting the last item in an array since currently I can do
e.g. someArray[1] which is less typing than someArray.at(1) for elements that are not the last item. I probably would have opted for an Array.prototype.last.

Maybe there are use cases for it that I'm missing like composing a bunch of functions.

Not everyone is seeing my addendum to this comment so here it is

Nick Taylor • Jun 15 '21 • Edited on Jun 15

Just an update to my initial comment as I typed it out pretty quickly yesterday. const [, last] = someArray will work if the array was only two items. For example, if it's 4 items, this won't work. You'll end up with this.

const a = [1,2,3,4];
const [,last] = a;

console.log(last); // a === 2

If I wanted to get the last element in the above array, I'd have to do this.

const a = [1,2,3,4];
const [, , ,last] = a;

console.log(last); // a === 2

</div>

Vadym Milichev • Jun 15 '21 • Edited

This const [, last] = someArray is equal to const last = someArray[1]
To use destructuring, one might want something like
const [l, [l - 1]: last] = someArray, but it's hardly more readable 😁

Stanyslas Bres • Jun 15 '21

@milichev I get the idea from your snippet but I think the syntax is incorrect, it should look something like this :

const { length, [length - 1]: last } = [1, 2, 3, 4];
// last === 4

Anyways that's a funny thing I never thought of :)

Nick Taylor • Jun 15 '21 • Edited

const a = [1,2,3,4];
const [,last] = a;

console.log(last); // a === 2

If I wanted to get the last element in the above array, I'd have to do this.

const a = [1,2,3,4];
const [, , ,last] = a;

console.log(last); // a === 2

David Wheatley • Jun 15 '21

Oooh I knew this was possible, but never really put 2 and 2 together with that destructuring for the last item! Thanks for pointing that out to me.

Rigoberto • Jun 16 '21 • Edited

Even I propose to extend your idea and include all quick methods related to collections like LINQ (from C#) does.

Federico "Edo" Granata • Jun 15 '21

As described here it looks like .at() is barely useful to get the last item.
It's unclear if it can be used to loop through the array in reverse (eg. .at(-2)) because we could have an hard time figuring when we reach the first element and stop the loop.

Henry Ing-Simmons • Jun 15 '21 • Edited

for (let i = 1; i <= arr.length; i++) {
   console.log(arr.at(-i));
}

Federico "Edo" Granata • Jun 15 '21

So we still have to use .length like in the classic way

for (let i = arr.length - 1 ; i >= 0; i--) {
  console.log(arr[i]);
}

We just shifted the 1 from the length - 1 to the starting point
I'm struggling to see why we need .at()

BTW You should cange const to let in your example

Henry Ing-Simmons • Jun 15 '21

You're right. I never use classic for loops anymore really. Too used to writing:

for (const item of arr) {
    // ...

I agree though. Don't see the point of at. Equally if you wanted to iterate the loop in reverse:

for (const item of arr.slice().reverse()) {
   // ...

Laurie • Jun 15 '21

They gave you an example. You really don’t need to “correct” it.

Federico "Edo" Granata • Jun 15 '21

What's wrong with that? I saw that he already edited it because he used "0" as a starting point instead of "1", so I thought he would like a fix.

Laurie • Jun 15 '21

Because they're not wrong. Let is just as valid as const from the perspective of the code. Without larger context it's just a preference. And you understood the example they were kind enough to provide just fine. Your response was to make yourself feel smart.

Federico "Edo" Granata • Jun 15 '21

Maybe I'm missing somethig as english isn't my first language but using const is wrong.
Javascript prevent you from reassigning a value to a const throwing an error TypeError: Assignment to constant variable.

I was the first one asking a question because I know that I don't know everything and I want to learn so I think others can appreciate if I reciprocate

Laurie • Jun 15 '21

Yes, you could loop through in reverse. The first non-element would return undefined.

Federico "Edo" Granata • Jun 15 '21

Sadly you can't just check for an undefined element because array with "hole" like const arr = [1,,3,4]; can create a problem with that logic.

Laurie • Jun 15 '21

Yes, if you have holes then you'll need to check relative to the length of your array.

Federico "Edo" Granata • Jun 15 '21

sure or you should do as suggested here dev.to/hisuwh/comment/1fcp7
I still miss the value of .at() beside being a sugar syntax to get the last item

Andrew Bridge • Jun 16 '21

It seems like you're pretty passionate about having a last() but I don't really see the issue. at(-1) uses the same number of characters as last() so it's no more verbose, plus it has the added benefit of providing a uniform way of accessing array items from the end of the array regardless of how many positions back from the end you need it.

A multi-purpose solution seems preferable to a method that can only do one thing, no?

That aside, if people start using .at(positiveIndex), that's on them. We already have people swearing off for loops and thinking reduce is the catch all solution for everything, and I think those issues are far more detrimental to this.

Dewald Els • Jun 16 '21

What ever happend to prototypes?

Array.prototype.last = function() {
  if (this.length > 0) {
    return this[this.length-1];    
  }
  return undefined
}

const items = ['What', 'ever', 'happened', 'to', 'prototypes'];
const lastItem = items.last();
console.log(lastItem);

Laurie • Jun 14 '21

You can read more about that here: github.com/tc39/proposal-array-last

The TLDR is that at was progressing faster and solved the same problem. So last was no longer pursued.

Mike Lippert • Jun 15 '21

I see responses saying why not arr.last.
I think they are completely missing the point.

True the article used -1 as the example value to get the last element, but the point of .at() is that negative indices start at the end, so -2 is the next to last element and -3 the one before that one, etc.
I'd assume that an index of -n of an n element array would be the first element and any index less than -n is undefined.

In addition .at() lets you use the index value stored in a variable, whereas .last does not.

Denis Mitropolsky • Jun 15 '21

Honestly, I don't think getting the last is the real reason for "at"

FJones • Jun 15 '21

Well then... What is? The only benefits over indices seem to be that it throws on non-array and that you can use valid negative indices.

For negative indices, the main purpose is most definitely .at(-1), since anything dynamic still requires knowing the .length, and anything less than -1 implies a data structure that should probably be an object in the first place.
And if I want to throw on non-array, I'll just use TypeScript.

Denis Mitropolsky • Jun 16 '21

Throws on non-array seems to me a real reason for using "at". TypeScript is not everywhere yet and even it is, there's still "any".

Ashley Oliver • Jun 16 '21

You would implement a stack as an object? Trippy ...

Denis Mitropolsky • Jun 15 '21

Another point - since everything in JS is an object, everything can be indexed using square brackets, not only array objects. So "at()" provides a safe way to get an element by index from the array and prevent an error when you're accidently working with someone which is not an array.

Andrew Bridge • Jun 17 '21

Okay, fair point! Clarity is certainly an important factor in code (hence my jab at reduce!), and you are right, the whole Unix mantra is built on "do one thing well" and it seems to do okay!

I suppose at this point, just having something better than [arr.length - 1] would be a massive improvement, even if it were a little obscure. If at makes people happy over last great! My bet is now on the two specs opposing one another, then they'll both sit uselessly unadopted 🤦‍♂️

Vadym Milichev • Jun 15 '21

I wonder will it work

const getLast = Array.prototype.at(?, -1); // see https://github.com/tc39/proposal-partial-application
const last = getLast({ length: 6, 5: 'last' });

and do we really need it 🤔😆

Dewald Els • Jun 16 '21

Break the internet! haha love it! Sometimes they need to take control and make the tough decisions for the betterment of the web.

Correct me if I am wrong, but if the official name is called .last(), the code above would simply overwrite it and not cause anything to break? However, if a library also creates a similar .last function, depending on the order of code execution, it could cause some unexpected results.

Aleksandr Hovhannisyan • Jun 15 '21

Huh, TIL! I wonder why they wouldn't just extend the indexing operator to support negative indices. Seems easier than introducing a method, and now there's the question of which to use.

Ste Griffiths • Jun 15 '21

The article covers this really:

Well, as it turns out, -1 is already a valid key. Arrays are really objects with indices as keys. So arr[-1] is looking at the arr object and the value of the "-1" key, which is undefined.

There can be a "-1" key present in the object, so the behaviour for "negative indices" is already defined by the language.

Laurie • Jun 15 '21

Because it is already a valid index and would break existing code.

Aleksandr Hovhannisyan • Jun 15 '21 • Edited

This is the part that I don't get, though. If arr[-1] returns undefined, then that means one of two things:

Existing code checks to make sure indices are never negative.
Existing code checks if arr[index] is truthy (or explicitly checks if it's undefined).

Either way, I don't see it breaking existing code if arr[-1] all of a sudden starts returning the last entry of an array. If we're doing #1, the API doesn't change for us since our code explicitly prohibits negative indexing. If we're doing #2, it still doesn't change because now negative indexing doesn't return undefined (unless the last element is, literally, undefined).

I only see this being an issue for actual objects. Can't arrays override the behavior of the indexing operator? (I'm not familiar with those kinds of low-level implementation details for JavaScript, so maybe not.)

Laurie • Jun 15 '21

"Unfortunately, JS's language design makes this impossible. The [] syntax is not specific to Arrays and Strings; it applies to all objects. Referring to a value by index, like arr[1], actually just refers to the property of the object with the key "1", which is something that any object can have. So arr[-1] already "works" in today's code, but it returns the value of the "-1" property of the object, rather than returning an index counting back from the end."

github.com/tc39/proposal-relative-...

Aleksandr Hovhannisyan • Jun 15 '21

Oh, gotcha! So it would break existing code. Thanks for the reference!

Junxiao Shi • Jun 15 '21

Coming from C++, my first feeling is that .at(nonexistent) would throw exception, but apparently this isn't the case.

Thomas Werner • Jun 15 '21

I would also expect an exception to happen instead. Passing in an out of bounds index argument should be considered a misuse of the method and raise an error instead. The return result of undefined is not sufficient for detecting if the index is out of bounds, since that accessed element could be undefined.

In programming it's better to fail early, so come a crash and the time to debug, the failing line of code in the stacktrace is as close as possible to the root of the problem.

Ideally the language and API should make it harder to misuse it, but in JavaScript a lot of nonsensical things are possible that can cause hard to debug problems because cause and effect can be delayed. That forces us to come up with ways to make it stricter such as using static type checkers or switching to a different cross-compiled language altogether.

This could have been an opportunity for getting it right though 😞

Compatibility and interchangeability with the existing bracket syntax was probably not the reason behind that design decision. The at function expects an integer index argument. The official polyfill reference implementation converts non-numeric or fractional numbers to whole numbers, which is another strike in my book.

The method should simply reject non-numeric, non-integer arguments. Instead we end up with the following possibility that doesn't make sense to me either: a[1.1] !== a.at(1.1). Fractional numbers should cause a crash too. Why second-guess the programmer and try to auto-correct them based on assumptions? 🤷

Laurie • Jun 15 '21

It returns undefined

Denis Tomilin • Jun 17 '21

What is quite a disappointing fact, instead of enhancing the language quality, addressing the code issues and simplifying the development, we see the new standards popping up with additions to the language, but keeping the old issues as well. Now "at" should be used instead of "[]", it makes a lot of sense, but will anyone learn that? Will the courses in popular websites address that? Nope.

It is clear they are trying to keep the backward compatibility, but enhancing the slicing operator would be so much better to the JS, developers, and the future of the dev in general.

Brendan Mullins • Jun 15 '21

Why don't they just add support for arr[-1]. Seems like the simplest solution

Ste Griffiths • Jun 15 '21

The article covers this really:

Well, as it turns out, -1 is already a valid key. Arrays are really objects with indices as keys. So arr[-1] is looking at the arr object and the value of the "-1" key, which is undefined.

There can be a "-1" key present in the object, so the behaviour for "negative indices" is already defined by the language.

Brendan Mullins • Jun 16 '21

Why would you ever need negative indexes that have their own value? This sounds like a big in the language to me

Ste Griffiths • Jun 16 '21 • Edited

¯\(ツ)/¯ Any string is a valid key in a javascript object

Laurie • Jun 15 '21

I believe I explained that in the post. It’s already a valid key.

Brendan Mullins • Jun 16 '21

Sure, but does it make sense that -1 is a key? That actually sounds like a bug to me xD instead all negative numbers could be used as reverse indexes instead of looking for a value in the array where there really should not be any.

Isla McNeill • Jun 15 '21

Idk, maybe it's because I'm a fairly new developer but, I'm actually really excited about this. It's just one more thing I can do to make my code more readable for others.

Denis Mitropolsky • Jun 15 '21

Sure, it's considered a good writing style when you're using different ways of expressing the same thoughts. Every developer would loves that!

Christopher Borchert • Jun 16 '21

I agree, and so do a lot of people, but I think that there has been a long standing discussion about adding this feature to ECMA script and it just won't advance. It's been blocked at stage 1 for like 3 years or something...

Ivan Jeremic • Jun 16 '21

But last feels more something frameworks should do why should a language have last() I mean it is super easy to do .at(anyIndex)

Richard Schloss • Jun 15 '21

I was sorta hoping the function was going to be for the Date object too :)

Date.at([some UTC time], () => { /* do stuff */ })

AlexJoeb • Jun 15 '21

I'd love to see functionality similar to python's arr[1:] come out of this. But, this will definitely be useful!

Nicholas Omer Chiasson • Jun 15 '21

Does this work with positive out of bounds also, kind of like a modulo of the length? Say arr.length is 4 and you tried arr.at(5), does it give you arr[1]? Just curious.

Isla McNeill • Jun 15 '21 • Edited

It will give you undefined. That way you're not running yourself in circles.

Laurie • Jun 15 '21

No. Positive out of bounds is undefined.

Junxiao Shi • Jun 15 '21

Modulo is risky because you get NaN on an empty array.

rosostolato • Jun 15 '21

It will be useful if it can access not just last but also the length - k item with arr.at(-k). For example arr.at(-3). If it's just for the last one, it won't be that good.