|
| 1 | +use leptos::*; |
| 2 | + |
| 3 | +#[component] |
| 4 | +pub fn Introduction() -> impl IntoView { |
| 5 | + view! { |
| 6 | + <article |
| 7 | + class=" p-4 prose dark:prose-invert max-w-[75ch] mx-auto lg:prose-lg prose-zinc |
| 8 | + prose-p:text-foreground prose-headings:text-foreground prose-lead:text-foreground prose-li:text-foreground prose-ul:text-foreground prose-ol:text-foreground |
| 9 | + prose-hr:border-border prose-hr:my-2 |
| 10 | + prose-h1:my-1 lg:prose-h1:my-1 |
| 11 | + prose-h2:my-1 lg:prose-h2:my-1 |
| 12 | + "> |
| 13 | + <h1>Why Leptos Query?</h1> |
| 14 | + <hr></hr> |
| 15 | + <strong>What is a Query? What is async state?</strong> |
| 16 | + <p>Broadly, a Query is an async request for data, bound to a unique key. You often (but not always) "don't" own that state on the client. |
| 17 | + </p> |
| 18 | + <p> |
| 19 | + "We'll" call this state <code>Async State</code>. |
| 20 | + Here are some common properties: |
| 21 | + </p> |
| 22 | + <ul> |
| 23 | + <li>You do not control or own the "source of truth" on the client</li> |
| 24 | + <li>Requires async APIs for fetching data</li> |
| 25 | + <li> |
| 26 | + Implies shared ownership and can be changed by other people without your knowledge |
| 27 | + </li> |
| 28 | + <li> |
| 29 | + Can potentially become "out of date" in your apps if "you're" not careful |
| 30 | + </li> |
| 31 | + </ul> |
| 32 | + <p> |
| 33 | + Very often in programming highly dynamic web apps, you end up creating a client-side state machine to keep some |
| 34 | + <code>Async State</code> |
| 35 | + in sync with the actual source of truth (usually the server/database or the browser). |
| 36 | + </p> |
| 37 | + <p> |
| 38 | + This helps make your app "feel" more responsive, with instant updates and the like. |
| 39 | + </p> |
| 40 | + <h4> But there are issues... </h4> |
| 41 | + <ul> |
| 42 | + <li>"It's" a ton of work to get right</li> |
| 43 | + <li> |
| 44 | + "It's" incredibly easy to get wrong (have incorrect state, requiring a page refresh) |
| 45 | + </li> |
| 46 | + <li> |
| 47 | + It "doesn't" scale well. The more state you have, the more complex it gets |
| 48 | + </li> |
| 49 | + </ul> |
| 50 | + <h4>Here are some of the common challenges</h4> |
| 51 | + <ul> |
| 52 | + <li>Knowing when data is "out of date"</li> |
| 53 | + <li>Updating "out of date" data in the background</li> |
| 54 | + <li>No duplicate fetches for same data</li> |
| 55 | + <li>Configurable cache lifetimes</li> |
| 56 | + <li>Invalidation</li> |
| 57 | + <li>Cancellation</li> |
| 58 | + <li>Managing memory and garbage collection</li> |
| 59 | + <li>Updates (set to new value, update mut existing value, etc.)</li> |
| 60 | + <li>Client side persistence (local storage, indexed db, etc.)</li> |
| 61 | + </ul> |
| 62 | + <p>"Here's" where a Leptos Query comes in.</p> |
| 63 | + <h2>Leptos Query to the rescue</h2> |
| 64 | + <hr></hr> |
| 65 | + <p> |
| 66 | + Leptos Query is a client-side Query Manager, helping you manage |
| 67 | + <code>Async State</code> for highly dynamic and interactive Leptos web apps, which handles all of the above problems. |
| 68 | + </p> |
| 69 | + Practically speaking, by using Leptos Query, you will likely: |
| 70 | + <ul> |
| 71 | + <li>Reduce your code complexity and improve code maintainability by removing a lot of state management from your client side code</li> |
| 72 | + <li>Improve the user experience by improving the speed and responsiveness of your app</li> |
| 73 | + <li>Have a nicer debugging experience, with the provided Devtools</li> |
| 74 | + </ul> |
| 75 | + </article> |
| 76 | + } |
| 77 | +} |
0 commit comments