DEV Community

Notes on ECMAScript 6 (ES6)

Scott Hardy on August 22, 2018

Introduction This is not meant to replace the official documentation. This post does not cover all the ES6 features. For typos and cor...

Read full post

Angel Daniel Munoz Gonzalez • Aug 23 '18

Great notes!
If I may add: regarding to classes you might want to try something like this if you want to accept an options like constructor

class SomeClass {
  constructor(options) {
    Object.assign(this, options);
    // if you want required properties you may want to if check here
    // and throw if required props are not present
  }

  toString() {
    return Object.entries(this)
      .map(([key, value]) => `[${key}: ${value}]`)
      .reduce((last, current) => `${last ? `${last}, ` :  ''}${current}`,'')
  }
}


const some = new SomeClass({propA: 'this is a', propB: 'this is b'});
some.toString();
//"[propA: this is a], [propB: this is b]"

of course if you are using typescript you can extend that to use an interface and ensure you only accept what is required.

Scott Hardy • Aug 28 '18

What are your thoughts on iterator as a protocol and not an interface?

Angel Daniel Munoz Gonzalez • Aug 28 '18

it is pretty useful, I think it has become better to work with collections, if you have teamates with python background, they can easily recognize [...someIterable] also it lets you do some stuff like const keys = [...Object.keys(myObj)] without for in or for each
also for people that isn't too much into functional methods like map, reduce, ans such, for of is quite a savior.

on the protocol vs interface, I think protocol is better suited in jsland where interfaces only exist on agreements (which some times not everyone agrees the same thing), not enforced in code.

Patrick Waivers • Aug 22 '18

Great write-up! What are your opinions on using const over let or var? What are the actual advantages of it (other than telling the developer that it will not change)?

Scott Hardy • Aug 22 '18 • Edited

Hey Patrick!

Thanks for the great question. I will try to answer by breaking it down first with var vs let and const

var is function scoped. let and const are block scoped. This is the biggest difference, to use the wise words of a work colleague: "let is what var should have been from the start."

That said the main difference with let vs const is that const does not allow re-declaring. This does tell a developer that it will not change as you mentioned, but more importantly, it is telling your program that it cannot change.

Some linters out there (AirBnB) will throw an error if you declare a let and never change or re-declare it, the error will be to use a const.

I hope I answered your question sufficiently.

Cheers!

flavio ⚡️🔥 • Aug 23 '18

const has a great advantage: there are less moving parts in your code.

I now default to const unless I know the variable is going to be reassigned later on.

Scott Hardy • Aug 23 '18

Patrick,

I was re-reading my post and noticed I am inconsistent with my let and const usage. I opened an issue and I am welcome to PR's

Again thank you for reading and asking a question.

Ben Halpern • Aug 22 '18

The scoping component of let seems pretty beneficial. let and const seem to remove some of the wishy-washiness of JS.

Scott Hardy • Aug 22 '18

I totally agree. Block scoping is great progress

Ian Kirker • Aug 26 '18

As someone who tries to write as little JavaScript as possible, I'm not sure I'm looking forward to infinite chains of impossible-to-debug promises any more than I currently enjoy infinite chains of impossible-to-debug callbacks.

Scott Hardy • Aug 26 '18 • Edited

Hey Ian,

Thanks for taking time to leave a comment, what part of a Promise Chain are you finding impossible to debug? Promises offer a second failed function within a then or the use of a catch to manage errors. Maybe I can help clear up some confusion.

In my opinion a promise chain is relief from callback hell.

Ian Kirker • Aug 26 '18

I've not actually tried using them yet, but my comment mostly comes from looking at that chain, imagining a longer one, and then imagining trying to work out which .then and .catch happen at which level, much like trying to work out which level of }) } } }) ) }, }; } } }) the problem is in with callback hell.

I guess it should at least be easier to add good error reporting in the .catch blocks.

Scott Hardy • Aug 26 '18

I recommend trying promises out, start by working with promises before creating them. A promise that you could work with is the fetch api for example, google has a good introduction

const getJson = res => {
    // comment out the if to return the error 
    // and see how catch works
    if(res.status !== 200) {
        return new Error(`StatusCode: ${res.status}`)
    }
    return res.json()
}
const getUrl = url => fetch(url).then(getJson)

getUrl('https://baconipsum.com/api/?type=meat-and-filler')
    .then(res => console.log(res))
    .catch(err => console.error(err.message))

kambala yashwanth • Dec 1 '18

Great post, can you change code block representation of example code to runkit.

Scott Hardy • Dec 1 '18

Hey Kambala!

I am unfamiliar with runkit. Feel free to fork the repo and submit a PR though as an example. I might be able to do this with your help. The project is open source