add $delete command to addons.update

[krawaller]

This PR adds a $delete command to addons.update. It takes a key or an array of keys and deletes them from the target object.

CLA completed (first-time contributor).

[krawaller]

Ack, only now saw discussion in #1807, where @syranide argues that it is preferable to set the property to undefined.

I'm not sure I agree though - it feels iffy that the property is still lingering. Also with set we can only "remove" one property at a time.

[syranide]

@krawaller "it's generally preferable", if you're dealing with fixed keys then setting to undefined/null should be preferable (to avoid creating new hidden classes), but if you're dealing with dynamic indices then deleting probably makes most sense. It was just intended as a reminder for anyone stumbling upon it.

[krawaller]

Nod, understood.

Another note, just realised that to continue parity with MongoDB, this should probably be renamed to unset and altered to behave in the same way?

[krawaller]

Updated functionality for MongoDB $unset parity (but haven't changed name):

• Target object can now be an array, in which case we replace matching element(s) with null.
• Also argument can be an object with keys to be deleted.
• EDIT: change name from delete to unset.

This means we now have the exact same functionality as MongoDB, except...

• we can give a single key or an array or object of keys, while in mongo its always an object
• we don't support dot notation in keys which Mongo does

[chenglou]

Nagging @petehunt because we wanna pull this in and deprecate update in favour of immutable-js

[gaearon]

I've said it here but want to bring the comment here as well: I'm not sure special behavior for arrays is justified, even if Mongo does it.

IMO if update lets your set not-yet-specified keys on an array with $set, then it should be possible to use $unset to undo this. A common use case for update is changing data (e.g. in Flux store), and when you change data, you often want to be able to revert your changes later.

[gaearon]

On the other hand, most people probably want “normal” $unset behavior that doesn't make array sparse (this also has bad perf effects IIRC). So I get why Mongo did that.

After all, if you really wanted to poke a hole in an array, you can $apply and do that manually.

[flying-sheep]

this also has bad perf effects IIRC

it’s the other way round: dense arrays have bad performance characteristics when used to represent sparse ones. and nothing about setting elements to null in an array is in any way more normal than setting it to 'thingamajig'

mongo’s behavior makes no sense:

When used with $ to match an array element, $unset replaces the matching element with null rather than removing the matching element from the array. This behavior keeps consistent the array size and element positions.

that’s bullshit. if you delete someArray[index], you’ll still be able to get the index after the last element with someArray.length afterwards, and of course the element positions stay the same. so why the hell would it set array elements to null?

also, why would someone specify an object without values just to give a set of keys. JS has no native syntax for sets (objects-without-values), and we only iterate the keys, so KISS and simply accept an array of keys or one key here like in other update APIs:

update([1,2,3], {$unset: 1}) === [1,,3]
update([1,2,3], {$unset: [0, 2]}) === [,2]
Object.keys(update([1,2,3], {$unset: 0})) === ['1', '2']

[b5]

+1 for this. I'd love an $unset command!

[CosticaPuntaru]

+1

[sophiebits]

Prefer using immutable.js. We don't want to turn this into a crazy DSL.

[dustingetz]

Is this even used internally, can we split this out into a standalone library? addons.update is valuable to me outside of React projects.

[chenglou]

It already is: http://facebook.github.io/react/blog/#two-packages-react-and-react-dom
https://www.npmjs.com/package/react-addons-update

[sophiebits]

@dustingetz Would you want to maintain it?

[zpao]

It is used internally (unfortunately). And yes, while it's available standalone(ish, it still depends on react), it should be split off in a real standalone project. Give me a good name and I'll do it sometime soon. I kinda want to call it ognom…

[dustingetz]

I want to use it to implement update-in for vanilla js data structures, which would let us compose actions. It's so easy to implement that you could even just include the sugar and call it updateIn 😄

[peteruithoven]

I see it's split on npm: https://www.npmjs.com/package/react-addons-update, but where does the code live? Is there a seperate github repo? I can only find the code in the react repo?
https://github.com/facebook/react/blob/master/src/addons/update.js

[zpao]

@peteruithoven It currently only lives here, where you found it. The npm module (all of the react-addons- modules in fact) just require deeply into react for the time being until they can become standalone / get removed.

[peteruithoven]

But pull requests like this one aren't merged? It feels like we shouldn't use this until it's split off and it can accept more contributors / contributions.

[gaearon]

From what I understand it stays here in 0.14 because react/addons still works for back compat.
0.15 is the release that kills 0.14 back compat, so I'd expect it to become standalone at that point.

[dustingetz]

As an experiment here is updateIn implemented against react-addons-update, along with other nice wrappers, it is a very nice programming model https://github.com/dustingetz/update-in

import {updateIn, merge, push, unshift, splice} from 'update-in';
const val = {a: {b: 0, c: 2}, xs: [1, 2]};

merge({x: 1, y: 1}, {y: 2, z: 2}) // => {x: 1, y: 2, z: 2}
updateIn(val, ['a'], merge, {c:99, d: 99})     // => {a: {b: 0, c: 99, d: 99}, xs: [1, 2]}

[ahdinosaur]

👍, being able to delete a property is necessary when you want a property to no longer exist when iterating with for ... in, Object.keys.

by the way, if anyone wants a react-addons-update compatible module that provides this ability, tcomb/lib/update has $remove which does the same.

[gaearon]

You might be interested in https://github.com/kolodny/immutability-helper that lets you define custom operations by name.

[facebook-github-bot]

@krawaller updated the pull request.

[hoytech]

Using $apply and/or immutable.js doesn't work for some use-cases since updates can't be serialised for transfer between client and server (short of implementing another protocol on top).

In case it helps anyone, I have created an almost-compatible module which implements $unset:

https://www.npmjs.com/package/update-immutable

My module also supports autovivification which can help you avoid maintaining initial state skeletons in components.