Part 1-2 edits

Author: markerikson

docs/tutorials/essentials/part-1-overview-concepts.md

@@ -19,13 +19,13 @@ import { DetailedExplanation } from '../../components/DetailedExplanation'
 
 Welcome to the Redux Essentials tutorial! **This tutorial will introduce you to Redux and teach you how to use it the right way, using our latest recommended tools and best practices**. By the time you finish, you should be able to start building your own Redux applications using the tools and patterns you've learned here.
 
-In Part 1 of this tutorial, we'll cover the key concepts and terms you need to know to use Redux, and in [Part 2: Redux App Structure](./part-2-app-structure.md) we'll examine a basic React + Redux app to see how the pieces fit together.
+In Part 1 of this tutorial, we'll cover the key concepts and terms you need to know to use Redux, and in [Part 2: Redux App Structure](./part-2-app-structure.md) we'll examine a typical React + Redux app to see how the pieces fit together.
 
 Starting in [Part 3: Basic Redux Data Flow](./part-3-data-flow.md), we'll use that knowledge to build a small social media feed app with some real-world features, see how those pieces actually work in practice, and talk about some important patterns and guidelines for using Redux.
 
 ### How to Read This Tutorial
 
-This page will focus on showing you _how_ to use Redux the right way, and explain just enough of the concepts so that you can understand how to build Redux apps correctly.
+This tutorial focuses on showing you _how_ to use Redux the right way, and explains concepts along the way so that you can understand how to build Redux apps correctly.
 
 We've tried to keep these explanations beginner-friendly, but we do need to make some assumptions about what you know already:
 
@@ -35,6 +35,7 @@ We've tried to keep these explanations beginner-friendly, but we do need to make
 - Familiarity with [ES2015 syntax and features](https://www.taniarascia.com/es6-syntax-and-feature-overview/)
 - Knowledge of React terminology: [JSX](https://react.dev/learn/writing-markup-with-jsx), [Function Components](https://react.dev/learn/your-first-component), [Props](https://react.dev/learn/passing-props-to-a-component), [State](https://react.dev/learn/state-a-components-memory), and [Hooks](https://react.dev/reference/react)
 - Knowledge of [asynchronous JavaScript](https://javascript.info/promise-basics) and [making HTTP requests](https://javascript.info/fetch)
+- Basic understanding of [TypeScript syntax and usage](https://www.typescriptlang.org/docs/handbook/typescript-in-5-minutes.html)
 
 :::
 

docs/tutorials/essentials/part-2-app-structure.md

@@ -190,7 +190,7 @@ export const store = configureStore({
 })
 ```
 
-In that example, `state.users`, `state.posts`, and `state.comments` are each a separate "slice" of the Redux state. Since `usersReducer` is responsible for updating the `state.users` slice, we refer to it as a "slice reducer" function.
+In that example, `state.users`, `state.posts`, and `state.comments` are each a separate "slice" of the Redux state. Since `usersReducer` is responsible for updating the `state.users` slice, we refer to it as a **"slice reducer" function**.
 
 <DetailedExplanation title="Detailed Explanation: Reducers and State Structure">
 
@@ -415,7 +415,7 @@ But, here's something _very_ important to remember:
 
 :::warning
 
-**You can _only_ write "mutating" logic in Redux Toolkit's `createSlice` and `createReducer` because they use Immer inside! If you write mutating logic in reducers without Immer, it _will_ mutate the state and cause bugs!**
+**You can _only_ write "mutating" logic in Redux Toolkit's `createSlice` and `createReducer` because they use Immer inside! If you write mutating logic in your code without Immer, it _will_ mutate the state and cause bugs!**
 
 :::
 
@@ -488,7 +488,7 @@ Note that you **don't have to create separate selector functions for every field
 
 :::info More Info on Selectors
 
-**[TODO]** We'll learn more about selector functions in [Part 4: Using Redux Data](./part-4-using-data.md), and look at how they can be optimized in [Part 6: Performance](./part-6-performance-normalization.md)
+We'll learn more about selector functions in [Part 4: Using Redux Data](./part-4-using-data.md#reading-data-with-selectors), and look at how they can be optimized in [Part 6: Performance](./part-6-performance-normalization.md#memoizing-selector-functions)
 
 See [Deriving Data with Selectors](../../usage/deriving-data-selectors.md) for a longer look at why and how to use selector functions.
 
@@ -500,8 +500,8 @@ So far, all the logic in our application has been synchronous. Actions are dispa
 
 A **thunk** is a specific kind of Redux function that can contain asynchronous logic. Thunks are written using two functions:
 
-- An inside thunk function, which gets `dispatch` and `getState` as arguments
-- The outside creator function, which creates and returns the thunk function
+- An inner thunk function, which gets `dispatch` and `getState` as arguments
+- The outer creator function, which creates and returns the thunk function
 
 The next function that's exported from `counterSlice` is an example of a thunk action creator:
 
@@ -600,6 +600,8 @@ export const counterSlice = createSlice({
 })
 ```
 
+If you're curious _why_ we use thunks for async logic, see this deeper explanation:
+
 <DetailedExplanation title="Detailed Explanation: Thunks and Async Logic">
 
 We know that we're not allowed to put any kind of async logic in reducers. But, that logic has to live somewhere.

docs/tutorials/essentials/part-4-using-data.md

@@ -441,7 +441,7 @@ const handleSubmit = (e: React.FormEvent<AddPostFormElements>) => {
 }
 ```
 
-## Writing Selectors for Slices
+## Reading Data With Selectors
 
 We now have a couple different components that are looking up a post by ID, and repeating the `state.posts.find()` call. This is duplicate code, and it's always worth _considering_ if we should de-duplicate things. It's also fragile - as we'll see in later sections, we are eventually going to start changing the posts slice state structure. When we do that, we'll have to find each place that we reference `state.posts` and update the logic accordingly. TypeScript will help catch broken code that no longer matches the expected state type by throwing errors at compile time, but it would be nice if we didn't have to keep rewriting our components every time we made a change to the data format in our reducers, and didn't have to repeat logic in the components.