# Operator proposal: spread-assignment preserving object fields

**URL:** <https://es.discourse.group/t/operator-proposal-spread-assignment-preserving-object-fields/367>\
**Category:** 💡 Ideas\
**Created:** [June 17, 2020, 11:22am UTC](https://es.discourse.group/t/operator-proposal-spread-assignment-preserving-object-fields/367 "2020-06-17T11:22:17Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![artus9033](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/artus9033/32/349_2.png) [@artus9033](https://es.discourse.group/u/artus9033)\
**Post date:** [June 17, 2020, 11:22am UTC](https://es.discourse.group/t/operator-proposal-spread-assignment-preserving-object-fields/367/1 "2020-06-17T11:22:17Z")

</div>

I would like to suggest a new operator that would be a shorthand for a composition of the the operators: assigment and spread.

Background:  
This would help with extending existing objects or assigning objects only partially with a shorter syntax than `Object.assign( .. )` or spreading the object inside a new object and overwriting selected key values, as shown in the example. The feature would be extremely helpful for React.js developers who use such an operation frequently to change the component's state.

Example:  
Suppose we have `let obj = { a: 1, b: 2, c: () => 3 }`. Now, to modify the object by re-assigning a massive amount of properties (in this example simplified to just a few) one would do: `obj = { ...obj, b: "!", c: () => 4 }`. What I would suggest to change this would be to do a partial assign, e.g. with a `...=` syntax, which would look like the following: `obj ...= { b: "!", c: () => 4 }`.

Even further, there might be a consideration to add a similar operator extending the key-value colon operator: `partiallyAssignedObject = { a ...: { partial property1: 3, partialProperty3: "#" }`.

---

<div class="post-metadata">

**Author:** ![bergus](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/bergus/32/152_2.png) [@bergus](https://es.discourse.group/u/bergus)\
**Post date:** [June 17, 2020, 6:56pm UTC](https://es.discourse.group/t/operator-proposal-spread-assignment-preserving-object-fields/367/2 "2020-06-17T18:56:12Z")

</div>

> [@artus9033](#):
>
> Now, to modify the object by re-assigning a massive amount of properties one would do: `obj = { ...obj, b: "!", c: () => 4 }`

Are you looking to _modify_ the object, or overwrite the `obj` variable with an altered copy? The former could be done with `Object.assign`, the latter doesn't seem to be such a frequent operation to me, usually you would do something else with the new object.

> [@artus9033](#):
>
> a `...=` syntax, which would look like the following: `obj ...= { b: "!", c: () => 4 }` .

It is normally expected that compound assignment operators desugar to the respective binary operator - in your case `obj = obj ... { b: "!", c: () => 4 }`. I think we would need this first, and I don't think it should use the `...` token.

---

<div class="post-metadata">

**Author:** ![claudiameadows](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/claudiameadows/32/126_2.png) [@claudiameadows](https://es.discourse.group/u/claudiameadows)\
**Post date:** [June 18, 2020, 1:49am UTC](https://es.discourse.group/t/operator-proposal-spread-assignment-preserving-object-fields/367/3 "2020-06-18T01:49:28Z")

</div>

What benefit does this yield that `Object.assign` doesn't (other than not mutating the original instance)? Also, there's two other things to consider independent of that:

1. What would the syntax `a ...= b` do if `b` is an object?
2. How would arrays be accomodated? And if they use the same syntax, what would happen if `b` is an array and `a` is an object, or if `a` is an array and `b` is an object?

---

<div class="post-metadata">

**Author:** ![artus9033](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/artus9033/32/349_2.png) [@artus9033](https://es.discourse.group/u/artus9033)\
**Post date:** [June 18, 2020, 1:38pm UTC](https://es.discourse.group/t/operator-proposal-spread-assignment-preserving-object-fields/367/4 "2020-06-18T13:38:13Z")

</div>

> [@bergus](#):
>
> Are you looking to _modify_ the object, or overwrite the `obj` variable with an altered copy? The former could be done with `Object.assign` , the latter doesn't seem to be such a frequent operation to me, usually you would do something else with the new object.

I intend to reassign `obj` to an altered copy. I know there is an alternative way to modify it in-place with `Object.assign`, but the only aim of the operator I suggested would be to have a shorthand for such an operation, which may be based on one of the two ways.

> [@bergus](#):
>
> It is normally expected that compound assignment operators desugar to the respective binary operator - in your case `obj = obj ... { b: "!", c: () => 4 }` . I think we would need this first, and I don't think it should use the `...` token.

I am not quite sure what You mean by saying this, but the problem I wanted to state here was that assigning to a nested object would also overwrite it with just the `=` operator, not preserving the existing fields, so it would be helpful to have a shorthand operator shorter than spreading the original in the newly-created object.

---

<div class="post-metadata">

**Author:** ![artus9033](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/artus9033/32/349_2.png) [@artus9033](https://es.discourse.group/u/artus9033)\
**Post date:** [June 18, 2020, 1:41pm UTC](https://es.discourse.group/t/operator-proposal-spread-assignment-preserving-object-fields/367/5 "2020-06-18T13:41:23Z")

</div>

It does not yield any optimialization benefits, but would just be a sugary syntax that would make it shorter to alter object properties without having to write an additional spread line at the beginning of the new object to be assigned, or without using the long `Object.assign(...)` syntax. The underlying implementation itself could even be the same as for `Object.assign`, I am just thinking of a syntactic shorthand to make the code smaller and more readable.
