Redux Core in React: Web Development

The Redux core library centers on a single object called the Store — think of it as one giant, tightly protected global variable that holds your entire application's state. Rather than scattering state across many components, Redux consolidates it into this one place.

The Store exposes exactly three core operations you'll use constantly: createStore() to set it up, dispatch() to send it actions describing what happened, and getState() to read its current data.

Every Redux application begins by calling createStore(), imported from the redux package. You must pass your root reducer function into createStore as its argument — const store = createStore(rootReducer) — so the Store knows exactly how to calculate a new state whenever it receives a future action.

Without a reducer, the Store has no logic to fall back on; the reducer is what defines how every possible action transforms the current state into the next one.

Once a Store exists, you interact with it through Actions — plain JavaScript objects that describe what happened, such as { type: 'USER_LOGIN_SUCCESS' }. The only requirement Redux strictly enforces is that every action object must include a type property, conventionally an uppercase string with underscores.

Actions don't perform any logic themselves; they're just descriptive messages that get sent to the reducer, which decides how to respond to them.

Actions often need to carry data along with the type, such as the text a user typed or the id of an item being added. By convention, that extra data goes inside a property named payload, e.g. { type: 'ADD_ITEM', payload: { id: 1, name: 'Apple' } }.

Redux itself doesn't require a payload field — only type is mandatory — but using payload consistently is the universal community standard that keeps action shapes predictable across a codebase.

Hardcoding action objects directly inside UI components is risky — a single typo in the type string, like 'ADD_ITM' instead of 'ADD_ITEM', causes a silent failure with no error thrown. Action creators solve this: an action creator is just a plain JavaScript function that returns a correctly-shaped action object, e.g. function addItem(item) { return { type: 'ADD_ITEM', payload: item }; }.

Calling dispatch(addItem(item)) instead of hand-writing the object everywhere centralizes the action's shape in one place, so a typo only needs fixing once.

The reducer is the brain of the Store — a plain function that takes two parameters, the current state and the action that was dispatched, and returns a new value that becomes the next state. On Redux's very first run, state is undefined, which is why reducers always declare a default parameter, like function reducer(state = initialState, action) { ... }.

That default is what seeds the Store with its starting values before any action has ever been dispatched.

A single reducer often has to handle dozens of distinct action types, like 'LOGIN', 'LOGOUT', or 'UPDATE_PROFILE', and chaining if/else blocks for all of them quickly turns unreadable. The industry-standard pattern instead uses a JavaScript switch statement on action.type, with one case per action and a mandatory default: return state; fallback.

That default case matters — if a reducer doesn't recognize the incoming action type, it must still return the existing state unchanged, never undefined or null.

Reducers must be pure functions, which means they can never mutate the state object directly — writing state.score = state.score + 10; return state; breaks Redux's ability to detect that anything changed. Instead, you use the spread operator (...) to copy every existing property into a brand-new object and then overwrite just the properties that changed: return { ...state, score: state.score + 10 };.

Returning a new object reference is exactly what lets Redux, and React-Redux, efficiently detect that the state actually changed.

The Redux Core. Welcome to the Redux Core. Now that we understand the philosophy, let's look at the actual code. To implement Redux, we use the core redux library. The central piece of the architecture is the 'Store'. It acts like a giant, highly protected global variable that holds your entire application state.

Creating the Store. The first step in any Redux application is to create the Store using createStore(). You must pass your root reducer function into createStore as its primary argument, so the Store knows how to handle future actions and calculate new states.

Actions (The WHAT). Once the store exists, you interact with it via Actions. As we covered, an Action is a plain JS object describing WHAT happened. The only strict requirement enforced by Redux is that the object MUST have a type property (typically a string in uppercase with underscores).

Action Payloads. Actions usually need to carry data to the Reducer. If the user typed a message, the action must carry that text string. By convention, we put this extra data inside a property named payload. This isn't technically required by the library, but it is the universal community standard.

Which property is STRICTLY REQUIRED by the Redux core library inside every Action object?

• →data
• →payload
• →type

Action Creators. Hardcoding action objects throughout your UI components is dangerous because a simple typo in the type string will cause silent failures. To fix this, we use 'Action Creators'. An Action Creator is simply a JavaScript function that returns an action object.

Reducers (The HOW). The Reducer is the brain of the Store. It is a standard function that takes two parameters: state (the current data) and action (the event). It returns a new object that replaces the current state. The first time Redux runs, the state is undefined, so you must provide a default initial state parameter (e.g., state = 0).

Switch Statements. Because a reducer might need to handle dozens of different action types ('LOGIN', 'LOGOUT', 'UPDATE_PROFILE', etc.), using if/else blocks gets extremely messy. The industry standard is to use a JavaScript switch statement on action.type.

What must a Reducer ALWAYS return in its default switch case if it does not recognize the action.type?

• →return null;
• →return state;
• →throw Error();

The Immutability Rule. As discussed in the intro, reducers MUST be pure functions. They cannot mutate state directly. You must use the spread operator (...) to copy the old state properties into a new object, and then overwrite the specific properties that changed.

Store Dispatch. To execute an action, we use store.dispatch(). You pass an action object (usually generated by an Action Creator) directly into this method. Redux immediately sends this action, along with the current state, into your Root Reducer. It evaluates the switch statement, returns the new state, and saves it in the Store.

Which function do we use to prevent typing errors by generating our Action objects automatically?

• →Action Creators
• →Reducers

Reading State. If you need to manually inspect the current state of the global store outside of a React component, you can call store.getState(). This returns the entire massive JavaScript object representing your application's current reality.

Unidirectional Flow. The reason we write all this boilerplate code is to enforce a strict, predictable 'Unidirectional Data Flow'. The UI triggers an Action Creator -> dispatch() sends the Action -> The Reducer calculates a new state -> The Store updates and notifies the UI. Data only ever flows in ONE direction.

Mastery Achieved. Fantastic! You've mastered the Redux Core API. You know how to create the Store, dispatch Actions via Action Creators, and write Pure Reducers using Switch statements. While you can use Redux entirely on its own, it's usually integrated directly into React components.