Wrapping with memoize redux selectors and passing them to connect.
When selector returns state or state.location (an object that prints in the console like proxy), an error happens.

state.location Proxy {id: "Login", params: {…}, query: {…}, prev: null}
00:04:02.369 VM47658 connectAdvanced.js:251 Uncaught TypeError: result.hasOwnProperty is not a function
    at deproxifyResult (VM47694 call.js:65)
    at deproxifyResult (VM47694 call.js:72)
    at deproxifyResult (VM47694 call.js:72)
    at deproxifyResult (VM47694 call.js:48)
    at deproxifyResult (VM47694 call.js:72)
    at callIn (VM47694 call.js:141)
    at Function.ms_ [as mapToProps] (VM47686 memoize.js:82)
    at mapToPropsProxy (VM47669 wrapMapToProps.js:48)
    at Function.detectFactoryAndVerify (VM47669 wrapMapToProps.js:57)
    at mapToPropsProxy (VM47669 wrapMapToProps.js:48)
deproxifyResult @ VM47694 call.js:65
deproxifyResult @ VM47694 call.js:72
deproxifyResult @ VM47694 call.js:72
deproxifyResult @ VM47694 call.js:48
deproxifyResult @ VM47694 call.js:72
callIn @ VM47694 call.js:141
ms_ @ VM47686 memoize.js:82
mapToPropsProxy @ VM47669 wrapMapToProps.js:48
detectFactoryAndVerify @ VM47669 wrapMapToProps.js:57
mapToPropsProxy @ VM47669 wrapMapToProps.js:48
handleFirstCall @ VM47683 selectorFactory.js:31
pureFinalPropsSelector @ VM47683 selectorFactory.js:79
runComponentSelector @ VM47658 connectAdvanced.js:36
initSelector @ VM47658 connectAdvanced.js:188
Connect(Component) @ VM47658 connectAdvanced.js:129
constructClassInstance @ VM47646 react-dom.development.js:11768
updateClassComponent @ VM47646 react-dom.development.js:13490
beginWork @ VM47646 react-dom.development.js:14089
performUnitOfWork @ VM47646 react-dom.development.js:16415
workLoop @ VM47646 react-dom.development.js:16453
callCallback @ VM47646 react-dom.development.js:145
invokeGuardedCallbackDev @ VM47646 react-dom.development.js:195
invokeGuardedCallback @ VM47646 react-dom.development.js:248
replayUnitOfWork @ VM47646 react-dom.development.js:15744
renderRoot @ VM47646 react-dom.development.js:16547
performWorkOnRoot @ VM47646 react-dom.development.js:17386
performWork @ VM47646 react-dom.development.js:17294
performSyncWork @ VM47646 react-dom.development.js:17266
requestWork @ VM47646 react-dom.development.js:17154
scheduleWork @ VM47646 react-dom.development.js:16948
scheduleRootUpdate @ VM47646 react-dom.development.js:17636
updateContainerAtExpirationTime @ VM47646 react-dom.development.js:17663
updateContainer @ VM47646 react-dom.development.js:17690
ReactRoot.render @ VM47646 react-dom.development.js:17956
(anonymous) @ VM47646 react-dom.development.js:18096
unbatchedUpdates @ VM47646 react-dom.development.js:17517
legacyRenderSubtreeIntoContainer @ VM47646 react-dom.development.js:18092
render @ VM47646 react-dom.development.js:18151
(anonymous) @ VM47639 index.js:15
(anonymous) @ VM47639 index.js:23
./src/client/index.js @ VM47334 bundle.js:11222
__webpack_require__ @ VM47334 bundle.js:725
fn @ VM47334 bundle.js:102
0 @ VM47334 bundle.js:11668
__webpack_require__ @ VM47334 bundle.js:725
(anonymous) @ VM47334 bundle.js:792
(anonymous) @ VM47334 bundle.js:795
00:04:02.389 VM47646 react-dom.development.js:14549 The above error occurred in the <Connect(Component)> component:
    in Connect(Component)
    in div
    in Unknown (created by ReactiveHOC)
    in div (created by Reflex)

import memoize from 'memoize-state'
import { connect as rrConnect } from 'react-redux'

const mem = o =>
	memoize((s, p) =>
		Object.entries(o).reduce((acc, [key, func]) => Object.assign(acc, { [key]: func(s, p) }), {})
	)

export const connect = selectors => rrConnect(mem(selectors))

The dependency proxyequal was updated from 2.0.1 to 2.0.2.

🚨 View failing branch.

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

proxyequal is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Your Greenkeeper Bot 🌴

Look like WeakMaps frees a data a bit earlier.

Return an object, to make it more usable.

Having memoize-state enabled (globally) redux-form does not trigger validation.

🚨 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 🌴

🚨 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 🌴

import memoizeState from "memoize-state";

const selector = memoizeState(s => {
  return Object.values(s.items).map(x => x.text);
});

const state = {
  items: {
    1: { text: "foo" }
  }
};

console.log(selector(state));
// expected ['foo']
// actual   ['foo']  ✅

const newState = {
  ...state,
  items: {
    ...state.items,
    2: { text: "bar" }
  }
};

console.log(selector(newState));
// expected ['foo', 'bar']
// actual   ['foo'] 🚩

Codesandbox demo

Recent changes to memoize-state and proxyequal adding WeakSet uses have broken the IE11 compatibility promise from the readme.

See #4 "Should work for IE11/Android without polyfills" for background.

Note, WeakMap is (mostly) supported by IE11 natively, but WeakSet is not:
https://caniuse.com/#search=weakmap
https://caniuse.com/#search=weakset

c6765f6 means memoize-state >2.0.11 is broken

theKashey/proxyequal@b498eb1 means proxyequal >2.1.0 is broken.

One workaround is pin at the compatible versions of the packages:

-    "memoize-state": "^2.0.7",
+    "memoize-state": "=2.0.10",
+    "proxyequal": "=2.0.9",

The other is include a WeakSet polyfill in applications that end up pulling in any of this code:

import 'core-js/es/weak-set';

Hey Anton, so basically for one we need it to work in the demo:

https://codesandbox.io/s/64mzx7vjmz?module=%2Fsrc%2Fconnect%2Findex.js

You mentioned that function references was the primary issue. So we need that.

Here's a primary test that must work:

static getDerivedStateFromProps(nextProps, prevState) {
        const { storeState, ...props } = nextProps
        const state = selector(storeState, props)

        console.log(prevState === state) // this must be true, when we are expecting it to be true :)

        return prevState === state ? null : state
}

Then dispatch({ type: 'BAR' }). The comparison will always be will always be false, even when nothing in state has changed. So hopefully this is just a matter of making the dispatch key/val work.

As far as this:

const fn = memoize(obj => ({ obj })
fn({ foo: 123 }) === fn({ foo: 123 })

Perhaps, we don't in fact need that. So let's just forget that for now.

Feel free to fork the demo, upgrade the deps, and paste a link to the working demo on the react-redux PR. I think it would be quite impressive to see all this come together in that demo. So for now, let's just think about what's actually being done in the demo, and then later I'm sure other cases will be brought to us.

deproxifyResult shall not dive deeper into POD objects.

deproxifyResult should not dive into state node.

As continue of #5

Full object spread is a big problem - from point of view it is a performance killer, as long all object fields are set to be trackable, from another - this is why we emit a warning asking a user to reconsider selector, and that is not nice.

First version of "spread detection" just disables tracking during massive spread operation. Now - only record a fact, as long we have to emit a new "result" if any of fields got updated.

But how memoize-state tracks the keys?

• "By use". there is a proxy get hook, to trap any access to a property. This is how we know about something got accessed.
• "By result". it analyse the function result in search of values just passed through, then memoize-state have to deproxify result, replacing Proxies by original values. This is but sorting array input does nothing - it will be replaced by the original object, as long it represents it.

Also

• there is "magic" field, "scan(Start|End)Guard", added to each object to detect spread.

Missing

• we could add get/apply trap on some array methods( https://github.com/sorodrigo/on-change/blob/caa29f63ad78108a9006eeb82774088da80822bb/index.js#L35) to detect "spreading" of arrays, and sorting immutable input data.

The idea:

What if add a special flag, to deproxify result outside of function call? Just split the calculation and the data you are going to pass throught.

Also we have to keep in mind - some spreads, are 100% "legal", as long "things just works that way". For example <Element {...props} /> - all the props are passed down to nested component.

Approach number 1

So "by result" will track the keys from "result" to be replaced by real values from "input". We still could have function memoized, but keeping "spreaded" paths updated.

const fn = state => memoize({...state, value: state.a + state.b});
// "returns" deproxifyed result {...state, value}
// should react only to .a or .b changes. But react on all props, recalculating everything.

const fn = state => memoize({...state, value: state.a + state.b}, {lazy: true});
// "returns", "raw" result {...Proxy(state), value)
// Will react only to .a or .b changes. "unwapping" proxies to the "current" values on each call.

As long object Objects and Arrays got proxies - not work for simple states. Meanwhile - could handle almost all the cases.

Approach number 2

Create a special function like Object.assign, to perform this operation without extra magic. "scanGuards" is the magic, I'll better keep of, but without them, we could not distinguish when values were "used", and when just "returned"

cons fn = state => ({...state, a: state.a, b:state.a+1});
fn({a:1, b:2});

spreaded, returned(used), used. If value was spreaded or returned - it still could be used.
Only b should be omitted.

Approach number 3

const fn = state => memoizedFlow(state, state => ({value: state.a + state.b});
// will produce "expected" behavior, as long it has `state = ({...state, fn(state)})` internally, outside of memozation tracking.

But, as long the goal of this library is to be "magic" - we might things about a better way.

When I try to use memoize nested the result is not correctly deproxyfied.
Is there something wrong with doing

const selectSomeContext = memoize((state, contextId) => state.foo.contexts[contextId]);

const selectSomethingRequiringContext = memoize((state, contextId) => {
    const context = selectSomeContext(state, contextId);

    return state.bar[context.currentSetting].map(x => x.val);
});

I expected the result to be deproxyfied as normal, but in the above scenario the resulting array would be still wrapped in its proxy.

I know I could just do state.foo.contexts[contextId] inside selectSomethingRequiringContext, but thats only the most basic example.

memoize state will return deep-proxied object as result, keeping counting each use of non-plain-old part of a result.

• should be free of side-effects out of stored function run.
• should deproxify results as much as possible.

Hi,

Thank you for a very interesting library. But I have a question that what is the difference between your one and React.memo or React.useMemo. Moreover, do you have any recommend between when or why I should use your or the React one?

Thank you!

Good day! I have discovered a behaviour I think must be an error.

If a function conditionally returns undefined depending on the state, then it is not memoized even if the value is unchanged.
The example function for memoization is:

k = memoize((obj) => 'value' in obj && obj.value ? obj.value : undefined)
k({ value: false }) // Cache miss expected
k({ value: false }) // Cache miss unexpected

Minimal representation with stats: https://runkit.com/embed/qitl8tiuizhf

Thank you!

Thanks for a great library! While trying to incorporate it into my project, I encountered the following issue.

Whenever a memoized function returns null, error is thrown instead.

Thrown:
TypeError: Cannot convert undefined or null to object
    at Function.keys (<anonymous>)
    at deproxifyResult (~/node_modules/memoize-state/dist/es5/call.js:72:12)
    at callIn (~/node_modules/memoize-state/dist/es5/call.js:155:16)
    at ms_ (~/node_modules/memoize-state/dist/es5/memoize.js:75:33)

Minimal representation: https://runkit.com/embed/urero89rh25k.

I think it should be possible to be able to return null value from the memoized function.

The fix seems to be to change this line from

if (typeof result === 'object') { }

to

if (typeof result === 'object' && result !== null) { }

but I am not familiar enough with the codebase to be sure.

With a given code

const mapState = ({ page, direction, ...state }) => ({
  page,
  direction,
  isLoading: isLoading(state)
})

memoize state should not react to any state change, as it would.

Posible solutions:

1. Currently, memoize react on key get, but it could react on key read. This will require all objects to be wrapped by something with valueOf/toString. They key will be added to tracking if someone "read" it, or "return" it.
   Could affect performance. Unstable.

2. Track such situations and encourage a user to change the code

• cast function to string, and search for spread operator (unstable)
• detect then all keys of state used, and inform user of a potential problem. Easy to do, could be enabled by default in dev mode.

Hi @theKashey,

I wanted to fix the unnecessary re-rendering issue on react native. I have tried reselect (selector with memoization), however it does not solve the re-rendering issue.

While searching around, I found this memoize-state. Interestingly, this solve the issue by wrapping this with mapStateToProps.

If you don't mind, could you help me to clear some of my doubts here:

1. If my objective is simply prevent unnecessary re-rendering in react, do you think memoize-state is enough for that without reselect?
2. In this case, do you recommend to wrap all the mapStateToProps with memoize-state? Or perhaps there are some exception case that I should not do for every mapStateToProps.

May fail while working with "Built-in" types, like Date, Map, Set

Sorry for the long title.

I noticed that accessing a "complex object" field but then doing nothing with it "binds" the memoization to it (iex it is recorded as the affected path)

    it('memoize test', () => {

        const memoized = memoize(context => {
            context.complex  // access but then do nothing with it
        })

        // call it
        memoized({ complex: { a: 1, b: 2, c: 3, d: 4 } })
        
       //  assert
        expect(memoized.getAffectedPaths()[0])
               .toEqual([])

      })

The assertion fails because it gets bind to ".complex".

Although if the fn changes and it access one of its inner member then affectedPath only contains the leaf longer path
For example if the function does

        const memoized = memoize(context => {
            context.complex  // access but then do nothing with it

            return context.complex.a
        })

Now affectedpath is just .complex.a

<< Ideally >> I would expect it not to bind with .complex since we are clearly not using that object (we are not accessing any member, neither getting its keys/values, etc.)

This example is of course a simplified version. In the real case the memoizing function is actually quite complex (a DSL interpreter).
In that case it happens that the code access such a complex field, to pass it as arg to many other nested functions, which depending on other inputs, they might end up not using that complex object at all !
But then the memoization cache misses if that complex object changes.

I was wondering if this is the expected behaviour (I can imagine there might be other cases where this field is used like identity comparisson that cannot be catched by the library right ?? is that the reason?)
And if so, if it makes sense to have some kind of option so that for particular cases the user might "tweak" this.

For the previous example

        const options = {
            omitPartialPaths: '.complex',  // here! 
        }
        const memoized = memoize(context => {
            context.complex  // access but then do nothing with it

            return context.complex.a
        }, options)

Currently our fix for this was to force ALWAYS accessing a field, a fake one, so that the library won't ever get coupled with the full "object".
For example:

        const memoized = memoize(context => {
           otherFnThatMightNotUseIt(context.complex)
            
           // force it
          context.complex.___FAKE_ACCESS__

        })

Thanks for your time and congrats for such a good library ! 👍

I have noticed a regularity: if you try to return in the function the object which is an argument of that function, than each time a new object returns (although the argument hasn't changed regarding the library's work).

const aFunction = (state) => Math.random();
const memoFunc = memoize(aFunction);
const result1 = memoFunc({a: 1, b: 2});
const result2 = memoFunc({a: 1, b: 2});
console.log(Object.is(result1, result2)) // true

const aFunction = (state) => state;
const memoFunc = memoize(aFunction);
const result1 = memoFunc({a: 1, b: 2});
const result2 = memoFunc({a: 1, b: 2});
console.log(Object.is(result1, result2)) // false?..

Even if the object is inside another object:

const aFunction = (state) =>({n: Math.random()});
const memoFunc = memoize(aFunction);
const result1 = memoFunc({a: 1, b: 2});
const result2 = memoFunc({a: 1, b: 2});
console.log(Object.is(result1, result2) && Object.is(result1.n, result2.n)) // true

const aFunction = (state) =>({n: Math.random(), data: state});
const memoFunc = memoize(aFunction);
const result1 = memoFunc({a: 1, b: 2});
const result2 = memoFunc({a: 1, b: 2});
console.log(Object.is(result1, result2) && Object.is(result1.n, result2.n)) // false?..

Is it bug or a feature?