-
Notifications
You must be signed in to change notification settings - Fork 8
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
refactor: store file content in atom #105
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice to see the atoms wired up! Lots of suggestions but at a high level:
- Now that chore: set up frontend testing infrastructure #100 is in, this really needs some tests. It would be great to have tests for some of the invariants that you're maintaining, for example that a file gets purged from memory once it's closed in both panes. OK if it's in another PR, but it should probably the very next PR!
- I think we should use an eslint rule to enforce that "core" atoms are only used in the expected places, rather than relying on comments and underscores. See comment below.
- I believe Jotai's
atomFamily
is designed to eliminate some of the bookkeeping aroundMap
s.
It's less scary to refactor once you have tests, so maybe a path forward could be to add some unit tests for src/atoms/fileActions.ts
(the public state API) and then refactor the internals to use atomFamily
.
Thank you for these comments. I have addressed them |
This PR fixes #32
This splits the state in a more atomic way, with the following:
This also adds an
activePane
state, that enables the app to open new file in the pane that has been used in last.