From bacbe69409b0dbc2b97dcf04a943237c82339257 Mon Sep 17 00:00:00 2001 From: Zack Ward Date: Wed, 7 Oct 2020 22:41:40 -0400 Subject: [PATCH] Fix Typo --- docs/src/pages/docs/guides/does-this-replace-client-state.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/src/pages/docs/guides/does-this-replace-client-state.md b/docs/src/pages/docs/guides/does-this-replace-client-state.md index 2906938093..1a907fdf87 100644 --- a/docs/src/pages/docs/guides/does-this-replace-client-state.md +++ b/docs/src/pages/docs/guides/does-this-replace-client-state.md @@ -12,7 +12,7 @@ With those points in mind, the short answer is that React Query **replaces the b For a vast majority of applications, the truly **globally accessible client state** that is left over after migrating all of your async code to React Query is usually very tiny. -> There are still some cicurmstances where an application might indeed have a massive amount of synchronous client-only state (like a visual designer or music production application), in which case, you will probably still want a client state manager. In this situation it's important to note that **React Query is not a replacement for local/client state management**. However, you can use React Query along side most client state managers with zero issues. +> There are still some circumstances where an application might indeed have a massive amount of synchronous client-only state (like a visual designer or music production application), in which case, you will probably still want a client state manager. In this situation it's important to note that **React Query is not a replacement for local/client state management**. However, you can use React Query along side most client state managers with zero issues. ## A Contrived Example