Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Assigning to store whose value is an object is broken in version 3.25+ #5437

Closed
Reikooters opened this issue Sep 22, 2020 · 1 comment
Closed

Comments

@Reikooters
Copy link

Describe the bug
When assigning a value to a store whose value is an object, the whole store value now gets overwritten beginning from 3.25 and above. Working in 3.24. See more details with example in "to reproduce" below. Also broken in 3.26.

To Reproduce
See below repl links, same code but in version 3.24 and 3.25.

The example creates a store which is an object containing two strings. First it logs the store's value to the console.
Then it overwrites the value of one of the strings in the object, and logs the store's value to the console again.
In version 3.24, the object got updated correctly. In version 3.25, the entire object got overwritten.

https://svelte.dev/repl/d9a6917ded77445d97af5ff826890e93?version=3.24.1
https://svelte.dev/repl/d9a6917ded77445d97af5ff826890e93?version=3.25.1

Version 3.24 gives the following output - string2 has been overwritten which is correct.

Object { string1: "abc" ,string2: "" }

Object { string1: "abc" ,string2: "def" }

Version 3.25 gives the following output - instead of updating the value of string2 in the object, the entire object got overwritten with the string.


Object { string1: "abc" ,string2: "" }
"def"

Expected behavior
Expected behaviour is as per the result using Svelte version 3.24.

Severity
Blocking an upgrade to newer Svelte version. In my application I'm using stores for accessing global data, e.g. API Urls, tokens, user preferences etc used throughout the application. This change breaks the whole app.

@Conduitry
Copy link
Member

Duplicate of #5412 - this is already fixed on master and will be released soon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants