What is so beneficial about Destructuring in ES6?

As much as I like FCC, the ES6 part is in my opinion a bit haphazardly designed.

The ES6 Destructuring Nested Objects example is as follow:

  today: { min: 72, max: 83 },
  tomorrow: { min: 73.3, max: 84.6 }

function getMaxOfTmrw(forecast) {
  "use strict";
  // change code below this line
  const maxOfTomorrow = undefined; // change this line
  // change code above this line
  return maxOfTomorrow;

console.log(getMaxOfTmrw(LOCAL_FORECAST)); // should be 84.6

I am trying to understand the core syntax of the Destructuring of the LOCAL_FORECAST

so If I am interested in the max value for tomorrow:

  1. I select the available Object on the Right hand side of the Expression
    const something = forecast
  2. I want to destructure the tomorrow key value pair so I do something:
    const {tomorrow:{....} } = forecast
  3. now I want to provide maxOfTomorrow from max
    const {tomorrow: { max: maxOfTomorrow}} = forecast

I really don’t get destructuring logic. How is all this coding mumbo-jumbo different from parsing the Object to quickly find the max of tomorrow with simple key-value pair parsing?

You can set object properties using shorthand:

const myObj = { foo: 1, bar: 2 }

Rather than doing

const myObj = new Object();
myObj.foo = 1
myObj.bar = 2

There used to be no equivalent shorthand for accessing objects, but now you can do

const { foo, bar } = myObj;

You don’t see the benefit as much until you need to access real things rather than toy examples, like for example, here’s a small response from the GitHub API:

  "login": "octocat",
  "id": 1,
  "node_id": "MDQ6VXNlcjE=",
  "avatar_url": "https://github.com/images/error/octocat_happy.gif",
  "gravatar_id": "",
  "url": "https://api.github.com/users/octocat",
  "html_url": "https://github.com/octocat",
  "followers_url": "https://api.github.com/users/octocat/followers",
  "following_url": "https://api.github.com/users/octocat/following{/other_user}",
  "gists_url": "https://api.github.com/users/octocat/gists{/gist_id}",
  "starred_url": "https://api.github.com/users/octocat/starred{/owner}{/repo}",
  "subscriptions_url": "https://api.github.com/users/octocat/subscriptions",
  "organizations_url": "https://api.github.com/users/octocat/orgs",
  "repos_url": "https://api.github.com/users/octocat/repos",
  "events_url": "https://api.github.com/users/octocat/events{/privacy}",
  "received_events_url": "https://api.github.com/users/octocat/received_events",
  "type": "User",
  "site_admin": false,
  "name": "monalisa octocat",
  "company": "GitHub",
  "blog": "https://github.com/blog",
  "location": "San Francisco",
  "email": "octocat@github.com",
  "hireable": false,
  "bio": "There once was...",
  "public_repos": 2,
  "public_gists": 1,
  "followers": 20,
  "following": 0,
  "created_at": "2008-01-14T04:33:35Z",
  "updated_at": "2008-01-14T04:33:35Z",
  "total_private_repos": 100,
  "owned_private_repos": 100,
  "private_gists": 81,
  "disk_usage": 10000,
  "collaborators": 8,
  "two_factor_authentication": true,
  "plan": {
    "name": "Medium",
    "space": 400,
    "private_repos": 20,
    "collaborators": 0

Also, it’s not really mumbo-jumbo, it’s a standard feature present in most other modern languages.

But what about Using a Typescript Class or an Interface that has the same structure as the JSON API you mentioned? Doesn’t that make sense in such scenarios?

Or just pattern match the response using destructuring? It’s much easier than writing classes and interfaces for something so trivial, and it’s orthoganal to classes/interfaces anyway

edit: this may be skewed by the languages I’m used to, but this is IMO just a basic syntactic feature of modern languages. JavaScript lacks the pattern-matching ability of most of them, so it’s less useful [at the minute] than it is in say Kotlin/Rust/Swift/any ML/C#/etc/etc, but it’s more powerful than Python’s implementation. It might not be as obviously useful coming from say languages that lack modern features (like Java or Go). It’s about intent, making it clear what the intent of the code is. JS has issues because objects can be so easily modified, so, unfortunately, the code doesn’t blow up when the match fails, which is a downside