fix typos (#4767)

* fix typo

* Update you-might-not-need-an-effect.md

* Update you-might-not-need-an-effect.md

Author: balazsorban44

beta/src/pages/learn/you-might-not-need-an-effect.md

@@ -93,7 +93,7 @@ function TodoList({ todos, filter }) {
 
 In many cases, this code is fine! But maybe `getFilteredTodos()` is slow or you have a lot of `todos`. In that case you don't want to recalculate `getFilteredTodos()` if some unrelated state variable like `newTodo` has changed.
 
-You can cache (or ["memoize"](https://en.wikipedia.org/wiki/Memoization)) an expensive calculation by wrapping it [`useMemo`](/apis/usememo) Hook:
+You can cache (or ["memoize"](https://en.wikipedia.org/wiki/Memoization)) an expensive calculation by wrapping it in a [`useMemo`](/apis/usememo) Hook:
 
 ```js {5-8}
 import { useMemo, useState } from 'react';
@@ -250,7 +250,7 @@ Now there is no need to "adjust" the state at all. If the item with the selected
 
 ### Sharing logic between event handlers {/*sharing-logic-between-event-handlers*/}
 
-Let's say you have a product page with two buttons (Buy and Checkout) that both let you buy that product. You want to show a notification [toast](https://uxdesign.cc/toasts-or-snack-bars-design-organic-system-notifications-1236f2883023) whenever the user puts the product in the cart. Adding the `showToast()` call to both button's click handlers feels repetitive so you might be tempted to place this logic in an Effect:
+Let's say you have a product page with two buttons (Buy and Checkout) that both let you buy that product. You want to show a notification [toast](https://uxdesign.cc/toasts-or-snack-bars-design-organic-system-notifications-1236f2883023) whenever the user puts the product in the cart. Adding the `showToast()` call to both buttons' click handlers feels repetitive so you might be tempted to place this logic in an Effect:
 
 ```js {2-7}
 function ProductPage({ product, addToCart }) {
@@ -358,7 +358,7 @@ When you choose whether to put some logic into an event handler or an Effect, th
 
 ### Initializing the application {/*initializing-the-application*/}
 
-Some logic should only runs once when the app loads. You might place it in an Effect in the top-level component:
+Some logic should only run once when the app loads. You might place it in an Effect in the top-level component:
 
 ```js {2-6}
 function App() {
@@ -645,7 +645,7 @@ function SearchResults({ query }) {
 }
 ```
 
-This ensures that when you Effect fetches data, all responses except the last requested one will be ignored.
+This ensures that when your Effect fetches data, all responses except the last requested one will be ignored.
 
 Handling race conditions is not the only difficulty with implementing data fetching. You might also want to think about how to cache the responses (so that the user can click Back and see the previous screen instantly instead of a spinner), how to fetch them on the server (so that the initial server-rendered HTML contains the fetched content instead of a spinner), and how to avoid network waterfalls (so that a child component that needs to fetch data doesn't have to wait for every parent above it to finish fetching their data before it can start). **These issues apply to any UI library, not just React. Solving them is not trivial, which is why modern [frameworks](/learn/start-a-new-react-project#building-with-a-full-featured-framework) provide more efficient built-in data fetching mechanisms than writing Effects directly in your components.**