-
Notifications
You must be signed in to change notification settings - Fork 289
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
Add Data Fetching Guide #991
base: main
Are you sure you want to change the base?
Conversation
Run & review this pull request in StackBlitz Codeflow. |
✅ Deploy Preview for solid-docs ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
Hi @amirhhashemi, First of all, thank you for taking the time to work on this, I appreciate the time you're taking out of your day to improve our documentation. It might be useful to take a look at the diataxis documentation on how guides should be written. We use this as a reference for writing our docs, and i feel like it could be helpful to consider for this! If you'd like some more directed feedback, however, please let me know |
Thank you for the feedback. I made some changes based on the diataxis guide:
I'm not sure about:
|
Thank you for adding some changes! One comment I do want to make, is that I think adding back some (basic) explanations can be helpful. Doesn't have to explain anything but the process, such as this:
This way it follows we have the code snippet explained a bit in case users need some kind of explanation (but not giving too much background about the topic itself, which is more appropriate for other sections in the docs). This is a pretty rough example but we can either have it as a quick list (if you feel it's necessary) or just a simple explanation of how things are set up in the snippet. I do agree that, to an extent, having each section self-contained is important. We don't want them so far removed that they could be considered separate entirely, but enough that there is some relationship (even if marginally). As for the Tanstack Query section, I do agree that it would probably be better suited for a tutorial than in here. That being said, a callout could probably replace the section saying something as simple as what you wrote for the first sentence:
Do you have any questions/ comments about what I mentioned? |
Thank you for the feedback. I've added basic explanations for each section. However, I have some concerns:
I would appreciate your feedback on these points. Please feel free to edit the document directly if needed. Regarding Tanstack Query: I've removed the dedicated section and added a brief note about it at the end of the |
I'm wondering whether we should remove the "how to" from section titles:
The way this guide is written, it's obvious we are only talking about how to do stuff, and not why and when. I think we can remove it. What do you think? |
@amirhhashemi Thank you for adding the explanations! I'll try and get to reviewing them this weekend (and seeing how we can approach the createResource section) but I wanted to say I think it's a great Idea to update the titles to remove the |
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 me know how you feel about these changes, but I feel like you did a great job explaining each code snippet briefly.
Co-authored-by: Sarah <gerrardsarah@gmail.com>
Co-authored-by: Sarah <gerrardsarah@gmail.com>
Co-authored-by: Sarah <gerrardsarah@gmail.com>
Co-authored-by: Sarah <gerrardsarah@gmail.com>
Co-authored-by: Sarah <gerrardsarah@gmail.com>
Co-authored-by: Sarah <gerrardsarah@gmail.com>
Co-authored-by: Sarah <gerrardsarah@gmail.com>
Co-authored-by: Sarah <gerrardsarah@gmail.com>
Co-authored-by: Sarah <gerrardsarah@gmail.com>
Co-authored-by: Sarah <gerrardsarah@gmail.com>
Co-authored-by: Sarah <gerrardsarah@gmail.com>
I really appreciate your feedback and help @LadyBluenotes. I think this PR if ready for the final review.
|
After this is merged, I see no reason for the current Date Loading page to remain. Should I remove it @LadyBluenotes? Edit: I created a PR that removes this page #995 |
When you only need to fetch data on the client side, you can use the [`createResource`](/reference/basic-reactivity/create-resource) primitive: | ||
|
||
```tsx {4-7} title="src/routes/index.tsx" | ||
import { createResource, ErrorBoundary, Suspense, For } from "solid-js"; | ||
|
||
export default function Page() { | ||
const [posts] = createResource(async () => { | ||
const posts = await fetch("https://my-api.com/posts"); | ||
return await posts.json(); | ||
}); | ||
return ( | ||
<ul> | ||
<ErrorBoundary fallback={<div>Something went wrong!</div>}> | ||
<Suspense fallback={<div>Loading...</div>}> | ||
<For each={posts()}>{(post) => <li>{post.title}</li>}</For> | ||
</Suspense> | ||
</ErrorBoundary> | ||
</ul> | ||
); | ||
} | ||
``` | ||
|
||
You can [read more about `createResource` here](/reference/basic-reactivity/create-resource). |
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.
So createAsync
can still be used to fetch on the client side, and the only reason you'd use createResource
instead is if you're not using solid-router
, not if you're fetching on the client. This section seems to confuse those two things together.
I'd break this into two separate sections, one that shows fetching on the client with createAsync
without "use server"
, and another that shows fetching using createResource
on both client and server.
Nevermind, I just noticed that most of your createAsync
snippets are fetching on the client already. The only correction I have is this section should be called "Fetching data without Solid Router"
or something like that.
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.
From the diataxis guide that we use as reference:
How-to guides must be written from the perspective of the user, not of the machinery. A how-to guide represents something that someone needs to get done. It’s defined in other words by the needs of a user. Every how-to guide should answer to a human project, in other words. It should show what the human needs to do, with the tools at hand, to obtain the result they need.
This is in strong contrast to common pattern for how-to guides that often prevails, in which how-to guides are defined by operations that can be performed with a tool or system. The problem with this latter pattern is that it offers little value to the user; it is not addressed to any need the user has. Instead, it’s focused on the tool, on taking the machinery through its motions.
Keeping each section action-oriented, focusing on a practical action that the user might want to do offers better value to the user. If the user wants to learn about a specific tool, it can go to the API Reference.
I believe the documentation should include a section discussing the pros and cons of using Solid.js versus Solid Router APIs for data fetching. Additionally, it would be helpful to clarify why some APIs are part of Solid Router while others belong to Solid.js. However, this page is not aimed at that type of content. Perhaps a tutorial on data fetching would be a more appropriate format for this discussion.
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 my initial draft, I included a call-out that gave a little hint:
<Callout type="info">
Note that `query` and `createAsync` are imported from `@solidjs/router`. By default, SolidStart uses [Solid Router](https://docs.solidjs.com/solid-router) under the hood. That means we can take advantage of all Solid Router data fetching primitives in SolidStart.
</Callout>
This may slightly disrupt the page's theme, but I think reintroducing a call-out like this could significantly help users navigate the material with greater clarity. At least until we add a comprehensive tutorial.
<Callout type="info" title="Advanced Data Handling"> | ||
For advanced features like automatic background re-fetching or infinite queries, you can use [Tanstack Query.](https://tanstack.com/query/latest/docs/framework/solid/overview) | ||
</Callout> |
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.
I like the callout, however I still think it would be helpful to show an example snippet here that shows using tanstack query with "use server"
. Would love to get some more thoughts on this.
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.
I almost wonder if we need a tutorial geared towards advanced data fetching. Like something that goes into the weeds of the more complicated parts people may run into?
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.
I think showcasing the usage of Tanstack Query with "use server"
is interesting enough to include in this guide. But, my concern is that it might go too far. If we want to cover Tanstack Query properly, we should add:
- A basic example of
createQuery
(with and without"use server"
) - A section about preloading data
- A section about error handling and loading UI
- A few examples of advanced things that Tanstack Query can do and SolidStart can't
It's too much for this page. I think it's better to leave it to the user to go through the Tanstack Query docs and figure things out. If there's any ambiguity regarding the use of "use server"
with Tanstack Query, we should consider updating other sections of the documentation for clarity.
## Preloading data | ||
|
||
Data fetching can be optimized during user navigation by preloading the data with the [`preload`](/solid-router/reference/preload-functions/preload) function: | ||
|
||
1. Export a `route` object with a `preload` function | ||
2. Run your query inside the `preload` function | ||
3. Use the query as usual in your component | ||
|
||
```tsx {9-11} title="src/routes/index.tsx" | ||
import { ErrorBoundary } from "solid-js"; | ||
import { query, createAsync, type RouteDefinition } from "@solidjs/router"; | ||
|
||
const getPosts = query(async () => { | ||
const posts = await fetch("https://my-api.com/posts"); | ||
return await posts.json(); | ||
}, "posts"); | ||
|
||
export const route = { | ||
preload: () => getPosts(), | ||
} satisfies RouteDefinition; | ||
|
||
export default function Page() { | ||
const post = createAsync(() => getPosts()); | ||
return ( | ||
<div> | ||
<ErrorBoundary fallback={<div>Something went wrong!</div>}> | ||
<h1>{post().title}</h1> | ||
</ErrorBoundary> | ||
</div> | ||
); | ||
} | ||
``` |
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.
Should we explain why preloading is even needed?
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.
It might be more worthwhile having that in a the other aspects of the docs (like the core parts of "learn" or a "tutorial". This is geared more towards people asking "how to" instead of "why" and i worry if we add the "why" here, it'd be assumed the rest of it should have it as well.
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.
that makes sense, we probably need a separate document for explaining the concepts and issues around data fetching + mutation
Description
The idea of the Guides section is to provide a resource for developers who don't read Solid.js and Solid Router docs before learning SolidStart, such as React developers who may think of SolidStart as what Next.js is for React and start learning Solid.js from SolidStart. However, I think a Guides section can be useful to a lot of people regardless of whether they come from React.
The goal is to get those users (or anyone really) up and running with SolidStart as quickly as possible, while also guiding them to read more relevant docs if they want to learn more.
This PR adds a Data Fetching page under the Guides section that covers basic data fetching patterns while providing links to relevant documentation for those who want to learn more.
See #861 for more context.
Related issues & labels
#914 #861