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

Derived dependent atoms not updating during multiple sets #2107

Closed
jsheely opened this issue Aug 31, 2023 · 8 comments · Fixed by #2111
Closed

Derived dependent atoms not updating during multiple sets #2107

jsheely opened this issue Aug 31, 2023 · 8 comments · Fixed by #2111
Labels
bug Something isn't working

Comments

@jsheely
Copy link

jsheely commented Aug 31, 2023

Summary

I am seeing a change from 2.3.1 to 2.4.1 where atoms that are updated that have derived values using that atom are not updated

I commonly use backing fields for my atoms with custom setters that set the backing field and may set multiple other atoms.

The change between the versions is that when doing a set() on the backing field and then another set() for another atom() that uses that backing field. It is fine. But if that atom() uses another atom that uses the backing field it has not been updated yet.

Here is my quick psuedo code of the issue

const testingArray = [];
const _selectedItemIdAtom = atom<string>("")
const selectedItemIdAtom = atom(
    (get) => get(_selectedItemIdAtom),
    (get, set, id: string) => {
        set(_selectedItemIdAtom, id);
        if (id === '')
            set(stateAtom, null)
    }
)

const selectedItem = atom((get)=> {
    const id = get(selectedItemIdAtom);
    return testingArray.find(item => item.id === id);
})

const _stateAtom = atom({});
const stateAtom = atom((get) => { }, (get, set) => { 
    const item = get(selectedItem); 
    const itemId = get(_selectedItemIdAtom)
    console.log(itemId, item?.id) // itemId !== item?.id in 2.4.1. Correct in 2.3.1
    if (item) {
        set(_stateAtom, item.state);
    }
});

Link to reproduction

https://codesandbox.io/s/jotai-2-4-1-regression-kmclx3?file=/src/App.tsx

@dai-shi
Copy link
Member

dai-shi commented Aug 31, 2023

Thanks for reporting.
I hope you can create a small reproduction with https://csb.jotai.org.

Meanwhile, if this is a regression from 2.3.1, can you try and see which causes it?

You can install the codesandbox build in those PRs.

@jsheely
Copy link
Author

jsheely commented Sep 1, 2023

Attached a repo. Changing from 2.4.1 to 2.3.1 in the package.json will change the behavior of this button

(2.4.1) Missmatch 1 undefined
(2.3.1) Missmatch 1 1
Console.log

I believe that it might be related to the work on #2086 which was my initial hunch. I will try and test them individually

@jsheely
Copy link
Author

jsheely commented Sep 1, 2023

Confirmed that it is #2086 that introduces the behavior change

https://codesandbox.io/s/react-typescript-forked-57q86k

@dai-shi
Copy link
Member

dai-shi commented Sep 1, 2023

Thanks. Is it possible for you to try it with Jotai v1.13.1? #2086 was to fix a regression from v1.

@jsheely
Copy link
Author

jsheely commented Sep 1, 2023

1.13.1 has the same behavior as 2.3.1 where the values match.

@dai-shi
Copy link
Member

dai-shi commented Sep 2, 2023

Thanks. Yeah, this seems a regression with fixing another regression from v1...

@dai-shi dai-shi added the bug Something isn't working label Sep 2, 2023
@dai-shi
Copy link
Member

dai-shi commented Sep 2, 2023

@jsheely
Copy link
Author

jsheely commented Sep 2, 2023

Confirmed #2111 resolves issue. Nice work on the PR. That looks like a non trivial update.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants