4 ms·

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

by namuol 3y ago

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-record-tuple - https://github.com/tc39/proposal-deep-path-properties-for-record https://github.com/tc39/proposal-deep-path-properties-for-re...

nlitened 3y ago
Also, if one found their way to immutable Records and Tuples, maybe it's also time to start exploring Clojure/ClojureScript.
- namuol 3y ago
  Maybe. But I think there’s room to bring more ideas from Lisps into a language at least partly inspired by Lisps.
- user3939382 3y ago
  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.
  - raspasov 3y ago
    JS: deep copy so awesome!! CLJS: ¯\_(ツ)_/¯
Tajnymag 3y ago
The hash symbol looks really out of place in js.
- meandmycode 3y ago
  it may do, but it has prior use already: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes/Private_properties https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
  - nobleach 3y ago
    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.
    - n2d4 3y ago
      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.
      - pests 3y ago
        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.
deleted 3y ago
[deleted]
nobleach 3y ago
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".
- moritzwarhier 3y ago
  > 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_API/Structured_clone_algorithm#supported_types 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...
moritzwarhier 3y ago
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.
- deleted 3y ago
  [deleted]
- namuol 3y ago
  You’re mostly right, I should have said “what you _probably_ want” instead. Misuse of deepClone & co is just a very common antipattern.
  - moritzwarhier 3y ago
    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.
no_wizard 3y ago
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/Reference/Global_Objects/Reflect https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [1]: https://goessner.net/articles/JsonPath/ https://goessner.net/articles/JsonPath/
wk_end 3y ago
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/ https://gcanti.github.io/monocle-ts/
- Akronymus 3y ago
  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.

by namuol 3y ago

nlitened 3y ago

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

namuol 3y ago
Maybe. But I think there’s room to bring more ideas from Lisps into a language at least partly inspired by Lisps.
user3939382 3y ago
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.
- raspasov 3y ago
  JS: deep copy so awesome!! CLJS: ¯\_(ツ)_/¯

Tajnymag 3y ago

The hash symbol looks really out of place in js.

meandmycode 3y ago
it may do, but it has prior use already: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes/Private_properties https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- nobleach 3y ago
  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.
  - n2d4 3y ago
    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.
    - pests 3y ago
      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.

deleted 3y ago

[deleted]

nobleach 3y ago

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".

moritzwarhier 3y ago
> 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_API/Structured_clone_algorithm#supported_types 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...

moritzwarhier 3y ago

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.

deleted 3y ago
[deleted]
namuol 3y ago
You’re mostly right, I should have said “what you _probably_ want” instead. Misuse of deepClone & co is just a very common antipattern.
- moritzwarhier 3y ago
  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.

no_wizard 3y ago

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/Reference/Global_Objects/Reflect https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [1]: https://goessner.net/articles/JsonPath/ https://goessner.net/articles/JsonPath/

wk_end 3y ago

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/ https://gcanti.github.io/monocle-ts/

Akronymus 3y ago
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.