from Hacker News

ES6 in Depth: Destructuring

by mnemonik on 5/28/15, 11:38 PM with 96 comments

  • by girvo on 5/29/15, 2:22 AM

    I'm currently building a rather large isomorphic React/Flux application in ES6 and ES7.

    With our Flux implementation that we're using[0], async actions to external services become amazingly simple.

      async sendRequest(payload) {
      try {
          let result = await this.api.sendRequest(payload);
          return await result;
      } catch (e) {
          if (e.name === 'ServerException') {
              this.errorActions.serverError(e);
              return null;
          }
          
          this.errorActions.genericError(e);
          return null;
      }
  }
    Having a class system on top of prototype system, removing a lot of the boilerplate is great. Browserify/CommonJS and Babel make for a phenomenal build system, and being able to with few exceptions render everything on the server correctly is brilliant.

    Javascript has come a long way. The best part of destructuring is simplifying `import` statements

      import { fooFunc } from './Bar';
    I highly recommend checking it out, as the confluence of ES6/7, Babel, React and Flux (with one way data-flow) feels like the future but here today. That, and I'm stoked that functional programming concepts are taking off!

    [0] http://acdlite.github.io/flummox

  • by bakhy on 5/29/15, 7:47 AM

    No offense meant to anyone, but I really do not like this constant stream of new features in JavaScript. There are some core issues with the language which, of course, cannot be just fixed, and no new features will make them go away. But there is also a beautiful simplicity and power in the way this (used to be) funny little language does classes, objects, scoping... I feel like these new features are bloating it, and for what? So that you can write an assignment in 1 instead of 3 lines? Wow. It's as if, whatever programming language is trendy, JavaScript must absorb as much of its features as it can...

    Don't get me wrong, destructuring is a nifty feature, but it's not really necessary. Plus, things like that usually get thought through along with everything else, when the language is designed. Not only is this increasing the conceptual weight of the language (OK, maybe I exaggerate in this example ;) but there are many more features added all the time), but now you also have a new set of potential pitfalls when doing potentially type-inappropriate destructuring. (I see from the text that you sometimes get undefined, and sometimes a TypeError?) Does JS need more of that?

    Why not keep it simple? It may have its flaws, but the JavaScript mental model, once you figure out some corner cases, is really simple and powerful. I find it sometimes very elegant. This feature bloat reduces that, IMO, and could hurt understandability of JS code.

  • by darklajid on 5/29/15, 7:31 AM

    I'm not really into web/frontend stuff. I'm interested, but it's not part of my day job and so I dabble only, play a bit here and there.

    My last experiments caused lots of browser based problems (string.prototype.contains doesn't exist in IE9 etc..) and ES6 features were a no-go for the same reason. How do you actually use things like the fat arrow etc. in applications today?

    Is that limited to server-side code for now (and for quite some time..)? Do you decide to ignore a number of ~relevant~ browsers? Build tools to generate a 'lower' dialect/subset?

    Any intro to this specific topic, i.e. 'making sure your ~modern~ code works in last years browsers'?

  • by dandelany on 5/29/15, 5:09 AM

    I've been writing ES6 with Babel for a couple of months now, and I've fallen in love with destructuring - it's my second favorite part, besides arrow functions. My only complaint, having run into this a few times in real code, is that you can only use destructuring with assignment, not with existing variables. So this works:

      let myThing = {a: 4};
  let {a} = myThing;
    But this does not:

      let a = 5;  
  let myThing = {a: 4};
  {a} = 5;
    I understand there are some problems of ambiguity here, but it seems to me this could be made to work somehow?

  • by thomasvarney723 on 5/29/15, 3:03 AM

    I recognize destructuring from Clojure. Did it origniate there? Or is this a specific case of pattern matching?

  • by itajaja on 5/29/15, 8:06 AM

    Adding to babel and traceur, Typescript is catching up with all ES6 features, so you can use destructors (discussed [here](https://github.com/Microsoft/TypeScript/issues/240)) in Typescript v1.5--beta

  • by crousto on 5/29/15, 10:32 AM

    I love it!

    As someone else also mentioned in the comments, it is unapologetically dynamic. In many ways, this reminds me of Perl. The array destructuring assignment is such a common pattern in that language (eg. http://perldoc.perl.org/functions/caller.html)

    What's even more exciting/terrifying is that ES6 goes even beyond the patterns allowed in Perl!

  • by istvan__ on 5/29/15, 2:59 AM

    I think this is a great language feature, using it a lot in OCaml and Clojure. I am not sure how much this will improve JS but I guess we can just wait and see.

  • by ffn on 5/29/15, 12:32 AM

    var [wtf] = NaN; console.log(wtf); // undefined

    I don't know about you, but this sensibly gives a TypeError when I did it in my console on Firefox 38. Please let this article be more dated than my firefox browser, because making NaN auto-coerce into an iterator sounds incredibly stupid.

  • by Ono-Sendai on 5/29/15, 1:17 AM

    Wow, that's some pretty complicated stuff. I can only imagine the monstrous code that could be written using this.

  • by gcb0 on 5/28/15, 11:48 PM

    that's awful syntax IMHO.

    like php's list/map but with several levels.

    those are just asking for bugs that are hard to spot even on code reviews.

  • by z3t4 on 5/29/15, 6:30 AM

    I fail to see this doing anything besides turning the syntax backwards!? Maybe it's useful for those of us who are used to write from right to left, like in Arabic, but I would still use var foo = bar[0] over var[foo] = bar any day. It gets even stupider with objects: var foo = bar.a, vs, var {a: foo} = bar.

    JavaScript is a good language because it's so simple and easy to learn, adding stuff like destructor's just make it more confusing! Making a language more confusing just because of strong preference with syntactic sugars is a mistake. I would like to see a forking of the language before this goes mainstream. Maybe called CJS, where C stands for Clean or Classic JavaScript.

  • by ilaksh on 5/29/15, 1:01 PM

    The part of this that is disengenuous and a little silly is that they are just slowly adding in features from CoffeeScript/IcedCoffeeScript and nobody mentions that.

    And in order to do it you have to use something like Babel.

    Why not just move to CoffeeScript, or IcedCoffeeScript, or ToffeeScript, or even LiveScript?

    The only explanation I can see is that people just aren't capable of learning the full new languages and so the standards people are leading you by the hand like you just got off the short bus.

    AND, the standards people don't want to admit that individuals did their jobs for them years ago, don't want to use someone else's design for implementing those features and so insist on slowly coming up with their own independent implementations for engines.

    This is a microcosm that demonstrates the relationship between technology and society. There is just a huge lag between the newest and best ideas or systems and what the group or individuals or systems can grasp or absorb.

    Take this existing many-year gap and multiply by 10X or 100X and you will start to perhaps understand the concept of the technological singularity.