Support Foreign Members to @turf/clone

[DenisCarriere]

Slightly outside the scope of GeoJSON, Foreign members are members which is not described by the GeoJSON specification (https://tools.ietf.org/html/rfc7946#section-6.1).

Tasks

• Dropped cloneAll since the default does the same thing as JSON.parse/stringify
• Preserve Foreign members
• Preserve id & bbox
• Preserve Properties (string/number/object/array)

Before

Using @turf/clone would remove all foreign members by default, unless you performed the JSON.parse + JSON.stringify combo which is significantly slower.

const clone = require('@turf/clone');
const point = {
    type: 'Feature',
    title: 'Custom Title',
    properties: {},
    geometry: {
        type: 'Point',
        coordinates: [10, 20]
    }
};
clone(point).title;
//= undefined

Now

By default all members are preserved including id & bbox.

clone(point).title;
//= 'Custom Title'

[stebogit]

@DenisCarriere doesn't this in practice replace the cloneAll feature?

[DenisCarriere]

Maybe.. but I don't think so?... pretty sure cloneAll feature clones all property values (JSON.parse + JSON.stringify), so if you need to mutate some of the properties then it might be best to use that option.

However.. we could test it out and maybe it can replace the cloneAll feature entirely.

[DenisCarriere]

The cloneAll is primarily used to clone properties, so we could test for that.

[DenisCarriere]

I was able to preserve the properties using the default setting, so I've dropped that the cloneAll param. Doesn't really have any backwards compatibility effects since it behaves the same way if true or false.

[stebogit]

@DenisCarriere what if the user wants still to clone only the GeoJSON object (no foreign members) taking advantage of a higher speed? I'd keep an optional parameter here, like geojsonOnly or something, to allow that.

[DenisCarriere]

🤔 ... it's really not a big speed difference speed.

The bigger difference is mutate=true to not even do this clone operation at all!

The new "foreign member" support acts also to support id & bbox which is apart of the GeoJSON spec, so we shouldn't make that optional, we should clone those.

[stebogit]

Then now this is just a faster version of JSON.parse(JSON.stringify(thing))! 😜
And it makes sense to expect that the whole thing is going to be cloned.
Good job! 👍

[DenisCarriere]

Yep! It's a faster JSON.parse(JSON.stringify(geojson)) tool, also it looks "cleaner" by just wrapping it with clone(geojson).

It's about 2-3x faster... depends on the type of Geometry.

[stebogit]

@DenisCarriere does this guarantee you can modify the properties of the cloned object without changing the original ones? Just want to make sure this issue doesn't happen again 😅

[DenisCarriere]

Shouldn't have any impact, before these properties were being dropped (so it's better than before).

We can add some tests for this behavior.

It shouldn't have any impact on the issue you mentioned above.

[stebogit]

Sure, no impact on that specific issue; I just used that as an example of creating a reference to the item instead of cloning it.

[DenisCarriere]

Agreed, we just need to test if those properties get mutated or not.

[DenisCarriere]

@stebogit Did some significant changes to prevent properties from being mutated, added test cases for every scenario I can think of. @stebogit Let me know what you think about this now.

[DenisCarriere]

What's been done so far:

• Dropped cloneAll since the default does the same thing as JSON.parse/stringify
• Preserve Foreign members
• Preserve id & bbox
• Preserve Properties (string/number/object/array)

[DenisCarriere]

Going to merge, if we find any other issues, I'll open up a new PR with tests/solution.