General

Introduction to Redux Pattern

Published Jan 11, 2021

Updated Feb 14, 2023

4 min read

This article was written over 18 months ago and may contain information that is out of date. Some content may be relevant but please refer to the relevant official documentation or available resources for the latest information.

Introduction to Redux Pattern

In this overview of the Redux Pattern, we'll dig into the basics and answer these pressing questions:

What is the Redux?
Why do we use the Redux?
When do we use the Redux?

Redux patterns in applications created in React or Angular are very handy tools in helping define state and managing active and passive events.

What is the Redux Pattern?

Redux is a pattern and library for managing and updating application state, using events called "actions". - Redux Documentation

Not only is redux great for defining events, it also guides the flow of events through preditable event tracking.

What Redux Pattern is not

Redux and Redux patterns are not to be confused with Flux patterns or Flux architecture. The main difference between these two patterns is the "single source of truth" concept.

Stores are our single sources of truth containing the state of our application. In Flux, the store can be split and defined in multiple locations throught the application.

Redux as a single source of truth means that we can better maintain and improve our applications by merging state and events into a single location. This single location feeding the application is one of the key considerations developing for the architecture and scalability of an application.

Why do we use the Redux Pattern?

...Redux makes it easier to understand when, where, why, and how the state in your application is being updated, and how your application logic will behave when those changes occur. - Redux Documentation

While Redux's use is simple for managing a "global" or "single source" level of state, there are some other impacting benefits:

Predictability of Events.

When we know what event will happen next if we click a button or link, we take away all assumptions about events triggering other events.

Better Debugging from Event Tracing.

Personally, event tracing is one of the huge benefits I like about state management because defects in events can be pinpointed accurately. If state wasn't updated correctly, we can make better logical assumptions.

Complex State Change

State is the one thing we can rely on and sometimes this state can receive asynchronous updates from different events. Redux makes these udpates easier to manage.

When do we use the Redux Pattern?

Ideally, Redux should be used for parts of an application that share state.

Here are a few other considerations when deciding to use the Redux pattern.

Frequency of State Changes

State can be small or large, simple or complex, but in every case where events are performed, state will always be updated.

Application Scalability

First, we need to predict how an application will grow in size from the number of features. As an application scales from a simple set of functions to an enterprise-level experience, duplicated code and events decrease performance.

Additionally, a Single Page Application (SPA) benfits greatly from Redux. For example, event-based routing behaves differently from a "regular" website since we conditionally generate new pages. As the SPA increases in features or pages, so does its need for state management.

Complexity of State Changes and Logic

Sometimes application state complexity increases as the application scales. Technical debt takes on a different form when the state isn't properly managed. Red, Green, Refactor is a simple, effective strategy to help minimize state technical debt - debt casue from a lack of code hygiene.

In Red, Green, Refactor we identify what needs to change, determine how we make the change, then execute the change. In the case for state, we can merge similar portions of state together or split apart state by feature or function, making it easier to access parts of state. Likewise, any logic that relies on combined or nested state should be updated as you make those changes.

How to Start Using Redux Today

While this is an introduction to using Redux, it's helpful to note where we can start to add it in our projects.

File Structure

First, we defined a store location. We can choose to have this live on the same directory level as our other components and services:

    src
    |- components
    |- services
    |- ...
    |- store
        |- actions
        |- reducers
        |- ...

React

Next, we can utilize state management. For vanilla JavaScript apps, we can use Redux as is, but there is special version of it created for React applications called React-Redux. The main difference here is the React integration:

    import ReactDOM from "react-dom";
    import ReactDOM from "react-dom";
    ...
    import { Provider } from "react-redux"; // needed to supply store to app
    import store from "./redux/store"; // your implementation of the store

    import TodoApp from "./TodoApp";

    const rootElement = document.getElementById("root");
    ReactDOM.render(
      <Provider store={store}> // now the app has access to our store
      <TodoApp />
      </Provider>,
      rootElement
    );

Angular

Similarly for the popular Angular framework, we have NgRx, a version of Redux created specifically for Angular.

    import { BrowserModule } from '@angular/platform-browser';
    import { NgModule } from '@angular/core';

    import { AppComponent } from './app.component';

    import { StoreModule } from '@ngrx/store'; // needed to supply store to app
    import { todoReducer } from './store/to-do.reducer'; // your implementation of the store

    @NgModule({
      declarations: [AppComponent],
      imports: [BrowserModule, StoreModule.forRoot({ todo: todoReducer })],
      providers: [],
      bootstrap: [AppComponent],
    })
    export class AppModule {}

You can choose your own adventure with state management. Choose wisely!

Closing Thoughts

Talking about the glories of Redux comes with it's cons as well. Keep in mind that using Redux also means defining a state that can become overly complex and require more overhead for Red-Green Refactoring. The benefits far outway this cost, however.

The key things to remember about Redux is that it's meant to define a predictable set of events, manage and share application state in a single source of truth, and should be used when a project becomes large and complex.

This Dot is a consultancy dedicated to guiding companies through their modernization and digital transformation journeys. Specializing in replatforming, modernizing, and launching new initiatives, we stand out by taking true ownership of your engineering projects.

We love helping teams with projects that have missed their deadlines or helping keep your strategic digital initiatives on course. Check out our case studies and our clients that trust us with their engineering.

About the author(s)

Morgan Worrell
Senior Software Engineer and Affiliate Professor empowering developers to achieve their career goals. When he’s not creating online course content, you can find him playing volleyball or music and working on 3D print projects. Specialized tech: Angular
@morgnism_@morgnism

Best Practices for Redux

Intro One year ago, I started to learn Redux for the first time. I was a code newbie, and I had a lot of difficulties understanding Redux! I was annoyed that I couldn't pass props from child components to the parent components in React, and I really needed Redux for that! I searched for alternatives to use instead of Redux, like React Context APIs, and I was happy with it because it’s already part of React. I didn't want to install any additional packages, and I found it easier to understand than Redux! In my first big project with React, I used React Context APIs and the project was so big and complex! After a while, the project became increasingly complex until I lost control, and couldn’t even make small changes. Plus, the states in React Context APIs were really a mess! What is Redux Redux is a predictable state container for JavaScript apps. It helps you write applications that behave consistently, run in different environments (client, server, and native), and are easy to test. On top of that, it provides a great developer experience, such as live code editing combined with a time-traveling debugger. Why do we need a Global store? In all major frontend frameworks like Angular, React, Vue, & Svelte, you can only pass data between your components from the parent components to the child components, and it is super hard to pass the data upward to the parent components! So Redux helps us to share the data easily with our different components! Redux’s problem But the real problem with Redux is organizing your files! Most of the tutorials just show you how you can configure a store, create a reducer, use dispatch, …etc, but after you use Redux for a while, you will have a mess of unorganized files, and you will need to learn how to organize the Redux files in your project! In this article, we will learn about the most used Redux patterns in real-world applications! Also in this tutorial, we will apply all of these patterns to this simple app! It’s a counter app created with create-react-app Redux Tool Kit (Recommended) This is the recommended pattern by the Redux core team, RTK is so much simpler and easier than using Redux! It uses slices, a new way to create and write the reducers, initial state and actions. Each slice file follows this pattern: ` And finally, we connect the slices with each other in the store.js ` Here is live example, run npm run dev https://stackblitz.com/edit/vitejs-vite-yaxe7w?ctl=1&embed=1&file=src/App.jsx&hideNavigation=1 Then you’ll use this store for the Redux provider in your app, simple isn’t it? For more info about this pattern take a look at Redux Essentials, Part 2: Redux App Structure Pros: As you see, everything is super organized and easy to edit and read! Redux ducks Redux Ducks is a different design pattern created by Erik Rasmussen, and in this pattern, we are merging all of our single reducer files into the reducer file itself, let’s see: ` And every reducer (duck file) will be: ` As you can see, we start with declaring our action types, and have no need to export them: ` Then the reducer (MUST BE DEFAULT EXPORTED). ` Finally, create the action types ` And that’s it! We have a standalone reducer that is so much easier to work with! Other strategies There are some software engineers who like to put the reducer next to the files or components that they will use in them: ` The old pattern This pattern is used by old apps, it’s not recommended to use it but you may find it when you work on old projects ` It is a folder called reducer that contains three other folders. and the store.js file in the root! Let's break them down. redux/types/counter.js is where we will save the action type as shown below: ` We added two action types for the two operations that we want to create, increment, and decrement. redux/actions/counter.js here we will add all of our action functions for the counter: ` First, we imported the types from the types file. Then, we created the two functions of our counter and exported them: redux/reducers/counter.js is the reducer for our counter. ` As you see, we imported the counter types again, and created our reducer. Finally, redux/store.js is where we will combine all of our reducers, and then configure our store: ` We imported the reducers first! Then we combined reducers, and finally create the store! Pros: As you see, everything is super organized, and easy to edit and read! Cons: Every reducer needs three files to be created, and this will end up with a massive number of files. Finally As you see, there are a lot of cool ideas to keep your Redux file organized. Try them, and choose the pattern that fits your project! And always work to keep your Redux files organized because this would be a game-changer for your project. 😉...

Jan 24, 2022

4 mins

JavaScriptReduxWeb Development

Redux Toolkit 2.0 release

Intro Redux Toolkit On December 4, 2023, Mark Erikson announced that Redux Toolkit 2.0 has been released! This change is considered a major version of the library and comes with breaking changes because, as the core team declared, it has been 4+ years since they released Redux tool kit, and they needed to clean up the code and standardize the way Redux apps are written. One of these changes is you no longer need to import the core redux library, RTK is a wrapper of it. In this article, we are going to focus on the main breaking changes and new features in RTK 2.0 Some general notes on the change * Standalone getDefaultMiddleware and getType removed * The package definitions now include an exports field to specify which artifacts to load, with a modern ESM build * UMD has been dropped * Typescript rewrite createSlice and createReducer One of the major changes is object syntax for createSlice.extraReducers and createReducer removed. In RTK 2.0, Redux team has opted to remove the 'object' form for createReducer and createSlice.extraReducers, as the 'builder callback' form offers greater flexibility and is more TypeScript-friendly, making it the preferred choice for both APIs So an example like this: ` Should be like this: ` Middlewares Now the configureStore.middleware must be a callback. That’s because before to add a middleware to the Redux store, you had to add it to the array of configureStore.middleware, but this is turning off the default middleware. Now it’s a callback function that should return an array with middlewares, the default middleware is being passed in the parameters of the callback function so the developer can include it or not in the middleware array like this: ` Enhancers Store enhancers are a formal mechanism for adding capabilities to Redux itself like adding some additional capabilities to the store. It could change how reducers process data, or how dispatch works. Most people will never need to write one. But similar to the middlewares, enhancers also must be a callback function that receives getDefaultEnhancers and should return enhancers back. ` autoBatchEnhancer In version 1.9.0, the Redux team introduced a new autoBatchEnhancer that, when multiple "low-priority" actions are dispatched consecutively. This enhancement aims to optimize performance by reducing the impact of UI updates, typically the most resource-intensive part of the update process. While RTK Query automatically marks most of its internal actions as "low-pri" users need to add the autoBatchEnhancer to the store for this feature to take effect. To simplify this process, configureStore has been updated to include the autoBatchEnhancer in the store setup by default, allowing users to benefit from improved performance without manual store configuration adjustments. AnyAction and UnknownAction The Redux TS types have historically exported an AnyAction type that lacks precise type safety, allowing for loose typology like console.log(action.whatever). However, to promote safer typing practices, they've introduced UnknownAction, which treats all fields beyond action.type as unknown, nudging users towards creating type guards with assertions for better type safety when accessing action objects. UnknownAction is now the default action object type in Redux, while AnyAction remains available but deprecated. RTK Query behavior They've addressed issues with RTK Query, such as problems with dispatch(endpoint.initiate(arg, {subscription: false})) and incorrect resolution timing for triggered lazy queries, by reworking RTKQ to consistently track cache entries. Additionally, they've introduced internal logic to delay tag invalidation for consecutive mutations, controlled by the new invalidationBehavior flag on createApi, with the default being 'delayed'. In RTK 1.9, the subscription status has been optimized syncing to the Redux state for performance, primarily for display in the Redux DevTools "RTK Query" panel. Conclusion This version is a major version of Redux Toolkit and it has a lot of breaking changes but what is important its source code has been cleaned and rewritten in TS will improve the developer experience for sure and on the final user experience as well, We discussed here only the headlines and the most used features but of course you can find all of the changes on The official Redux Github Releases page...

Mar 8, 2024

3 mins

ReduxJavaScript

Common Patterns and Nuances Using React Query

React hosts a number of solutions to various design problems due to its flexible paradigm. The decisions we make at the design and architecture phase of a project can either alleviate the time cost of development for a simple robust solution, or hinder it due to taxing implementations. One easy-to-implement yet sometimes tricky to use tool is react-query- a powerful library for asynchronous state management. It's simplicity in implementation makes it a desireable choice for writing component state logic. However, there are some unspoken aspects of React Query that may seem frustrating, and increase its difficulty, yet often fall on the context of the problem we hope to resolve. The next few concepts demonstrate some patterns for simple solutions while addressing some nuances one might encounter along the way. Note that react-query is now TanStack Query, and these concepts can be used in Vue, Solid, and Svelte. It'll continue to be referred to as React Query (RQ) in this React article. Understanding Query State Keys Under the hood, RQ performs some mappings similarly to "typed" actions works in other state machines. Actions, or in our case, queries, are mapped to a key where the value is either null, or some initial state (more on this in the following section). Because RQ is a state management tool, state will update relative to other stateful changes within a component. This means that whenever state changes in a component, these changes also affect the query's state performing state checks, and update accordingly. Take a Todo app that loads some tasks. The snapshot of the query's state can look like: ` If the state key changes, so does the cached data accessible at the key at that moment. State changes will only occur on a few select events. If the state key doesn't change, the query can still run, but the cached data won't update. Using Initial and Placeholder Data An example of this is with the use of initial data to represent values that haven't been fully loaded. It's common in state machines to introduce an initial state before hydration). Take the Todo app earlier that needs to show an initial loading state. On initial query, the tasks query is in loading status (aka isLoading = true). The UI will flicker this content in place when it's ready. This isn't the best UX, but it can be fixed quickly. RQ provides options for settings initialData or placeholderData. Although these properties have similarities, the difference is where caching occurs: cache-level vs observer-level. Cache-level refers to caching via Query Key, which is where initialData resides. This initial cache overrides observer-level caches. Observer-level refers to the location the subscription lives, and where placeholderData renders. Data at this level won't cache, and works if no initial data was cached. With initialData, you have more control over cache staleTime and refetching strategies. Whereas, placeholderData is a valid option for a simple UX enhancement. Keep in mind that error states change with the choice between caching initial data or not. ` Managing Refreshing State Expanding on the previous concept, updating the query happens when either state is stale, and we control the refresh, or we use other mechanisms, provided by RQ, to perform the same tasks. Re-hydrating Data RQ exposes a refresh method that makes a new network request for the query and updates state. However, if the cached state is the same as the newly fetched state, nothing will update. This can be a desired outcome to limit state updates, but take a situation where manual refetching is required once a mutation occurs. Using a query key with fetch queries increases the query's specificity, and adds control refetching. This is known as *Invalidation*, where the Query Key's data is marked as stale, cleared, and refetched. Refetching data can occur automatically or manually in varying degree for either approach. What this means is we can automatically have a query refetch data on stateTime or other refetching options (refetchInterval, refetchIntervalInBackground, refetchOnMount, refetchOnReconnect, and refetchOnWindowFocus). And we can refetch manually with the refetch function. Automatic refresh is rather straightforward, but there are times when we want to manually trigger an update to a specific Query Key thus fetching the latest data. However, you probably encountered a situation where the refetch function doesn't perform a network request. Processing HTTP Errors One of the more common situations beginners to RQ face is handling errors returned from failed http requests. In a standard fetch request using useState and useEffect, it is common to create some state to manage network errors. However, RQ can capture runtime errors if the API handler used doesn't contain proper error-handling. Whether runtime or network error, they appear in the error property of the query or mutation (also indicated by isError status). To overcome this and pass network error into the query, we can either do one or a combination of: - telling the fetch API how to process the failed response - using error boundaries with queries and mutations Handling Errors with Fetch For a simple solution to handling errors, process network requests from the fetch API (or axios) like the following: ` Then, in your component: ` This pattern gets repetitive, but is useful for simple apps that may not require heavy query use. Handling Errors with Error Boundaries Arguably the best thing a React dev can do for their app is to set an Error Boundary. Error Boundaries help contain runtime errors that would normally crash an app by propagating through the component tree. However, they can't process network errors without some setup. Thankfully, RQ makes this very easy with the useErrorBoundary option: ` The query hook takes the error, caches it, and rethrows it, so the error boundary captures it accordingly. Additionally, passing a function to useErrorBoundary that returns a boolean increases the granularity of network error handling like: ` Takeaways The three main concepts using React Query are: - hydrating the cache with placeholders or defaults - re-hydrating the cache with fresh data - handling network errors with the correct setup and error boundaries There are a number of state management tools to use with React, but React Query makes it simple to get up and running with an effective tool that adheres to some simple patterns and React rendering cycles. Learning how and when to execute queries to achieve the desire pattern takes some understanding of the React ecosystem....

Dec 19, 2022

5 mins

TypeScriptJavaScriptReact

Introduction to Zod for Data Validation

As web developers, we're often working with data from external sources like APIs we don't control or user inputs submitted to our backends. We can't always rely on this data to take the form we expect, and we can encounter unexpected errors when it deviates from expectations. But with the Zod library, we can define what our data ought to look like and parse the incoming data against those defined schemas. This lets us work with that data confidently, or to quickly throw an error when it isn't correct. Why use Zod? TypeScript is great for letting us define the shape of our data in our code. It helps us write more correct code the first time around by warning us if we are doing something we shouldn't. But TypeScript can't do everything for us. For example, we can define a variable as a string or a number, but we can't say "a string that starts with user_id_ and is 20 characters long" or "an integer between 1 and 5". There are limits to how much TypeScript can narrow down our data for us. Also, TypeScript is a tool for us developers. When we compile our code, our types are not available to the vanilla JavaScript. JavaScript can't validate that the data we actually use in our code matches what we thought we'd get when we wrote our TypeScript types unless you're willing to manually write code to perform those checks. This is where we can reach for a tool like Zod. With Zod, we can write data schemas. These schemas, in the simplest scenarios, look very much like TypeScript types. But we can do more with Zod than we can with TypeScript alone. Zod schemas let us create additional rules for data parsing and validation. A 20-character string that starts with user_id_? It's z.string().startsWith('user_id_').length(20). An integer between 1 and 5 inclusive? It's z.number().int().gte(1).lte(5). Zod's primitives give us many extra functions to be more specific about *exactly* what data we expect. Unlike TypeScript, Zod schemas aren't removed on compilation to JavaScript—we still have access to them! If our app receives some data, we can verify that it matches the expected shape by passing it to your Zod schema's parse function. You'll either get back your data in exactly the shape you defined in your schema, or Zod will give you an error to tell you what was wrong. Zod schemas aren't a replacement for TypeScript; rather, they are an excellent complement. Once we've defined our Zod schema, it's simple to derive a TypeScript type from it and to use that type as we normally would. But when we really need to be sure our data conforms to the schema, we can always parse the data with our schema for that extra confidence. Defining Data Schemas Zod schemas are the variables that define our expectations for the shape of our data, validate those expectations, and transform the data if necessary to match our desired shape. It's easy to start with simple schemas, and to add complexity as required. Zod provides different functions that represent data structures and related validation options, which can be combined to create larger schemas. In many cases, you'll probably be building a schema for a data object with properties of some primitive type. For example, here's a schema that would validate a JavaScript object representing an order for a pizza: ` Zod provides a number of primitives for defining schemas that line up with JavaScript primitives: string, number, bigint, boolean, date, symbol, undefined, and null. It also includes primitives void, any, unknown, and never for additional typing information. In addition to basic primitives, Zod can define object, array, and other native data structure schemas, as well as schemas for data structures not natively part of JavaScript like tuple and enum. The documentation contains considerable detail on the available data structures and how to use them. Parsing and Validating Data with Schemas With Zod schemas, you're not only telling your program what data should look like; you're also creating the tools to easily verify that the incoming data matches the schema definitions. This is where Zod really shines, as it greatly simplifies the process of validating data like user inputs or third party API responses. Let's say you're writing a website form to register new users. At a minimum, you'll need to make sure the new user's email address is a valid email address. For a password, we'll ask for something at least 8 characters long and including one letter, one number, and one special character. (Yes, this is not really the best way to write strong passwords; but for the sake of showing off how Zod works, we're going with it.) We'll also ask the user to confirm their password by typing it twice. First, let's create a Zod schema to model these inputs: ` So far, this schema is pretty basic. It's only making sure that whatever the user types as an email is an email, and it's checking that the password is at least 8 characters long. But it is *not* checking if password and confirmPassword match, nor checking for the complexity requirements. Let's enhance our schema to fix that! ` By adding refine with a custom validation function, we have been able to verify that the passwords match. If they don't, parsing will give us an error to let us know that the data was invalid. We can also chain refine functions to add checks for our password complexity rules: ` Here we've chained multiple refine functions. You could alternatively use superRefine, which gives you even more fine grained control. Now that we've built out our schema and added refinements for extra validation, we can parse some user inputs. Let's see two test cases: one that's bound to fail, and one that will succeed. ` There are two main ways we can use our schema to validate our data: parse and safeParse. The main difference is that parse will throw an error if validation fails, while safeParse will return an object with a success property of either true or false, and either a data property with your parsed data or an error property with the details of a ZodError explaining why the parsing failed. In the case of our example data, userInput2 will parse just fine and return the data for you to use. But userInput1 will create a ZodError listing all of the ways it has failed validation. ` ` We can use these error messages to communicate to the user how they need to fix their form inputs if validation fails. Each error in the list describes the validation failure and gives us a human readable message to go with it. You'll notice that the validation errors for checking for a valid email and for checking password length have a lot of details, but we've got three items at the end of the error list that don't really tell us anything useful: just a custom error of Invalid input. The first is from our refine checking if the passwords match, and the second two are from our refine functions checking for password complexity (numbers and special characters). Let's modify our refine functions so that these errors are useful! We'll add our own error parameters to customize the message we get back and the path to the data that failed validation. ` Now, our error messages from failures in refine are informative! You can figure out which form fields aren't validating from the path, and then display the messages next to form fields to let the user know how to remedy the error. ` By giving our refine checks a custom path and message, we can make better use of the returned errors. In this case, we can highlight specific problem form fields for the user and give them the message about what is wrong. Integrating with TypeScript Integrating Zod with TypeScript is very easy. Using z.infer<typeof YourSchema> will allow you to avoid writing extra TypeScript types that merely reflect the intent of your Zod schemas. You can create a type from any Zod schema like so: ` Using a TypeScript type derived from a Zod schema does *not* give you any extra level of data validation at the type level beyond what TypeScript is capable of. If you create a type from z.string.min(3).max(20), the TypeScript type will still just be string. And when compiled to JavaScript, even that will be gone! That's why you still need to use parse/safeParse on incoming data to validate it before proceeding as if it really does match your requirements. A common pattern with inferring types from Zod schemas is to use the same name for both. Because the schema is a variable, there's no name conflict if the type uses the same name. However, I find that this can lead to confusing situations when trying to import one or the other—my personal preference is to name the Zod schema with Schema at the end to make it clear which is which. Conclusion Zod is an excellent tool for easily and confidently asserting that the data you're working with is exactly the sort of data you were expecting. It gives us the ability to assert at runtime that we've got what we wanted, and allows us to then craft strategies to handle what happens if that data is wrong. Combined with the ability to infer TypeScript types from Zod schemas, it lets us write and run more reliable code with greater confidence....

Nov 15, 2024

7 mins

JavaScriptZod

Let's innovate together!

We're ready to be your trusted technical partners in your digital innovation journey.

Whether it's modernization or custom software solutions, our team of experts can guide you through best practices and how to build scalable, performant software that lasts.

Introduction to Redux Pattern

Introduction to Redux Pattern

What is the Redux Pattern?

What Redux Pattern is not

Why do we use the Redux Pattern?

Predictability of Events.

Better Debugging from Event Tracing.

Complex State Change

When do we use the Redux Pattern?

Frequency of State Changes

Application Scalability

Complexity of State Changes and Logic

How to Start Using Redux Today

File Structure

React

Angular

Closing Thoughts

Morgan Worrell

You might also like

Best Practices for Redux

Redux Toolkit 2.0 release

Common Patterns and Nuances Using React Query

Introduction to Zod for Data Validation

Let's innovate together!

You might also like

Best Practices for Redux

Redux Toolkit 2.0 release

Common Patterns and Nuances Using React Query

Introduction to Zod for Data Validation