Hacker News Reader

Comment by namuol | Hacker News Reader

If you’re reaching for structuredClone, what you really want is native immutable Record and Tuple syntax, and the companion “deep path properties” syntax which allows for efficient and ergonomic immutable updates:

- https://github.com/tc39/proposal-record-tuple

- https://github.com/tc39/proposal-deep-path-properties-for-re...

View on HN

Also, if one found their way to immutable Records and Tuples, maybe it's also time to start exploring Clojure/ClojureScript.

I dream of a world where ClojureScript became the common front end language of the web instead of JS and what that would have done for the language and ecosystem.

JS: deep copy so awesome!!

CLJS: ¯\_(ツ)_/¯

Maybe. But I think there’s room to bring more ideas from Lisps into a language at least partly inspired by Lisps.

There are other reasons for cloning objects apart from immutable updates. Might also be you just want to pass around an object reference and make sure it is not mutated later, so you use a clone.

And structuredClone was standardized to serialize objects passed between contexts.

So I don't see what's wrong with teaching people about this as the native way to clone serializable objects.

Record/Tuples are different types and I don't think that "what you really want" is a future proposal when you want a built-in now.

You’re mostly right, I should have said “what you _probably_ want” instead.

Misuse of deepClone & co is just a very common antipattern.

Yeah it is really easy to fall into a misuse of expensive object memoization with deep equality checks if you try to "do it right" in React for example, and work without an external state management library.

Or when working with libraries that demand this.

In that spirit, I find MobX pleasant to work with as an alternative.

Although it remains needed to grok reference equality checks in reactivity, there's no way around that I guess.

Fundamentally, when passing messages with structured payloads I'd consider it good style for the payload to be serializable and free from references and mutable state.

While I am extremely excited that these may someday make it into the language, I actually would be fine with `.hashCode` and `.equals` on the Object prototype.

structuredClone, if I'm not mistaken also allows cloning functions/Maps/Sets, so while there may be some overlap, I'm not sure having Records and Tuples solves the same problems. Or as nerdy engineers are so prone to say, they're "orthogonal".

> if I'm not mistaken also allows cloning functions/Maps/Sets

Map and Set yes, but not functions. Makes sense because there is no reasonable way to serialize functions in JS.

https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers...

edit: I have no idea what actually happens to cloned maps with function values or keys though...

I know Reflect[0] doesn't get alot of attention however I always thought it would be a big improvement if `Reflect.set`, `Reflect.get` and `Reflect.deleteProperty` gained support to deal with nested properties. It would effective give developers built-in JSON Path support[1] (like you see in MySQL, Postgres or SQLite databases).

As an unrelated aside, recursive proxies would also be extremely useful

[0]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

[1]: https://goessner.net/articles/JsonPath/

Instead of the "deep path properties" syntax, you might want to take the opportunity to learn about functional lenses with monocle-ts

https://gcanti.github.io/monocle-ts/

This is one of the things I hate about the JS ecosystem.

"instead of learning x, use y library" Sometimes that advise makes sense, yes. But it's constantly used in a dogmatic manner.

The hash symbol looks really out of place in js.

it may do, but it has prior use already: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

I'm not a fan of it there either. JavaScript, since its earliest days, had `private` as a reserved word. Typescript makes use of it. It conveys perfectly what the Class member's visibility should be. Using `#` might be easier on parsers, or may fix some sort of compatibility issue (I haven't read the reasoning) but it's silly.

There's a lot of reasoning for it, mostly summarized by "this.abc and this.#abc are not the same fields".

The goal of #-private properties in JS is to have total runtime isolation, so that there's no way at all to access it from the outside. If you're fine with a compile-time error, use TypeScript's private keyword instead (JS does not have a compiler).

But why can't `otherObj.abc = 3` throw an error if abc is declared as private? Because it would incur a runtime cost on all property accesses to check whether it's public or not, even if private properties aren't used anywhere within the class. Not a sacrifice anyone would be willing to make.

So, the solution is to make sure that private property accesses can be distinguished from public property accesses. You could have had something like `private.abc` instead of `this.#abc`. But I don't think that's better, either.

Honestly, you'll get used to # if you use it for a while.

This is similar to the recent post about private members in Ruby. It's a sytaxical check that the receiver is literally 'this'. Which, like you say, can be checked at parse time without any lookups. Even identity(this).privateVar doesn't pass in Ruby due to not being sytaxical this.

Reply on news.ycombinator.com