Create Thinking in Redux category and move some pages in it

docs/basics/DataFlow.md

@@ -11,7 +11,7 @@ Redux architecture revolves around a **strict unidirectional data flow**.
 
 This means that all data in an application follows the same lifecycle pattern, making the logic of your app more predictable and easier to understand. It also encourages data normalization, so that you don't end up with multiple, independent copies of the same data that are unaware of one another.
 
-If you're still not convinced, read [Motivation](../introduction/Motivation.md) and [The Case for Flux](https://medium.com/@dan_abramov/the-case-for-flux-379b7d1982c6) for a compelling argument in favor of unidirectional data flow. Although [Redux is not exactly Flux](../introduction/PriorArt.md), it shares the same key benefits.
+If you're still not convinced, read [Motivation](../thinking-in-redux/Motivation.md) and [The Case for Flux](https://medium.com/@dan_abramov/the-case-for-flux-379b7d1982c6) for a compelling argument in favor of unidirectional data flow. Although [Redux is not exactly Flux](../thinking-in-redux/PriorArt.md), it shares the same key benefits.
 
 The data lifecycle in any Redux app follows these 4 steps:
 

docs/basics/Store.md

@@ -68,7 +68,7 @@ You can see how this causes the state held by the store to change:
 
 <img src='https://i.imgur.com/zMMtoMz.png' width='70%' />
 
-We specified the behavior of our app before we even started writing the UI. We won't do this in this tutorial, but at this point you can write tests for your reducers and action creators. You won't need to mock anything because they are just [pure](../introduction/ThreePrinciples.md#changes-are-made-with-pure-functions) functions. Call them, and make assertions on what they return.
+We specified the behavior of our app before we even started writing the UI. We won't do this in this tutorial, but at this point you can write tests for your reducers and action creators. You won't need to mock anything because they are just [pure](../thinking-in-redux/ThreePrinciples.md#changes-are-made-with-pure-functions) functions. Call them, and make assertions on what they return.
 
 ## Source Code
 

docs/faq/General.md

@@ -59,7 +59,7 @@ In the end, Redux is just a tool. It's a great tool, and there are some great re
 
 **Documentation**
 
-- [Introduction: Motivation](../introduction/Motivation.md)
+- [Thinking in Redux: Motivation](../thinking-in-redux/Motivation.md)
 
 **Articles**
 

docs/introduction/README.md

@@ -1,9 +1,6 @@
 # Introduction
 
-- [Motivation](Motivation.md)
 - [Core Concepts](CoreConcepts.md)
-- [Three Principles](ThreePrinciples.md)
-- [Prior Art](PriorArt.md)
 - [Learning Resources](LearningResources.md)
 - [Ecosystem](Ecosystem.md)
 - [Examples](Examples.md)

docs/recipes/ReducingBoilerplate.md

@@ -6,11 +6,11 @@ hide_title: true
 
 # Reducing Boilerplate
 
-Redux is in part [inspired by Flux](../introduction/PriorArt.md), and the most common complaint about Flux is how it makes you write a lot of boilerplate. In this recipe, we will consider how Redux lets us choose how verbose we'd like our code to be, depending on personal style, team preferences, longer term maintainability, and so on.
+Redux is in part [inspired by Flux](../thinking-in-redux/PriorArt.md), and the most common complaint about Flux is how it makes you write a lot of boilerplate. In this recipe, we will consider how Redux lets us choose how verbose we'd like our code to be, depending on personal style, team preferences, longer term maintainability, and so on.
 
 ## Actions
 
-Actions are plain objects describing what happened in the app, and serve as the sole way to describe an intention to mutate the data. It's important that **actions being objects you have to dispatch is not boilerplate, but one of the [fundamental design choices](../introduction/ThreePrinciples.md) of Redux**.
+Actions are plain objects describing what happened in the app, and serve as the sole way to describe an intention to mutate the data. It's important that **actions being objects you have to dispatch is not boilerplate, but one of the [fundamental design choices](../thinking-in-redux/ThreePrinciples.md) of Redux**.
 
 There are frameworks claiming to be similar to Flux, but without a concept of action objects. In terms of being predictable, this is a step backwards from Flux or Redux. If there are no serializable plain object actions, it is impossible to record and replay user sessions, or to implement [hot reloading with time travel](https://www.youtube.com/watch?v=xsSnOQynTHs). If you'd rather modify data directly, you don't need Redux.
 

docs/style-guide/style-guide.md

@@ -430,7 +430,7 @@ If multiple dispatches are truly necessary, consider batching the updates in som
 
 ### Evaluate Where Each Piece of State Should Live
 
-The ["Three Principles of Redux"](../introduction/ThreePrinciples.md) says that "the state of your whole application is stored in a single tree". This phrasing has been over-interpreted. It does not mean that literally _every_ value in the entire app _must_ be kept in the Redux store. Instead, **there should be a single place to find all values that _you_ consider to be global and app-wide**. Values that are "local" should generally be kept in the nearest UI component instead.
+The ["Three Principles of Redux"](../thinking-in-redux/ThreePrinciples.md) says that "the state of your whole application is stored in a single tree". This phrasing has been over-interpreted. It does not mean that literally _every_ value in the entire app _must_ be kept in the Redux store. Instead, **there should be a single place to find all values that _you_ consider to be global and app-wide**. Values that are "local" should generally be kept in the nearest UI component instead.
 
 Because of this, it is up to you as a developer to decide what state should actually live in the Redux store, and what should stay in component state. **[Use these rules of thumb to help evaluate each piece of state and decide where it should live](../faq/OrganizingState.md#do-i-have-to-put-all-my-state-into-redux-should-i-ever-use-reacts-setstate)**.
 

website/_redirects

@@ -65,11 +65,11 @@
 
 # Old old Gitbook links?
 /docs/introduction/CoreConcepts.html        /introduction/core-concepts
-/docs/introduction/Motivation.html        /introduction/motivation
+/docs/introduction/Motivation.html        /thinking-in-redux/motivation
 /docs/introduction/Ecosystem.html*        /introduction/ecosystem:splat
 /docs/introduction/CoreConcepts.html        /introduction/core-concepts
-/docs/introduction/PriorArt.html        /introduction/prior-art
-/docs/introduction/ThreePrinciples.html        /introduction/three-principles
+/docs/introduction/PriorArt.html        /thinking-in-redux/prior-art
+/docs/introduction/ThreePrinciples.html        /thinking-in-redux/three-principles
 /docs/introduction/Examples.html*         /introduction/examples:splat
 /docs/introduction/        /introduction/getting-started
 
@@ -144,4 +144,4 @@
 /feedback        /introduction/getting-started#help-and-discussion
 
 # PR preview for the new tutorial
-/tutorials/quick-start/quick-start-part-1        /tutorials/essentials/part-1-overview-concepts
+/tutorials/quick-start/quick-start-part-1        /tutorials/essentials/part-1-overview-concepts

website/sidebars.js

@@ -3,14 +3,16 @@ module.exports = {
     Introduction: [
       'introduction/getting-started',
       'introduction/installation',
-      'introduction/motivation',
       'introduction/core-concepts',
-      'introduction/three-principles',
-      'introduction/prior-art',
       'introduction/learning-resources',
       'introduction/ecosystem',
       'introduction/examples'
     ],
+    'Thinking In Redux': [
+      'thinking-in-redux/motivation',
+      'thinking-in-redux/three-principles',
+      'thinking-in-redux/prior-art'
+    ],
     Tutorials: [
       'tutorials/tutorials-index',
       {