From de4c6b1013c40413c3b043c91082918ecdfc50e1 Mon Sep 17 00:00:00 2001 From: zqran Date: Sat, 10 Sep 2022 00:54:02 +0800 Subject: [PATCH] [Beta] Update the link for React Router 6.4+ (#5024) * [Beta] Update links for React Router 6.4+ * [Beta] Update the link for Strict Mode --- beta/src/content/learn/synchronizing-with-effects.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/beta/src/content/learn/synchronizing-with-effects.md b/beta/src/content/learn/synchronizing-with-effects.md index 3d781299..2b5ed835 100644 --- a/beta/src/content/learn/synchronizing-with-effects.md +++ b/beta/src/content/learn/synchronizing-with-effects.md @@ -700,7 +700,7 @@ Writing `fetch` calls inside Effects is a [popular way to fetch data](https://ww This list of downsides is not specific to React. It applies to fetching data on mount with any library. Like with routing, data fetching is not trivial to do well, so we recommend the following approaches: - **If you use a [framework](/learn/start-a-new-react-project#building-with-a-full-featured-framework), use its built-in data fetching mechanism.** Modern React frameworks have integrated data fetching mechanisms that are efficient and don't suffer from the above pitfalls. -- **Otherwise, consider using or building a client-side cache.** Popular open source solutions include [React Query](https://react-query.tanstack.com/), [useSWR](https://swr.vercel.app/), and [React Router 6.4+.](https://beta.reactrouter.com/en/dev/getting-started/data) You can build your own solution too, in which case you would use Effects under the hood but also add logic for deduplicating requests, caching responses, and avoiding network waterfalls (by preloading data or hoisting data requirements to routes). +- **Otherwise, consider using or building a client-side cache.** Popular open source solutions include [React Query](https://react-query.tanstack.com/), [useSWR](https://swr.vercel.app/), and [React Router 6.4+.](https://beta.reactrouter.com/en/dev/getting-started/overview) You can build your own solution too, in which case you would use Effects under the hood but also add logic for deduplicating requests, caching responses, and avoiding network waterfalls (by preloading data or hoisting data requirements to routes). You can continue fetching data directly in Effects if neither of these approaches suit you. @@ -720,7 +720,7 @@ In development, `logVisit` will be called twice for every URL, so you might be t **In production, there will be no duplicate visit logs.** -To debug the analytics events you're sending, you can deploy your app to a staging environment (which runs in production mode) or temporarily opt out of [Strict Mode](/api/strictmode) and its development-only remounting checks. You may also send analytics from the route change event handlers instead of Effects. For even more precise analytics, [intersection observers](https://developer.mozilla.org/en-US/docs/Web/API/Intersection_Observer_API) can help track which components are in the viewport and how long they remain visible. +To debug the analytics events you're sending, you can deploy your app to a staging environment (which runs in production mode) or temporarily opt out of [Strict Mode](/apis/react/StrictMode) and its development-only remounting checks. You may also send analytics from the route change event handlers instead of Effects. For even more precise analytics, [intersection observers](https://developer.mozilla.org/en-US/docs/Web/API/Intersection_Observer_API) can help track which components are in the viewport and how long they remain visible. ### Not an Effect: Initializing the application {/*not-an-effect-initializing-the-application*/}