I don’t know if I’d call it an idiom — rather I’d argue that in modern JavaScript, mutating passed objects is often an anti-pattern.

▲

dashersw 4 days ago | parent [-]

I personally agree. But the default expectation (and therefore the design) should follow the practices of the language. If JS allows mutations on the objects passed to a function to be reflected on the parent, I believe frameworks should follow this paradigm.

And in the end in Gea developers have full control over this, just in the same way they do in real life. `child({ ...obj })` easily solves this, for example, in both idiomatic JS and in Gea.

▲

mpalmer 4 days ago | parent | next [-]

You're using various terms to refer to concepts which are similar but distinct, and it's confusing the issue a bit.

> But the default expectation (and therefore the design) should follow the practices of the language

Languages do not have practices, developers do.

Regarding "idiom": core language features/semantics are not idioms. In programming, "idiom" usually refers to small commonly-used patterns that reside atop the language. "Mutating objects" is not an idiom, if only because I can think of any number of non-idiomatic uses of mutation.

> If JS allows mutations on the objects passed to a function to be reflected on the parent

JS "allows" mutations on objects to be "reflected" elsewhere, because that's how mutation works. If JS had to support scoped mutability at the language level, the language would be significantly more complex.

But this implies nothing about the value or advisability of using mutation and two-way binding in an application framework. That is a choice on which framework authors usually land on one side or the other.

It seems that by more or less equating "idiom", "practice" and "paradigm", you're opting out of the sorts of choices that not only distinguish web frameworks, but simplify the patterns involved in building with them.

	▲	dashersw 4 days ago \| parent [-]
		[dead]

▲

dalmo3 3 days ago | parent | prev | next [-]

> `child({ ...obj })` easily solves this, for example

Spreading doesn't prevent you from mutating nested fields. The fact that you think this is an easy problem puts all your other choices under question.

	▲	dashersw 3 days ago \| parent [-]
		Feel free to question anything you like and I'll help you find the answers. This is a well-trodden path. All aspects of object mutation and its effects are obvious and well-known. What is pass by ref and what is pass by val is also pretty obvious. One can easily pass in primitive values and not worry about two-way binding if they choose to. One can also easily not mutate any props they receive from their parents. This is already the best practice in eslint for like 10 years. This is not easy, this is trivial. I'd rather see some real concerns.

▲

anamexis 4 days ago | parent | prev [-]

> But the default expectation (and therefore the design) should follow the practices of the language. If JS allows mutations on the objects passed to a function to be reflected on the parent, I believe frameworks should follow this paradigm.

Why? Why should frameworks be beholden to the mutation semantics of the language, particularly with JS where there is no choice of language in the browser? Why should frameworks follow this paradigm?

	▲	dashersw 4 days ago \| parent [-]
		Because JavaScript _is_ the language and people know it. I never understood the concept of a "React developer", for example, although I saw many junior devs who were very well-versed in React and didn't completely understand JavaScript. In the end, it's a design choice. Of course frameworks don't inherently _need_ to be beholden to the standards of the underlying language, but I think this is just simpler, therefore a worthy goal to pursue.