Support for undefined puts

[orimay]

Currently, it's not possible to get rid of a key in GUN. This update adds such an option. As you put some key with undefined value, the key gets removed, and the on listeners (but not the map ones) get called. The key gets removed from storage and remote peers, as the metadata about the key gets persisted.

This is useful for the cases where we want to map over some object, but don't wanna deal with null keys (which, definitely, have a separate meaning). For example, data indexes represent such objects.

[wayjake]

With your responses, though helpful, I can assure you your knowledge is infinitely greater as to how the small pieces fit together. I think my question(s) would be:

• how do we know that we hit all the correct places that interact with setting values?
• is there a pre-deploy check that we can do?
  • perhaps I could fire up a server on this branch and try to set some things null?
• once deployed, how do we know if adverse reactions occur?

[orimay]

Well, it was not new functionality, rather than the removal of restrictions on undefined value. You will be able to observe the changes via on callback on the node. Also, you suppose to put undefined rather than null to see this in action. null values are already supported

[amark]

I love the idea of extending to support other types. We just got off a call, and we tried checking to see if this could be done "natively" and a hurdle we hit is that TextEncoder for WebCrypto does not differentiate between "" and undefined, so this starts to overly complicate cross-system compatibility. However, it should still be trivial to support it via declared types, like (random example, not actual proposal) "@person='John'" or JSON-LD type stuff, then the app can parse accordingly.

If supporting any type of type is not the goal, just trying to support cleaning up tombstoned values, then we can add an optional wire adapter that checks for a special property on a node, and purges it.

[wayjake]

This is an interesting perspective that, admittedly, took me a couple read-throughs to grasp. This is partly what excites me about this project is that in weighing in the future tangibilities we are able to make things maximizing-ly interchangeable.

I was originally curious about this PR because it was one of the first caveats that I ran into when developing in Gun. I worked around it in my code and once situated I mostly don't notice the difference, at least presentation-wise. And it added a little "hidden" feature as the keys in my object are a reference to other objects so though no presented visually, I can command their spirits back to life as needed.

The spirit of the space seems to trend towards being immutable. I think my original concern was that if we cannot remove keys from an embedded object it may cause concern if that key was something I truly wanted to evaporate.

Interesting discussion @amark and @Orimay thank you for allowing me to join on this branch/features' journey.

[orimay]

Sadly, I missed something on network state delivery so this PR is useless so far :c Therefore -- I am closing it until I am able to fix it or make a chain extension