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

docs(async): Rework async education #1176

Merged
merged 19 commits into from
May 31, 2022
Merged

docs(async): Rework async education #1176

merged 19 commits into from
May 31, 2022

Conversation

TwistedMinda
Copy link
Collaborator

@TwistedMinda TwistedMinda commented May 21, 2022

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? :/

@vercel
Copy link

vercel bot commented May 21, 2022

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Updated
jotai ✅ Ready (Inspect) Visit Preview May 31, 2022 at 0:44AM (UTC)

@codesandbox-ci
Copy link

codesandbox-ci bot commented May 21, 2022

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:

Sandbox Source
React Configuration
React Typescript Configuration
React Browserify Configuration
React Snowpack Configuration
Next.js Configuration
Next.js with custom Babel config Configuration
React with custom Babel config Configuration

@dai-shi
Copy link
Member

dai-shi commented May 21, 2022

Thanks for the suggestion.

One request: I want to limit the discussion in "BASICS" to the core module jotai. If we need to talk about loadable from jotai/utils, "GUIDES" is a better place. How about moving "Async" section to the first item of "GUIDES"?

What did I do to break the prettier check? :/

yarn run prettier will fix it. I recently added it, which had once included and been broken for a while. There are pros and cons, but appreciate for understanding.

@@ -80,6 +110,57 @@ const Component = () => {

> There's no way to know as of now if an atom suspends because of `read` or `write`.
Copy link
Member

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".

Copy link
Collaborator Author

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

Copy link
Collaborator Author

@TwistedMinda TwistedMinda May 22, 2022

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 ;)

Copy link
Member

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.

Copy link
Collaborator Author

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

Copy link
Contributor

@Pinpickle Pinpickle left a 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.

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.
Copy link
Contributor

@Pinpickle Pinpickle May 23, 2022

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 and hasError.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Pinpickle Sounds way better!

@dai-shi
Copy link
Member

dai-shi commented May 23, 2022

Arf I feel bad about it. I would have really liked for people to consider it basics.

If you want to keep async section in basics, I would require that to be only about jotai, so no loadable. We can still more about async in guides. I actually like it better.

@dai-shi
Copy link
Member

dai-shi commented May 23, 2022

Just a proposition, we can fallback to just moving Async if you want, for now ;)

I want @sandren 's comment on it.

@TwistedMinda
Copy link
Collaborator Author

TwistedMinda commented May 23, 2022

@dai-shi

If you want to keep async section in basics, I would require that to be only about jotai, so no loadable. We can still more about async in guides. I actually like it better.

Hm I feel stuck now. Cutting the async guide in half seems like a bad idea to me.
I prefer your solution of moving it to Guides in total, if I had to choose

If you want to cut in 2 parts, what would you approach in each?

@dai-shi
Copy link
Member

dai-shi commented May 24, 2022

If you want to cut in 2 parts, what would you approach in each?

BASICS: only about atom(async(get) => ...) and the fact that we need <Suspense> higher in the tree, but within <Provider>.
GUIDES: async write, loadable, promise as value, infinite pending

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 jotai, no jotai/utils. If it's too confusing, "BASICS" can be only about "sync".

@TwistedMinda
Copy link
Collaborator Author

@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?
I'm not experienced with async atoms enough to documentate them better, so maybe just a polish and we can let someone take over?
I actually only use the simple patterns :p

@dai-shi
Copy link
Member

dai-shi commented May 26, 2022

So I moved it to guides as you recommended.

Fair enough. I'll think about it once again.

Did you review the content of the async page?

Sorry, not yet. Please give me some time as this is such an important change/improvement.

@sandren
Copy link
Collaborator

sandren commented May 26, 2022

@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. 🙂

Copy link
Member

@dai-shi dai-shi left a 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.

docs/guides/persistence.mdx Outdated Show resolved Hide resolved
readme.md Outdated
Comment on lines 206 to 208
- Demo
- [Comparison](./docs/basics/comparison.mdx)
- [Showcase](./docs/basics/showcase.mdx)
Copy link
Member

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.

Copy link
Collaborator Author

@TwistedMinda TwistedMinda May 28, 2022

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

Copy link
Member

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done: 5d3d203

docs/guides/async.mdx Outdated Show resolved Hide resolved
docs/guides/async.mdx Outdated Show resolved Hide resolved
Copy link
Member

@dai-shi dai-shi left a 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!

@dai-shi dai-shi merged commit 3a09955 into pmndrs:main May 31, 2022
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

Successfully merging this pull request may close these issues.

4 participants