Hey, I'm experimenting using memoize-state as an alternative to reselect on some selectors and I'm getting this error:

TypeError: 'get' on proxy: property 'byId' is a read-only and non-configurable data property on the proxy target but the proxy did not return its actual value (expected '#<Object>' but got '[object Object]')

According to the stack trace, the error is coming from the get method of the proxyequal proxy.

Here's a small reproducible without using any libraries (from this stackoverflow answer):

var obj = {};
Object.defineProperty(obj, "prop", { 
  configurable: false,
  value: {},
});

var p = new Proxy(obj, {
  get(target, property, receiver) {
    return new Proxy(Reflect.get(target, property, receiver), {});
  },
});

var val = p.prop;

Some observations:

• Tested on Chrome latest and Firefox Developer Edition
• I believe this is related to using immer on my reducers, immer freezes the objects.
• This is only happening on development mode (probably because immer don't freeze on production)
• Might also be related to nested selectors (one memoized selector that calls another one inside).
• May be unrelated but it seems this is only happening with some selectors, and they call at least one external function.

I found this pull request which contains a fix, maybe it would work here as well. Here's the code.

If I understood correctly proxyequal needs to handle this case.
@theKashey What do you think?

Hi, I'm trying to improve https://github.com/dai-shi/react-hooks-easy-redux with proxyMap,
but it doesn't behave as I expect. Do I misunderstand the usage?

$ node 
> const { proxyState } = require('proxyequal')
undefined
> const proxyMap = new WeakMap()
undefined
> const state = { a: 1, b: 2 }
undefined
> const trapped1 = proxyState(state, null, proxyMap)
undefined
> trapped1.state.a
1
> trapped1.affected
[ '.a' ]
> const trapped2 = proxyState(state, null, proxyMap)
undefined
> trapped2.state.b
2
> trapped2.affected
[]
> trapped1.affected
[ '.a', '.b' ]

I was expecting trapped2.affected to be ['.b'] and trapped1.affected to be kept ['.a'].

First of,

Thanks for this lib! It's great for performance improvements.

However, I've got quite large objects to compare, and they're not equal, but they should, and I want to inspect which property did change.

Is it possible to use compare and get some debug reports eg. Not equal because .key.otherkey.something is not equal

Unless drainDifference is called, differs keep increasing.
Most likely, we want to avoid it in the production environment.

An extra API is just one option.

I'm very happy using proxyEqual in my project.

I've created a few react hooks based on it and the way it can optimize renders is crazy!

However, I sometimes use it in generic hooks, where I don't know up-front what type of value will be used for the state.

And if it'll happen that such value will be primitive (eg. string, null), ProxyEqual will throw an error

TypeError: Attempted to add a non-object key to a WeakSet

add
    [native code]:0
proxyfy
    proxyEqual.js:133:21
proxyState
    proxyEqual.js:555:30
...

I've mitigated this issue by always wrapping my value inside a small object like { __value: valueHere }, but it's probably not the optimal way to do it as it's always adding one level of nesting when comparing anything.

I've tried to dynamically detect if I need such wrapper and wrap it or no when creating a proxy initially, but this also didn't work, as often state that used to be null, might become an object later etc (eg. when loading something from the internet null -> person) or object might become null (eq. selectedItemObject -> null)

Notes:

In the case of primitives, there is probably no way to optimize other than isEqual = a === b which seems fine for me for primitives.

Support for primitives is rather a consistent interface API when working with proxyequal

Object.create(null)

In my case graphql package could return such object.
Something like

export function shouldInstrument(obj) {
  const name = obj.constructor === undefined && typeof obj === 'object ? 'Object' : constructor.name;
}

should fix it

If I understand correctly it's just a slightly better version of shallowEqual but with the cost of proxy usage.
With consideration of the proxy cost can I assume that it always works faster than shallowEqual?
Why would I want to use proxyShalloow instead of proxyEqual?

In shouldInstrument.js, this package finds the global object by evaluating:

const globalObj = Function("return this")();

A lot of sites operate a content security policy which does not allow evaluation of strings containing JS. It would be nice if we got the global some other way, though some stack overflow discussions reveal this is actually non trivial.

However, there are (not so great) alternatives, which I think would work here without violating common CSP's. Since this package is used as a dep in popular libs like react-memoize, I think it would be a useful change to make it applicable to more audiences :).

Thanks for open sourcing this! :)

Having the same parent object(shallow equal), there is no need to compare nested information.
EqualProxy should check reference-equality of parent objects, and don't drill down into children if it is the same.
Having this logic it is possible to archive the same speed as shallow equal, and the same accuracy as proxy equal.

The current implementation always imports ProxyPolyfill:

However, that polyfill is 6K before minification, which looks like it's about 1/3 of the total source size.

Per https://bundlephobia.com/[email protected] , the deployed size is 8.3K min and 3K min+gz. If the polyfill was only conditionally imported (or even better, made a separate thing that users could import and enable themselves if needed), that size could probably shrink noticeably.

const proxy = proxyState({})
console.log(proxy.state.value)
console.log(proxy.affected) // affected is empty in IE 11, ['.value'] in Chrome

Any way to quick fix it?

🚨 Reminder! Less than one month left to migrate your repositories over to Snyk before Greenkeeper says goodbye on June 3rd! 💜 🚚💨 💚

Find out how to migrate to Snyk at greenkeeper.io

The devDependency codecov was updated from 3.6.5 to 3.7.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

codecov is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

🚨 Reminder! Less than one month left to migrate your repositories over to Snyk before Greenkeeper says goodbye on June 3rd! 💜 🚚💨 💚

Find out how to migrate to Snyk at greenkeeper.io

There have been updates to the babel7 monorepo:

• • The devDependency @babel/cli was updated from 7.8.4 to 7.10.0.

• The devDependency @babel/core was updated from 7.9.6 to 7.10.0.
• The devDependency @babel/preset-env was updated from 7.9.6 to 7.10.0.
• The devDependency @babel/register was updated from 7.8.6 to 7.9.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

This monorepo update includes releases of one or more dependencies which all belong to the babel7 group definition.

babel7 is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

Current "polyfills" relay on all the keys, existed on the target, as long proxyequal adds 3 "virtual" keys. As result - it does not work under standard polyfills.

theKashey/memoize-state#4

Hey Anton,

I've been looking over the code and spotted a few areas where we might be able to improve performance.

There's some small ideas I had based on chip architecture that should speed up loops (looping backwards is faster than forwards), as well as my understanding of how native methods have been implemented into the browser & what their performance is capable of (filter is slow)

Mind if I open a PR? Also, do you know if any specific areas where bottlenecks are occurring?

Would love to boost the benchmarks if possible :)