pinia: A getter not updated when option store used with Vue 2
Reproduction
https://github.com/denego/piniajs-vue2-bug-report
Steps to reproduce the bug
Clone and start example project
git clone https://github.com/denego/piniajs-vue2-bug-report
cd piniajs-vue2-bug-report
npm i
npm run serve
Open http://localhost:8080 Click test2 link
Expected behavior
number2Getter value matches number2 value
Actual behavior
number2Getter value stays the same
Additional information
This project has two simple pinia stores, each has one number (number1 and number2), one getter (number1Getter and number2Getter) returning the number, and one action (updateTest1 and updateTest2) to increment the number.
There are two pages /test1 and /test2 each rendering TestCmp.vue. The component renders numbers and getters from both stores, and calls updateTest1 and updateTest2 on mount.
Initial render is good. However, if you click on test2 link to navigate, the mount hook of TestCmp.vue will be called, and number1, number1Getter, number2 will be incremented, but number2Getter which just returns number2, will not be updated.
Also interesting, if you place number2 and number2Getter before number1 and number1Getter in TestCmp.vue, then number1Getter will not be updated.
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Comments: 16 (6 by maintainers)
I think I have identified the root cause. First, in set(pinia.state.value, id, state ? state() : {}), it’s highly likely to trigger the renderTriggered hook of a certain component’s lifecycle. Then, due to the usage of the previous currentInstance in callHook, the scope of the previous instance is activated after the callHook is completed. As a result, the computedGetters in this section are all collected into the incorrect scope mentioned earlier.
Subsequently, when the component is being destroyed, _scope.stop is called. At this point, all the computed properties inside computedGetters are teardown, causing the getters to become non reactive.
This issue’s correct solution might involve addressing it from the Vue callHook. If possible, I’d be glad to assist in preparing a pull request for the fix.
@posva I have submitted the pull request. Please take a look. Thank you.
@gcaaa31928 Thanks for the Vue PR, it got merged and released:
Can this PR please be merged? This is a major issue for anyone trying to migrate large existing apps to Vue 3. The actual code change is only 6 lines, and it includes a spec, so I’m not sure what the holdup is here.
Not sure where this could come from TBH, so any contribution is welcome. Note this could also be an upstream bug.
As a workaround, using
setup()seems to not show the issue.