-
-
Notifications
You must be signed in to change notification settings - Fork 592
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
docs(async): Rework async education #1176
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit 5d3d203:
|
Thanks for the suggestion. One request: I want to limit the discussion in "BASICS" to the core module
|
docs/basics/async.mdx
Outdated
@@ -80,6 +110,57 @@ const Component = () => { | |||
|
|||
> There's no way to know as of now if an atom suspends because of `read` or `write`. |
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.
We can remove this. It's a note for pre-1.4. write
will not suspend. Exception: if you write
a promise object, it will suspend, but "you know it".
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.
@dai-shi That part was so misleading me that I didn't even dare to touch it.
So you confirm me that:
cont [_, setNum] = useAtom(writeAsync) is never gonna suspend
only the below will
cont [_, setNum] = useAtom(writeAsync) is never gonna suspend
React.useEffect(() => {
setTimeout(() => { setNum() }, 1000) // This triggers the suspend
}, [])
Are we good?
if you write a promise object, it will suspend, but "you know it".
I'm not sure I understood that part
How about moving "Async" section to the first item of "GUIDES"?
Arf I feel bad about it. I would have really liked for people to consider it basics. But I feel your pain of attacking utils straight in the basics... In that case, I would propose a re-order of the menu to put Async in top of the scene.
What do you think?
Just a proposition, we can fallback to just moving Async if you want, for now ;)
BASICS
- Concepts
- Primitives
API
- Core
- Utils
GUIDES
- Async
- Resettable <== Too simply to be a guide, should only be an util/recipe, no?
- Persistence
- Atoms in atom
- Composing atoms
EXPERIENCE
- TypeScript
- Debugging
- Devtools
- Babel
- Testing
- Core Internals
BRIDGES
- Next.js
- React Native
- Vite
SHOWCASE:
- Comparison
- Showcase
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.
@dai-shi I'm not sure how to document the loadable util correctly, tho.
Is there anything more that I should be aware of, more of the simple usage:
const loadableAtom = loadable(asyncAtom)
// Does not need to be wrapped by a <React.Suspense> element
const Component = () => {
const value = useAtom(loadableAtom)
}
I added it as last util, in my last commit, if you may review that part too ;)
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.
cont [_, setNum] = useAtom(writeAsync) is never gonna suspend
React.useEffect(() => {
setTimeout(() => { setNum() }, 1000) // This triggers the suspend
}, [])
It will not trigger suspend.
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.
@dai-shi Yeah, my bad! It's only gonna suspend read() calls. Gonna clean that up
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.
@TwistedMinda I wanted to say thanks for the docs that I never got to writing for the past 6 months! I added a little nit, but it being documented is far better than the situation we're in at the moment.
docs/utils/loadable.mdx
Outdated
title: loadable | ||
--- | ||
|
||
For some reason, you may not want to profit from the React's `Suspense` core handling of jotai, and prevent your app from suspending when using async atoms. |
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.
This comes off as a little negative to me ("not want to profit"), I think there are lots of valid use-cases for loadable
.
You could say something like
If you don't want async atoms to suspend or throw to an error boundary (for example, for finer-grained control of loading and error logic), you can use the
loadable
util. It returns a value with one of three states:loading
,hasData
andhasError
.
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.
@Pinpickle Sounds way better!
If you want to keep async section in basics, I would require that to be only about |
I want @sandren 's comment on it. |
Hm I feel stuck now. Cutting the async guide in half seems like a bad idea to me. If you want to cut in 2 parts, what would you approach in each? |
BASICS: only about I don't mean I'm very confident on this. So, I'd like to hear your opinions. But, I strongly feel we should have "BASICS" to explain only about |
@dai-shi Well even after meditating I still strongly believe we shouldn't cut the Async part, as its the "most-complicated" and should not be confusing in any way! So I moved it to guides as you recommended. But really had to move away the show-case that was preventing a good transition of basics to the first guide. A demo is not a basic, right? I moved it at the end in a Demo sub-section. Did you review the content of the async page? Do you think it's ok for now? |
Fair enough. I'll think about it once again.
Sorry, not yet. Please give me some time as this is such an important change/improvement. |
@dai-shi I think moving the async doc to 'guides' is a good idea as it allows us to cover more than what is available in Jotai core. 🙂 |
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.
Thanks for working on this! Looks very good. Added some comments.
readme.md
Outdated
- Demo | ||
- [Comparison](./docs/basics/comparison.mdx) | ||
- [Showcase](./docs/basics/showcase.mdx) |
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.
@sandren what do you think about moving them down here?
I expected many people are interested in "comparison" and "showcase" before diving into detailed docs.
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.
@dai-shi We can move the Demo Sub-section to the top of basics, I wouldn't mind at all, like the entry point
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.
In this PR, let's move them between Basics and Guides.
@sandren will probably re-organize anyway in follow-up PRs.
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.
done: 5d3d203
Co-authored-by: Daishi Kato <[email protected]>
Co-authored-by: Daishi Kato <[email protected]>
Co-authored-by: Daishi Kato <[email protected]>
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.
Let's merge this. Thanks so much for your contribution!
I need to re-read myself a few times more but I guess the main idea is here.
I would also like to test if the loadable API could be used inside actions to also explain how preloading can be done without Suspense.
Anyways, what do you think?
EDIT: What did I do to break the prettier check? :/