The readonly computed property depends on readonlyReason. readonlyReason consumes state external to bar from the foo state slice.
When "Submit" is clicked, readonly should become true based on how the computed property is written. However it remains false. The current workaround is to define an explicit state resolver to isolate readonlyReason. When readonlyReason is accessed directly by the state resolver, readonly returns the expected value. See store.ts and try toggling the computed props to see this in action.
I believe what's happening here is that this check prevents the computed prop from re-computing any time the computed prop's inputs are the same OR if store state is equal to the previous store state. In this case, the inputs are equal (with no explicit state resolvers, the default state resolvers of [(state) => state] are used, and no local state has changed), but store state and previous store state are different, and since the prop in question depends on a computed property that depends only on external state, its not updating correctly.
I have a possible fix in mind and will test with the help of @jmyrland before opening a PR. If for some reason this cannot be fixed, we should update the documentation to cite this as a known issue.
See this CodeSandbox:
The
readonlycomputed property depends onreadonlyReason.readonlyReasonconsumes state external tobarfrom thefoostate slice.When "Submit" is clicked,
readonlyshould becometruebased on how the computed property is written. However it remains false. The current workaround is to define an explicit state resolver to isolatereadonlyReason. WhenreadonlyReasonis accessed directly by the state resolver,readonlyreturns the expected value. Seestore.tsand try toggling the computed props to see this in action.I believe what's happening here is that this check prevents the computed prop from re-computing any time the computed prop's inputs are the same OR if store state is equal to the previous store state. In this case, the inputs are equal (with no explicit state resolvers, the default state resolvers of
[(state) => state]are used, and no local state has changed), but store state and previous store state are different, and since the prop in question depends on a computed property that depends only on external state, its not updating correctly.I have a possible fix in mind and will test with the help of @jmyrland before opening a PR. If for some reason this cannot be fixed, we should update the documentation to cite this as a known issue.