redux thunk

Author: rohan-paul

React/pureComponent.md

@@ -1,3 +1,13 @@
+#### Immutability Is Important for PureComponents
+
+By default, React components (both the functional type and the class type components, if it extends React.Component) will re-render whenever their parent re-renders, or whenever you change their state with setState.
+
+**An easy way to optimize a React component for performance is to make it a class, and make it extend React.PureComponent instead of React.Component. This way, the component will only re-render if it’s state is changed or if it’s props have changed. It will no longer mindlessly re-render every single time its parent re-renders; it will ONLY re-render if one of its props has changed since the last render.**
+
+Here’s where immutability comes in: if you’re passing props into a PureComponent, you have to make sure that those props are updated in an immutable way. That means, if they’re objects or arrays, you’ve gotta replace the entire value with a new (modified) object or array. Just like with Bob – kill it off and replace it with a clone.
+
+If you modify the internals of an object or array – by changing a property, or pushing a new item, or even modifying an item inside an array – then the object or array is referentially equal to its old self, and a PureComponent will not notice that it has changed, and will not re-render. Weird rendering bugs will ensue.
+
 #### PureComponent is exactly the same as Component except that it handles the shouldComponentUpdate method for you. When props or state changes, PureComponent will do a shallow comparison (see below notes for more details) on both props and state. Component on the other hand won’t compare current props and state to next out of the box. Thus, the component will re-render by default whenever shouldComponentUpdate is called.
 
 #### Now lets look at STATELESS Component vs Pure Component
@@ -53,9 +63,7 @@ When comparing previous props and state to next, a shallow comparison will check
 ### Further Reading
 
 1. [https://reactjs.org/docs/react-api.html#reactpurecomponent](https://reactjs.org/docs/react-api.html#reactpurecomponent)
-
 2. [https://reactjs.org/docs/shallow-compare.html](https://reactjs.org/docs/shallow-compare.html)
-
 3. [https://codeburst.io/when-to-use-component-or-purecomponent-a60cfad01a81](https://codeburst.io/when-to-use-component-or-purecomponent-a60cfad01a81)
-
 4. [https://logrocket.com/blog/pure-functional-components/](https://logrocket.com/blog/pure-functional-components/)
+5. [https://daveceddia.com/react-redux-immutability-guide/](https://daveceddia.com/react-redux-immutability-guide/)

Redux/redux-thunk-basics.md

@@ -1,10 +1,17 @@
 <img src="Redux-Thunk.jpeg">
 
-### First, the synchronous and pure flow of data through Redux’s components is well-defined with distinct, simple roles. Which is as below ->
+#### Thus, in summary there are two parts to Redux-Thunk:
+
+- 1. A thunk creator, which is an action creator that returns a thunk (a.k.a. asynchronous action creators)
+- 2. The thunk itself, which is the function that is returned from the thunk creator and accepts dispatch and setState as arguments
+
+The reason that we need to use a middleware such as Redux-Thunk is because the Redux store only supports synchronous data flow. Thus, middleware to the rescue! Middleware allows for asynchronous data flow, interprets anything that you dispatch and finally returns a plain object allowing the synchronous Redux data flow to resume. Redux middleware can thus solve for many critical asynchronous needs (e.g., axios requests).
+
+### First note that, the synchronous and pure flow of data through Redux’s components is well-defined with distinct, simple roles. Which is as below ->
 
 ### Action creators create objects → objects are dispatched to the store → the store invokes reducers → reducers generate new state → listeners are notified of state updates.
 
-A thunk is another word for a function. But it’s not just any old function. It’s a special (and uncommon) name for a function that’s returned by another. Like this:
+A thunk is another word for a function. It’s a special (and uncommon) name for a function that’s returned by another. Like this:
 
 ```js
 function not_a_thunk() {
@@ -41,7 +48,7 @@ Same action, but now you can “create” it by calling the userLoggedIn functio
 
 Isn’t it kind of funny that Redux’s so-called “actions” don’t actually do anything? They’re just objects. Boring and simple and inert.
 
-### **************\***************
+### **\*\***\*\***\*\***\***\*\***\*\***\*\***
 
 Redux Thunk teaches Redux to recognize special kinds of actions that are in fact functions.
 
@@ -53,7 +60,7 @@ If Redux Thunk middleware is enabled, any time you attempt to dispatch a functio
 
 And then since we “taught” Redux to recognize such “special” action creators (we call them thunk action creators), we can now use them in any place where we would use regular action creators.
 
-### ****************\*\*\*\*****************
+### **\*\***\*\*\*\***\*\***\*\*\*\***\*\***\*\*\*\***\*\***
 
 [https://medium.com/fullstack-academy/thunks-in-redux-the-basics-85e538a3fe60](https://medium.com/fullstack-academy/thunks-in-redux-the-basics-85e538a3fe60)
 
@@ -78,6 +85,28 @@ thunk.withExtraArgument = createThunkMiddleware;
 export default thunk;
 ```
 
+#### What is a side-effect?
+
+"Side Effect" is not a react-specific term. It is a general concept about behaviours of functions. A function is said to have side effect if it trys to modify anything outside its body. For example, if it modifies a global variable, then it is a side effect. If it makes a network call, it is a side effect as well.
+
+A "side effect" is anything that affects something outside the scope of the function being executed. These can be, say, a network request, which has your code communicating with a third party (and thus making the request, causing logs to be recorded, caches to be saved or updated, all sorts of effects that are outside the function.
+
+There are more subtle side effects, too. Changing the value of a closure-scoped variable is a side effect. Pushing a new item onto an array that was passed in as an argument is a side effect. Functions that execute without side effects are called "pure" functions: they take in arguments, and they return values. Nothing else happens upon executing the function. This makes the easy to test, simple to reason about, and functions that meet this description have all sorts of useful properties when it comes to optimization or refactoring.
+
+Pure functions are deterministic (meaning that, given an input, they always return the same output), but that doesn't mean that all impure functions have side effects. Generating a random value within a function makes it impure, but isn't a side effect, for example.
+
+#### What is side-effects in Redux or React
+
+The natural Redux flow is this: some action is dispatched, and as a consequence, some state is changed.
+
+But, most apps need to reach out to the outside world to be useful — whether by talking to the server, accessing local storage, recording analytics events, or something else entirely.
+
+That process of calling into the real world is what side-effects are. They are a way of bridging the pure Redux world with the outside world.
+
+But, we can’t handle side effects in reducers (they’re pure functions, they aren’t meant for making API calls).
+
+Thunks transform action creators so that they can return functions (rather than JSON objects representing actions). We can then use these functions to make API requests and trigger dispatch calls to our redux store.
+
 ### Other sources to Read
 
 1> This is the recommended one by thunk's own github page