Trace source of atom updates

[kevinschaich]

Discussed in #135, original issue #130

^{Originally posted by kevinschaich April 11, 2024}
When your state becomes large enough, effects tend to overlap – especially in applications with a lot of visual/input interactions (mouse movement, tracking positions of elements on the screen, dragging and dropping, etc). This can lead to render loops that can be hard to track down. If you have 10 buttons/sliders/keyboard shortcuts that all perform the same state update, it's really time consuming to figure out which one of them is causing issues.

Redux devtools has a nice feature that lets you "trace" the source of updates:

I think this would be a nice addition to the devtools, perhaps in the Time Travel tab behind a (default off) feature flag or setting.

[kevinschaich]

I made some progress on this today. Looked into how Redux devtools is making it work – they create a new error and get the call stack, e.g.:

const trace = new Error().stack

However that gets us a lot of junk including stuff from React/Next/Webpack etc. so we'll need to clean it up.

Just a few lines of filters got me extremely close to what we'd need to support a v0 in Devtools:

    store.sub(CodeEditorCodeAtom, () => {
        const trace = new Error().stack
            ?.split('\n')
            .filter(
                (line) =>
                    !line.includes('vanilla.mjs') &&
                    !line.includes('react-dom-client.development') &&
                    !line.includes('<anonymous>') &&
                    !line.includes('atom-provider') &&
                    !line.includes('react.mjs'),
            )
            .join('\n')

        console.group('CodeEditorCodeAtom modified.')
        console.log('New Value:', store.get(CodeEditorCodeAtom))
        console.log(trace)
        console.groupEnd()
    })

And indeed on line 117 of BlockEditorHeader:

setCode(blockFile.content as string)

[arjunvegda]

Sorry, I've been MIA recently. I have not had a chance to look into this 😟 Probably wouldn't until a few more weeks.

Since this is an ask for net new feature, let's convert this issue into a discussion.

[arjunvegda]

This is good progress, should we look at how Redux does this and draw inspirations from it?

Have you looked at stacktracey? Seems pretty pretty promising.

[kevinschaich]

@arjunvegda why do you keep converting this into a discussion? I'm also a collaborator for the Jotai org and this is going to get lost. If we both agreed it is valuable then it should be an issue so people can easily find it and track progress.

[dai-shi]

we generally prefer using discussions. visibility is a bit of issue though. I sometimes use "pin". moving some issues to discussions help other issues to be more visible. so, let's follow @arjunvegda 's decision.

[arjunvegda]

We don't use issues to track features for this repo. We can get a birds eye view of all the ideas that users are proposing on the discussions tab. This includes maintainers as well.

Would you like to pick this work up? We can chat over Discord and align on plans. 😁