[HN Gopher] Overzealous Destructuring
___________________________________________________________________
Overzealous Destructuring
Author : bentobean
Score : 45 points
Date : 2022-10-07 18:48 UTC (4 hours ago)
(HTM) web link (www.aleksandrhovhannisyan.com)
(TXT) w3m dump (www.aleksandrhovhannisyan.com)
| [deleted]
| ramesh31 wrote:
| Nah. Destructure all the things. The alternative is writing
| unsafe code or using a library in place of standard language
| features.
| klyrs wrote:
| That's funny, a good portion of the article is about the
| unsafety of destructuring...
| fredrikholm wrote:
| Jesus that loaded quickly. Hats off to the author for creating
| such a snappy site.
| [deleted]
| danielvaughn wrote:
| I probably wouldn't have even noticed had you not said
| anything. But yeah you're right, that was instant. Very nice
| work.
| Arrath wrote:
| I'm almost taken aback at how quick that loaded. It reminds me
| of finally upgrading from dialup.
|
| The modern web experience really is subpar.
| RedShift1 wrote:
| A quick look at the network tab in the dev tools: the page is
| less than 10 KB (fits in TCP fast start window), little
| external resources (10 in total: 1 HTML, 1 CSS, 4 fonts, 2
| images and 2 JS files), tiny amount of JS code which doesn't
| add extra requests, all served by Google's CDN which probably
| has a mirror geographically close to you.
| username_exists wrote:
| I definitely get the point. I often have the urge to use
| destructuring for saving space, but want to kick myself when
| revisiting the code a month or two later. I like your rules,
| thanks for sharing.
| moogly wrote:
| I definitely agree with the spirit of the article: you can take
| this too far.
|
| The real benefit of destructuring isn't really brevity, per se,
| IMO, but easy extensibility. You all of a sudden need two or
| three properties from the same object at the same level? You
| just reference the additional properties on the left side
| without any fuss.
| myhf wrote:
| the curly braces in that font are TOO CURLY
| bluepnume wrote:
| > it's important to remember that TypeScript does not provide any
| assurances about a variable's runtime type, especially if the
| data is coming from an external source (like an API). In those
| cases, you often need to use type assertions or guards anyway to
| assert the returned type because TypeScript can't infer the type
| of dynamically fetched data. So destructuring the data is more
| dangerous than defensive coding (like using the optional chaining
| operator or good-old if statements).
|
| Optional chaining or null checks should not be used
| "defensively". They should just be used whenever TypeScript tells
| you to. Otherwise you just exacerbate the problem and end up with
| more unanticipated null values.
|
| If you're dealing with an API with untrustworthy types or lots of
| null values, the solution is to:
|
| a) Write mostly optional type definitions for that API, and/or
|
| b) Use zod to verify the API data before you use it, to make sure
| it matches your expectations.
|
| https://github.com/colinhacks/zod
| capableweb wrote:
| If you're like me (and many others) and can't get enough of
| destructuring, Clojure has it on steroids compared to JS and is
| everywhere in a normal/average Clojure codebase:
| https://clojure.org/guides/destructuring
|
| Destructuring in Clojure doesn't suffer from the same problems as
| JavaScript, so lot of the things in the article doesn't apply. I
| was always slightly disappointed when destructuring finally came
| to JavaScript but it was so neutered compared to what it could
| have been.
|
| But on the other hand, I'm happy JavaScript is not becoming more
| complicated just for the sake of new features. But on the other
| foot, we already got `class` and a bunch of other complicated,
| syntactic sugar, so why not another?
| __ryan__ wrote:
| I'm not super familiar with Clojure, but I tried to read
| through the link you shared. I certainly could be missing
| something, what can Clojure's destructuring do that JavaScript
| cannot?
| joshlemer wrote:
| I'm not sure what are all the differences but one I have come
| across that you can't do in JS is to simultaneously
| destructure an object/array, and at the same time bind a name
| to the entire object/array. For instance here in Clojure we
| can extract the a,b,c keys from the passed map, and at the
| same time bind the whole map to the variable bar.
| (defn foo [{:keys [a b c] :as bar}] [bar a b c])
| (foo {:a 1 :b 2 :c 3}) ;; => [{:a 1, :b 2, :c 3} 1 2 3]
|
| in JS you can do const f = ({a,b,c}) =>
| [???, a, b, c]
|
| but how do you bind to the whole object as well?
| joshlemer wrote:
| Oh I thought of an other one. In Clojure "objects" are
| actually maps, which can have non-string keys as well. That
| means you can destructure maps which have non-string (or,
| technically, keyword) keys as well: (defn
| foo [{a 1 b 2 :as bar}] [bar
| a b]) (foo {1 "hi" 2 "world" 3 "!"}) ;; => [{1
| "hi", 2 "world", 3 "!"} "hi" "world"]
|
| In JS of course you can have Maps with non-string keys, but
| destructuring doesn't work on them. Plus you have other
| issues like arrays in JS having equality defined by
| reference rather than value, making maps less useful
| overall.
| [deleted]
| jakub_g wrote:
| Semi-related: "there-must-be-an-eslint-rule"-fetishism.
|
| Some developers seemingly can't live in a world where certain
| constructs can be used sometimes in the code, and others at other
| times, depending what is more appropriate in a given context. If
| they think construct B is superior over A, they will put in place
| an eslint rule that forbids A and always forces you to use B.
|
| In some cases it happens that B is clearly superior because A is
| known to be broken for reasons x,y,z, then I'm okay with this.
|
| But sometimes those kind of rules are taken out of nowhere for no
| good reason, just a personal preference, or with a fake reason
| like this blog shows (certain construct is only better at certain
| times, but not always).
| dexwiz wrote:
| Ugh tell me about it. My large enterprise company has been
| piling these on lately. You also get blocked from checking in
| any ignore eslint statements unless you ask some review board
| that meets once a week with a month long waiting list. I know
| all jobs are balance of productivity and bookkeeping, but all
| these CI checks are really starting to make me consider
| switching jobs.
| hinkley wrote:
| I got a lot more relaxed about hard and fast rules around the
| same time I really started having some success growing plants.
| I couldn't tell you which order it happened in. Organic systems
| can't be controlled, they can only be guided. And at the end of
| the day, while the software itself is inorganic, it is and
| continues to be created by a bunch of meat sacks, flapping
| their meat at each other to communicate. If you have an
| evolving system created by organic creatures, it is going to
| behave organically itself.
|
| I will say it's a little weird the ways in which some people
| think they've found a 'gotcha' and instead what's happened is
| that they're thinking 3 moves ahead and you're thinking 6.
| deckard1 wrote:
| been there. Worst offender I've seen is an eslint rule that
| forces you to not mutate the object you're creating with
| reduce() because mutation is bad. So now you're doing object
| spreading and went from an O(n) algorithm to an O(n^2)
| algorithm. Wonderful.
|
| There is a lot of unquestioned dogma going around in this
| industry.
| cercatrova wrote:
| Why not just use a for loop?
| LAC-Tech wrote:
| is that an airbnb eslint rule?
|
| no wonder their website is so slow!
| jvalencia wrote:
| lol, and then you add an exception for spreading: /* eslint-
| disable react/jsx-props-no-spreading */
___________________________________________________________________
(page generated 2022-10-07 23:00 UTC)