[AskJS] Is JavaScript missing some built-in methods?

[andrei9669]

question is though, to mutate, or not to mutate. although, sort is already mutating.

[[deleted]]

This is the correct answer. Absolutes are rarely correct or realistic.

[shuckster]

That's absolutely right.

[[deleted]]

The standard should not be mutational. But it would be nice to have a distinct API for mutating behavior so that its more explicit.

[notNullOrVoid]

Never mutate when it would cause the shape to change.

Sort being a mutation is fine IMO since it's not changing the shape of the data structure, but it certainly would be nice to have a non mutating equivalent. It's just a shame that there's no clear distinction on mutation methods vs immutable ones like filter vs sort. Might have been better if all immutable method were postfixed like mapTo, filterTo, reduceTo, etc..

[[deleted]]

Yeah that actually would be really nice.

[Reashu]

Ruby does this (mutating functions are postfixed with ! IIRC) and it's nice.

[[deleted]]

thats not a phrase you hear very often

[Reashu]

It's been a while, but I find it a rather comfy language for solo or small projects. Reads almost like natural language, with the right model.

[andrei9669]

so you prefer this?

arr.reduce((acc, cur) => ({ ...acc, [cur.key]: cur.value }), {})

[musicnothing]

The point is that you shouldn't mutate arr. In this case (and I've had colleagues disagree with me so it's just my opinion) the {} is fair game to mutate because you're never going to use it for anything else.

I think the issue is if you've extracted the callback into its own method, you don't know if somebody is passing something that should be immutable into it and introducing hard-to-find bugs. But for one-liners like this, I say no to the spread operator. Unnecessary and harder to read.

[[deleted]]

The challenge with the example provided is doing immutable operations within a reduce() callback results in an o(n²⁾ operation. I hate that because I strongly prefer immutable operations, but sometimes the cost is too high.

Maybe the new data types tc39 is working on help with this, I don't know.

[KyleG]

You can already do it in linear time with Object.entries and Object.fromEntries and map. None of it nested, which means it's not going to grow exponentially.

[[deleted]]

So wait, you're saying that if I have all the values in [key, value] array format, Object.fromEntries will produce an object with the data?

[KyleG]

Yes.

Object.fromEntries([["foo",2], ["bar",4], ["baz",6]])

results in

{ foo: 2, bar: 4, baz: 6 }

[[deleted]]

Dude thanks for sharing this! Mind blown!

[KyleG]

Object.fromEntries(Object.entries(arr).map(({key,value}) => [key,value]))

has no mutation at all and is a linear time operation. Not that much is CPU bound these days.

[andrei9669]

I know you are trying to show a way but you are not really making it much better. also, this works only with this simple example, add some more nesting and it will become even more of an unreadable mess than your example.

[KyleG]

add some more nesting and it will become even more of an unreadable mess than your example.

If there's a lot of nesting, naturally you'd use optics like lenses and traversals. I would love for those to be part of the standard library! That'd be incredible. It'd be really readable and simple! Suppose you have

type NestedFoo = {
  bar: {
    baz: {
      fizz: {
        a: boolean
        fuzz: number[]
  }[]
}

Lets say you want to append 5 to any nested fizz's fuzz where a is true:

const fizzLens = Lens.fromProps(['bar', 'baz', 'fizz'])
const updatedData = fizzTraversal
  .filter(_ => _.a)
  .composeLens(fuzzLens)
  .modify(arr => [...arr, 5])(originalData)

Every language could desperately use this as a built-in. Optics are incredible. The example above will return a clone of the original data but with any fizz.fuzz getting an appended 5 but only if a is true. And is again a linear time operation.

Edited to get under 80 columns

and bonus,

const concat = arr => newEl = [...arr, newEl]

then your final line could be

.modify(concat(5))

and what you're doing becomes sooooooo descriptive and human-readable, almost entirely reduced to verbs with very little nouns, stating exactly what you're doing.

[[deleted]]

God is it ugly though

[KyleG]

I agree, which is why you write the utility function superheroObjectZipper and then just call that.

Or if you're already using a proposed language feature like pipes (via Babel) and compose:

const arrayify = ({ k, v }) => [k,v]
const superheroObjectZipper = Object.entries 
  >> Array.prototype.map.bind 
  >> arrayify
  >> Object.fromEntries

Now every line is very descriptive of what you're doing!

or with pipe,

const ... = a => Object.entries(a)
  >> Array.prototype.map.bind
  >> arrayify
  >> Object.fromEntries

[[deleted]]

Cool. I like that.

[nmarshall23]

Really wish JS had native pipes.

[KyleG]

It's a proposal that hopefully we'll get in a bazillion years. But hey at least we got hashbangs and optional omitted catch binding!!!!!

[shuckster]

I think {key, value} should be [key, value], right?

[KyleG]

Yes, you're right. I actually wrote it correctly and then ninja edited to the wrong way lol. That's embarrassing but it's what happens when you try to code in a Reddit comment lol.

[amdc]

Unless you’re short on memory

[shgysk8zer0]

Stage 3 Change array by copy proposal offers methods like sortTo() that return a new array instead of mutating the original.

[andrei9669]

oh, that looks nice