Merge pull request reduxjs#1992 from remiprev/fix/wrong-link-in-splitting-reducer-logic-doc

markerikson · web-flow · commit 7691312acf5d · 2016-09-26T11:39:43.000-04:00
Fix wrong link in “Splitting Up Reducer Logic” doc
diff --git a/docs/recipes/reducers/02-SplittingReducerLogic.md b/docs/recipes/reducers/02-SplittingReducerLogic.md
@@ -22,4 +22,4 @@ For clarity, these terms will be used to distinguish between different types of
 The term "*sub-reducer*" has also been used in various discussions to mean any function that is not the root reducer, although the term is not very precise.  Some people may also refer to some functions as "*business logic*" (functions that relate to application-specific behavior) or "*utility functions*" (generic functions that are not application-specific).
 
 
-Breaking down a complex process into smaller, more understandable parts is usually described with the term ***[functional decomposition](http://stackoverflow.com/questions/947874/what-is-functional-decomposition)***.  This term and concept can be applied generically to any code.  However, in Redux it is *very* common to structure reducer logic using approach #3, where update logic is delegated to other functions based on slice of state.  Redux refers to this concept as ***reducer composition***, and it is by far the most widely-used approach to structuring reducer logic.  In fact, it's so common that Redux includes a utility function called [`combineReducers()`](../../api/combineReducers.md), which specifically abstracts the process of delegating work to other reducer functions based on slices of state. However, it's important to note that it is not the *only* pattern that can be used.  In fact, it's entirely possible to use all three approaches for splitting up logic into functions, and usually a good idea as well.  The [Refactoring Reducers](./03-RefactoringReducers.md) section shows some examples of this in action.
+Breaking down a complex process into smaller, more understandable parts is usually described with the term ***[functional decomposition](http://stackoverflow.com/questions/947874/what-is-functional-decomposition)***.  This term and concept can be applied generically to any code.  However, in Redux it is *very* common to structure reducer logic using approach #3, where update logic is delegated to other functions based on slice of state.  Redux refers to this concept as ***reducer composition***, and it is by far the most widely-used approach to structuring reducer logic.  In fact, it's so common that Redux includes a utility function called [`combineReducers()`](../../api/combineReducers.md), which specifically abstracts the process of delegating work to other reducer functions based on slices of state. However, it's important to note that it is not the *only* pattern that can be used.  In fact, it's entirely possible to use all three approaches for splitting up logic into functions, and usually a good idea as well.  The [Refactoring Reducers](./03-RefactoringReducersExample.md) section shows some examples of this in action.

Original file line number	Diff line number	Diff line change
`@@ -22,4 +22,4 @@ For clarity, these terms will be used to distinguish between different types of`
`22`	`22`	`The term "sub-reducer" has also been used in various discussions to mean any function that is not the root reducer, although the term is not very precise. Some people may also refer to some functions as "business logic" (functions that relate to application-specific behavior) or "utility functions" (generic functions that are not application-specific).`
`23`	`23`
`24`	`24`
`25`		-Breaking down a complex process into smaller, more understandable parts is usually described with the term *[functional decomposition](http://stackoverflow.com/questions/947874/what-is-functional-decomposition). This term and concept can be applied generically to any code. However, in Redux it is very* common to structure reducer logic using approach #3, where update logic is delegated to other functions based on slice of state. Redux refers to this concept as *reducer composition, and it is by far the most widely-used approach to structuring reducer logic. In fact, it's so common that Redux includes a utility function called [`combineReducers()`](../../api/combineReducers.md), which specifically abstracts the process of delegating work to other reducer functions based on slices of state. However, it's important to note that it is not the only* pattern that can be used. In fact, it's entirely possible to use all three approaches for splitting up logic into functions, and usually a good idea as well. The [Refactoring Reducers](./03-RefactoringReducers.md) section shows some examples of this in action.
	`25`	+Breaking down a complex process into smaller, more understandable parts is usually described with the term *[functional decomposition](http://stackoverflow.com/questions/947874/what-is-functional-decomposition). This term and concept can be applied generically to any code. However, in Redux it is very* common to structure reducer logic using approach #3, where update logic is delegated to other functions based on slice of state. Redux refers to this concept as *reducer composition, and it is by far the most widely-used approach to structuring reducer logic. In fact, it's so common that Redux includes a utility function called [`combineReducers()`](../../api/combineReducers.md), which specifically abstracts the process of delegating work to other reducer functions based on slices of state. However, it's important to note that it is not the only* pattern that can be used. In fact, it's entirely possible to use all three approaches for splitting up logic into functions, and usually a good idea as well. The [Refactoring Reducers](./03-RefactoringReducersExample.md) section shows some examples of this in action.