What does HackerNews think of proposal-record-tuple?
ECMAScript proposal for the Record and Tuple value types. | Stage 2: it will change!
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
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
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.
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
`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.
Theoretically they would use structural sharing for their implementation which should reduce the overhead of creating a whole new array of objects like that
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.
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).
On this subject specifically, see the records & tuples proposal (currently at stage 2): https://github.com/tc39/proposal-record-tuple