Skip to content

Conversation

LinusBorg
Copy link
Member

@LinusBorg LinusBorg commented Dec 5, 2021

When we have a readonly object nested in another reactive object, attempting to write to a property of that readonly object fails, as expected.

const state = reactive({
  subState: readonly(reactive({ msg: 'Hello' }))
})
state.subState.msg = 'Bye' // => fails as `subState` is readonly

But if we have a readonly ref nested in a reactive object, it successfully writes to it.

const state = reactive({
  msg: readonly(ref('Hello' ))
})
state.msg = 'Bye' // => succeeds even though `msg` is a readonly ref.

This PR fixes that edge case.

Open questions

  • Is the behavior introduced by this PR the desired one?
  • Is this a "risky fix" as it may break code that works in current user projects?

fix: #5042

@LinusBorg LinusBorg added the need guidance The approach/solution in the PR is unclear and requires guidance from maintainer to proceed further. label Dec 5, 2021
@caozhong1996
Copy link
Contributor

Such cases are extremely rare, you can expect no one will rely on it, so this change won't cause problems.
For me, I hope readonly is highest priority, because I don't want to memorize summary table.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
need guidance The approach/solution in the PR is unclear and requires guidance from maintainer to proceed further.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Perserve immutable semantic on accessing reactive object properties
3 participants