Upgrading from v4.0.1 to 5.0.0 causes some issues related to computed props

Upgrading to the newest release of easy-peasy has broken some of our tests:

Test Suites: 31 failed, 34 passed, 65 total
Tests:       145 failed, 246 passed, 391 total

Upon further inspection, it seems that there is some issues with some computed properties being undefined (when they are not supposted to be).

Here is an excerpt of one of the repeating errors:

  TypeError: Cannot read property 'map' of undefined
  
      at actionReducer (src/components/App/Local.model.ts:109:52)  
      at fn (../../../node_modules/easy-peasy/src/create-reducer.js:8:43)
      at simpleProduce (../../../node_modules/easy-peasy/src/lib.js:124:20)
      at runActionReducerAtPath (../../../node_modules/easy-peasy/src/create-reducer.js:8:5)      at reducerForActions (../../../node_modules/easy-peasy/src/create-reducer.js:13:14)   
      at rootReducer (../../../node_modules/easy-peasy/src/create-reducer.js:37:31)
      at next (../../../node_modules/redux/lib/redux.js:219:22)
      at next (../../../node_modules/easy-peasy/src/persistence.js:236:19)
      at next (../../../node_modules/easy-peasy/src/effects.js:6:14)
      at ../../../node_modules/easy-peasy/src/listeners.js:5:20
      at next (../../../node_modules/redux-thunk/lib/index.js:14:16)
      at Object.dispatch (../../../node_modules/easy-peasy/src/computed-properties.js:29:12)      at Object.setGeneration (../../../node_modules/easy-peasy/src/actions.js:12:15

Has anything changed in how computed properties work, from v4 to v5?

[jmyrland]

Across our mono repo, we have a total of 884 unit tests - most of them touches easy-peasy in some shape or form. I’ve run the test for the entire repo, and only a single test is failing.

I’ve been scratching my head for a while, to figure out why the single test is failing. I have tried reproducing the exact conditions in the sandbox, but the tests are still passing there.

I just tried debugging the failing test - and of course, we got a schrödingers situation here. When I debug - the tests are of course passing 👯‍♂️

I’ve tried to insert a delay between the action and getState - but that had no effect on the result.

If you got any pointers on what I could try next, I’m all ears!

Edit:

I went poking, and came across this in the latest commit:

// We don't want computed properties resolved every time an action
// is handled by the reducer. They need to remain lazy, only being
// computed when used by a component or getState call.	         

The failing test does this:

1. Seed data via an action
2. Update data via an action
3. getState() then verify changes from step 2

The action in step 2 uses computed props internally, so I figured based on the comments above that I should try to call getState() (targeting the computed prop) in between step 1 and 2.

Et voila, it is now passing 🎉🎉🎉

The wierd thing is, that the contrived test example in the sandbox has the same setup - but it is passing without issues. 🤔

Maybe this is enough info to solve the last kink, but if not, let me know & I’ll help out where I can 👍

[jmyrland]

We got some progress 👏

Test Suites: 1 failed, 57 passed, 58 total
Tests:       1 failed, 416 passed, 417 total

Just a single test to go 😁

    expect(received).toHaveProperty(path)

    Expected path: "x"
    Received path: []

    Received value: {"1": {...}, "1.2": {...}, "2": {...}} 

      233 |         } = store.getState();
      234 | 
    > 235 |         expect(map).toHaveProperty('x');
          |                             ^

I’ve reconstructed the model & related test in the sandbox, and it generates the same error when using easy-peasy@5.0.2 - but it passes with easy-peasy@5.0.3 🤔 However, I still get the error locally.

The only difference in functionality between the sandbox model and the local (failing) modal, is that the local modal has some dependencies of a computed prop from another store.

I’ll tinker a little more with it, and see if I manage to reproduce the issue in the sandbox.