TC39 Delegates
2023-04-07
plaintext logs
prev next
source on github
13:07
<Francisco Tolmasky>
Has there been any discussion around "nullish coallescing destructuring", that is, making something like function a ({ x = 10 }) { } "just work" for the a() case and having x just be set to 10 instead of throwing? Perhaps using syntax like function a({ x ?= 10 }) { } or something?
14:25
<rbuckton-pto>
While not as efficient, you can already do function a ({ x = 10 } = {}) { }
14:35
<Justin Ridgewell>
There were a few discussions in the Optional Chaining proposal: https://github.com/search?q=repo%3Atc39%2Fproposal-optional-chaining+destructuring&type=issues
17:09
<TabAtkins>
Yeah the = {} trick works for top-level, but it's more annoying if you want to destructure deeper into the object; you've got to supply more dummy objects for each path you take.
17:45
<Francisco Tolmasky>
Right, the concern is when it starts to nest pretty deep
18:51
<Justin Ridgewell>
Oh, there was also https://github.com/tc39/agendas/pull/1122, but it was never presented
18:54
<Chris de Almeida>
https://twitter.com/TheJoin95/status/1644387103105482753 speaking of...
19:00
<bakkot>
I feel like doing very deep destructuring all in one go is generally less clear than splitting it up, so I'm not sure I would want to add syntax which is mostly useful for very deep destructuring
19:01
<Chris de Almeida>

well.. could simplify the example:

const state = {
  profileMenu: null
}

const {
  profileMenu: {
    username: ProfileMenuUsername
  }
} = state;
19:03
<ljharb>
const { username: ProfileMenuUsername } = {} = state?.profileMenu; ?
19:05
<Chris de Almeida>
const { username: ProfileMenuUsername } = {} = state?.profileMenu; ?
Cannot read properties of null (reading 'username')
19:05
<ljharb>
const { username: ProfileMenuUsername } = state?.profileMenu ?? {}; then :-p
19:07
<Chris de Almeida>
well that gives you a diff obj 🤷
20:46
<ljharb>
the only thing you care about is ProfileMenuUsername, and it gives you undefined in this case
21:10
<Chris de Almeida>
fair. that was just a reduction of the ackchyual example in the repo. I can't speak to what they care about or not wrt the deep obj destructuring there. anyway, to my eyes, seems like it's just one tiny requirement away from needing refactoring -- seems like fragile serialization
21:21
<ljharb>
true. what's fragile is having deeply nested data structures that can have nulls in it. outside of graphql tho i don't think that's super common.