What does HackerNews think of proposal-record-tuple?

ECMAScript proposal for the Record and Tuple value types. | Stage 2: it will change!

Language: HTML

#7 in JavaScript
I hope Records & Tuples[0] land before this does. It would have meaningful and far reaching positive effects for the language, without much controversy. Like most of these things, it takes about 5-7 years for it to permeate through enough of the engines to be meaningfully useful in the day to day of web developers (node / deno typically 12-18 months tops). It would drastically speed up existing code once wide adoption is gained though.

I don't think the Pipe Operator would be as useful in comparison.

I really hate how long the Records & Tuple proposal has been languishing at stage 2. It could've shipped years ago if not for a syntax debate that dragged on and on without being fruitful[1]

EDIT: there is a class based version of this, that is stage one, for adding structs[2]. They behave similarly.

[0]: https://github.com/tc39/proposal-record-tuple

[1]: https://github.com/tc39/proposal-record-tuple/issues/10

[2]: https://github.com/tc39/proposal-structs

For JavaScript, there's an active proposal to add deeply immutable objects and arrays: records and tuples. [0]

[0]: https://github.com/tc39/proposal-record-tuple/

There's a JavaScript stage-2 proposal for records and tuples: https://github.com/tc39/proposal-record-tuple
One funny thing about React is that the most dangerous kind of developer is the one with middle-level knowledge of it

beginners don't know enough to do optimisation seniors know enough that they only optimise what is needed mid-level are capable of build code that needs to be optimised, but they tend to over-optimise and often do the optimisation wrong

for example what a mid-level might do:

const C1 = React.memo(({values}) => {...}) const C2 = () => { return }

That React.memo is useless because arrays and objects are mutable in JS It also reveals a flaw in JS/React in that memoization often needs to happen at the parent instead of the child, creating awkward code and implicit behaviour and implicit performance traps when forgetting to memoize object/array props that the child expect to be memoized. The child decides which props should be memoized, but doesn't enforce it and no amount of typescript will catch that problem

Fortunately there is a proposal that will fix this problem by introducing records and tuples like python (immutable objects/arrays) https://github.com/tc39/proposal-record-tuple but it still seems far off to being usable as I don't think it will be viable to polyfill it for browsers that don't support it

> immediate data structures

Immutable?

But React in JS is a blessing – it brought good thinking to messy world. And as a direct influence, JS will adopt immutable data structures – tuples and records.

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

If the Record & Tuple proposal advances to stage 3 we'll finally have native immutable data structures in JS [1].

[1] https://github.com/tc39/proposal-record-tuple

Nahhhh lets get the immutable data structures (record + tuples) proposal to land, this one is of much more value IMO

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

Sorry for the "+1" chain but I want to express my agreement as well.

Especially when I compare it to Svelte and Vue (not solid, solid.js is just... good), if I look at a component, with react it's way easier to say what's going to happen.

Aren't there gotchas? Yes, but sometimes it's just stuff JS lacks, and so does React.

I'm very excited about Records and Tuples in JS to help with the immutability, for example: https://github.com/tc39/proposal-record-tuple

> What would happen if the view functions in elm by default were lazy?

`lazy` incurs a performance penalty not in memory but in execution steps, due to having to do a deep-equality comparison on the prev/next view inputs in the underlying JS. Enabling such a check globally would, on balance, slow everything down. Only if the work of running the view exceeds that small penalty, would you want to use it strategically here and there, hence the reason it's opt-in.

Even if the Records and Tuples proposal[1] lands and Elm gets refactored to use it internally, thus allowing `===` comparisons in the underlying JS instead of deep-equality, it's unclear whether enabling it globally would be good or bad, simply because the JS engine itself would presumably still be doing some kind of deep-equality check behind that innocuous-looking `===` operator. When the time comes I'll be curious to see if there's any progress on that front.

[1] https://github.com/tc39/proposal-record-tuple

Immutability is the whole point of records and tuples. You can read more about them on the proposal: https://github.com/tc39/proposal-record-tuple.
Record and Tuple are actively being worked on: https://github.com/tc39/proposal-record-tuple -- currently Stage 2.
Immutable data structures are on the agenda over in https://github.com/tc39/proposal-record-tuple and I would vote for that in Deno while I have the chance.
There's a proposal for immutable records and tuples: https://github.com/tc39/proposal-record-tuple

Theoretically they would use structural sharing for their implementation which should reduce the overhead of creating a whole new array of objects like that

Tuples and records are proposed immutable data structures and currently in stage 2[1] (same as the pipe operator).

[1] https://github.com/tc39/proposal-record-tuple

Is is with immutable constructs (record and tuple [0]) for example. Current FP story in ts/flow is surprisingly good.

[0] https://github.com/tc39/proposal-record-tuple

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

Only stage 2, so whether it'll get through to next stage is up in the air, will depend on interest (compare to Temporal which started fairly slow but has gained huge momentum recently and is now at stage 3 and engine testing level) but it's encouraging.

There is an active TC39 proposal to add immutable types to JS: https://github.com/tc39/proposal-record-tuple
There's a Stage 2 proposal before TC-39 to add immutable Record and Tuple types [1] which would be structurally compared and perfect for complex Map keys.

It's also easy enough to find or write quick simple Map wrappers that use a hash function on an object as keys when provided (either piggy-backing on the existing Object.prototype.valueOf, which always exists on every object and easily falls back to the reference-based current behavior, and expecting classes to have custom overrides for that, or using a Symbol named function of their own to avoid polluting own-property-keys/name clashes with other libraries).

[1] https://github.com/tc39/proposal-record-tuple

> Want first class tuples/immutable arrays.

On this subject specifically, see the records & tuples proposal (currently at stage 2): https://github.com/tc39/proposal-record-tuple