Hey guys! 👋🏽.

Thanks for joining.

First and foremost, my advice would be that you should always try as much as possible to understand the underlying concept of a tool, framework, language, etcetera before using - implementing it.

Which makes learning worthwhile and sort of fun.

After all, is said and done 🙃, let's get started. This lecture will be in different parts so as not to bore you.

React can practically be considered as a group of components that are rendered in a tree-like structure. Of which is mainly centred around User-Interface.

It gives room for State Management tools to play an important role, such as Redux, Graph-Ql etcetera. Redux is a great state management tool and not just for react. Kindly note.

Concept

I would go on a limb here and assume everyone reading is conversant with the concept of a Component or a component-driven development. So let's take a look at diagram 1.0 below

This shows how each component is mapped to its respective state.

From this diagram, I would discuss the underlying problem which would arise in a big project if the said method of directly appending a component to its state.

1. Props Drilling: Which means passing down-state / properties between nested child components, that can be passed down through many child component layers before it finally gets to where it would be used. Even though most child components it passes through do not require it.

2.Redundant code: this refers to rewriting a bunch of code block in a repetitive manner.

Looking at the stated problem above, Redux which actually got inspiration from database design such as event sourcing and happens to be great in the follow.

1. Great for managing large state.
2. Useful for sharing data between components.
3. Predictably state management, using the 3 principles below;

i). Single source of truth: One big collective object of data
ii). State appears to be read only: So that it's doesn’t get modified easily
iii). Changes are made using only pure functions: This simple means a function that returns an output based on the input.

From the diagram above, we can deduce the difference from diagram 1.0. whereby each component's respective state has been removed and stored in one massive data object. Which in return describes what our application state should look like. In simple terms means no component holds any state.

Redux Operation

Components that compose our application fires actions, these fired actions set a single piece of the state which can be accessible to all components in the application. The state is what we call a reducer.

Every reducer is simply a function that takes two arguments a state and an action. Whereby the state can be referred to as the previous state it was in and would end up returning to a new state at the end of the function. Hence, it circles back to the principle listed above which states that it is immutable.

The above diagram describes the operational flow of events.

This pattern is called the Flux pattern: in simple terms an action that gets dispatched in other to update the view.

This is quite unlike the MVC Pattern (model, view, controller): whereby action is read by the controller, then the model - data is updated based on the controller input. of course, the model updates the view.

From the Action: let's say an event from a user (such as a click on the mouse or keypress). this action goes through the

Middleware: the middleware can be described as a piece of code that receives the action fired before relaying it to the reducer.

Then, the Reducer which happens to be a pure function takes an input (state & action) and creates a corresponding state output that can be referred to as the store.

And finally, the store (that is the corresponding state) updates the DOM - view.

Seems to be a lot of states here. So let's clarify with an example.

The above is an example of a reducer with a practical approach of that of a user, which consist of two arguments as discussed above.

This works with a switch case which checks if type is the same as SET_ACTION_TYPE then we would return a new object via spreading the state. and the main reason we return a new object is to make sure our component re-renders. And if there were no changes made, our component would return the current state by default.

Thanks for joining once again. Much advance implementation coming up!!!