traviskaufman / cyclonejs Goto Github PK

The idea here would be to implement the following major change to the api:

The result of clone would always be asynchronous and always return a promise.

If a clone is successful, the promise would be resolved with the cloned object. It would be rejected with whatever error occured on failure.

The purpose of this change would be to support all possible clones with the object's specified in the spec, therefore attaining as close to full parity as possible with the W3C algorithm, which would be awesome.

Of course there are also cons.

For one, it would make writing code more complicated. Everything has to be async, whether or not the clone requires them, less we unleash cthulu

For another, the user would either have to ensure their environment supports Promises, or use a polyfill to ensure that they are. It looks like most major browsers natively support them, except of course for the red-headed stepchild of the browser world (which, like most people I know in the field, I could personally care less about), and Opera Mini (who even uses that?).

I'd love some feedback!

• travis ci
• testling

see #5

• Available options.
• Custom cloning procedures.

I fiddled around with the performance of this library since I found it being significantly slower than a straight 'for (var prop in orig)' implementation. I found that replacing the below line in _handleCollectionClone improved the performance with a factor 5-7.
from:
var isNonAccessor = _hasOwn(desc, 'value');
to:
var isNonAccessor = Object.prototype.hasOwnProperty.call(input,prop);

My only guess of whats happening is that the optimizer fails due to the bind of _hasOwn for some reason. Any suggestions, or am I missing something in the behavior of the two lines here?

My test case is cloning a simple byte array of ~600 000 elements

Safari 8.0 has an implementation of Map. If a key does not exist, it returns undefined as per the spec (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Map). Your polyfill, however, returns null instead of undefined in Map.get. This leads to a failure to clone in Safari 8 (and probably any other browser that implement Map).

See: https://github.com/w3c/web-platform-tests/tree/13bff083fba249ed260966bca65319b1b35d3f34/workers/semantics/structured-clone

Using esnext

Reduces file size and code clutter. ES6-transpiler should be able to provide appropriate WeakMap/Object static method polyfills.

Have CY.clone() return null if it comes across an uncopyable object instead of throwing.

Hi, I was searching an alternative for lodash clone and found cycloneJS which is a smaller and cleaner library for this operation.
After some tests I found out that cycloneJS has not very good performance on small arrays of objects (small is <1000). But it performed very well on bigger arrays. (comparing with lodash clone)
And bigger the array better is the performance of cyclone.js.

I've put two tests in jsperf:
http://jsperf.com/cyclonejs-vs-lodash-clone-on-small-array-of-objects
http://jsperf.com/cyclone-js-vs-lodash-clone-on-long-array-of-objects

Do you have any ideas why the slow numbers with small arrays?

Any progress on supporting those?

• Run lint and tests, make sure they pass
• Ensure version is bumped.
• Generate documentation
• Tag and push new revision

• Unminified, development version with source maps to the original es6 code
• Unminified, development version without source maps
• Minified, production ready version

Should fail if coverage isn't 100%

I noticed this comment in the code as I was source-diving:

// We only clone if the property is a non-accessor. We can't really clone
// getters and setters, we can only pass them through.

I'm fairly new to the structured clone algorithm in general, so forgive me (and please correct me) if I'm wrong. The W3C info says that if the input is an object or an array to "set deep clone to own." In the section discussing "own" deep cloning, it says:

Let source value be the result of calling the [[Get]] internal method of input with the argument name.

and a bit further down there's a note saying:

Property descriptors, setters, getters, and analogous features are not copied in this process. For example, the property in the input could be marked as read-only, but in the output it would just have the default state (typically read-write, though that could depend on the scripting environment).

So - that being said, is it correct to say that cyclone should call the getter (via reading the actual property) to get the source value, rather than pass the descriptor to Object.defineProperty?